[Azamat]

Доброго дня, коллеги.

 

Попробовали в работе netmap-ipfw, FreeBSD 10.1

Режим моста, цель - фильтрация/шейпинг. Трафика порядка 7Гбит в одну сторону, 1.2 в другую.

 

на ix1:

674K 0 0 812M 547K 0 118M 0 0

672K 0 0 812M 551K 0 118M 0 0

673K 0 0 811M 546K 0 116M 0 0

657K 0 0 795M 541K 0 116M 0 0

679K 0 0 818M 548K 0 118M 0 0

 

Собственно, суть вопроса к знатокам.

Процесс kipfw даже в режиме "allow ip from any to any" жрет через чур много:

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

660 root 99 0 885M 342M CPU2 2 80.1H 92.68% kipfw

 

Если включить пару реальных правил, например выделить исходящую полосу по маске на каждый IP (порядка 15К адресов),

то процесс мин через 15 бьет в 100% и трафик скидывается с 7Гбит до 2,5. Хотя load averages: 1.25, 1.20, 1.17

По описаниям технологии, должен был бы пережевать такой трафик в реальной работе, что же не так-то ?

 

Еще момент, объем занимаемой памяти не зависит от общего трафика, по крайней мере от ночных 2Гбит до вечерних 7 поле SIZE прибито в 885М (RES 342).

Может быть, где-то в коде задефайнен лимит ? Может быть, отпустить RAM, упадет load на процессоре ? (если вообще есть какая-то связь).

 

Пока одна радость, не падает + на него с основного шейпера снесена санация трафика от всяких левых 25 портов и др вирусни.

[GrandPr1de]

uname -a

А что за сетевка такая?

[Azamat]

10.1-STABLE FreeBSD 10.1-STABLE #4

сетевка обычная DA-520

[GrandPr1de]

в sysctl менялось что-то?

[Azamat]

похоже в режиме netmap обычные sysctl переменные не влияют на поведение сетевой подсистемы.

[t0ly]

c dev.netmap игрались? ман по netmap читали?

[Azamat]

нет по обоим последним вопросам.

С нетмап-ом ли проблема? kipfw же работает с пакетами, полученными в userspace от netmap модуля?

 

Получилось изменить объем выделяемой памяти под нетмап/kipfw, сейчас с 885М стало:

11366 root 100 0 1029M 93272K CPU1 1 40:44 95.17% kipfw

 

но, на потребление процессора это не сказалось :(

Изменено 5 января, 2015 пользователем Azamat

[DVM-Avgoor]

По идеологии netmap приложение должно находиться в постоянном poll'е. В таком положении расход цпу всегда будет высок на вид, ибо нет пустых циклов.

for (;;) {
            poll(&fds, 1, -1);
            while ( (buf = nm_nextpkt(d, &h)) )
                consume_pkt(buf, h->len);
        }

[Azamat]

Казалось бы, машина имеет вагон ресурсов, а kipfw тем не менее при определенных условиях бьет в потолок и привет DoS (отказ от обслуживания), трафик скидывается в 2,5 раза с потерями и ростом задержки.

 

Кстати, текущая версия netmap-ipfw заводится только с

hw.ix.rxd=2048

hw.ix.txd=2048

 

если сделать больше - kipfw не взлетает с ошибкой. Видимо тоже как-то через sysctl или в #define лечится ? если имеет значение в netmap режиме.

Изменено 5 января, 2015 пользователем Azamat

[DVM-Avgoor]

если сделать больше - kipfw не взлетает с ошибкой. Видимо тоже как-то через sysctl или в #define лечится ? если имеет значение в netmap режиме.

 

 

В man netmap есть все sysctl что можно крутить. Однако не надо забывать что и kipfw и netmap это скорее научная поделка и в продакшен им не место.

[Azamat]

ну, неделю работает мост, свою работу выполняет - подчищает исходящий трафик от мусора, разгрузив основной мост/шейпер от лишней работы.

Вот если бы kipfw жрал поменьше, тогда и исходящий шейпинг на него можно было бы вывесить.

[t0ly]

он и будет все время жрать под 100%, почему ? - ответил выше DVM-Avgoor.

поищите может есть крутилки сделать несколько таких процессов да разбить по ядрам, вообще в таких случаях стоит подебажить чем то. Я б сам с удовольствием это сделал но у меня нет железа под рукой для тестов.

[Azamat]

если вы можете дать некий план тестов, то можно дать вам удаленный доступ к моему мосту (скажем после 11 мск). В худшем случае, если упадет/уроните процесс kipfw машина будет работать как обычный мост.

Единственно, перезагрузок делать недопустимо.

 

Сейчас в работе такие правила к исходящему трафику:

00400 deny tcp from table(25) to any dst-port 25

00500 deny tcp from 192.168.0.0/16 to table(26) dst-port 25

00600 pipe 665 udp from 192.168.0.0/16 to any dst-port 6881

00700 pipe 666 tcp from 192.168.0.0/16 to any tcpflags syn

00750 pipe 10 udp from 192.168.0.0/16 to any

00760 pipe 11 tcp from 192.168.0.0/16 to any dst-port 443

 

все пайпы выдают полосу по маске на каждый ип адрес.

порядка 20К адресов.

in / out спецификаторы не работают, назначения red/gred не работают

 

трафика

root@bridge-netmap:/usr/local/netmap-ipfw/ipfw # netstat -bdh -w1 -I ix1

input ix1 output

packets errs idrops bytes packets errs bytes colls drops

675K 0 0 819M 523K 0 103M 0 0

669K 0 0 813M 525K 0 102M 0 0

^C

 

Загрузка:

last pid: 16662; load averages: 1.05, 1.13, 1.15 up 6+00:03:52 01:17:05

108 processes: 6 running, 75 sleeping, 27 waiting

CPU 0: 18.9% user, 0.0% nice, 5.9% system, 2.8% interrupt, 72.4% idle

CPU 1: 15.4% user, 0.0% nice, 6.7% system, 5.1% interrupt, 72.8% idle

CPU 2: 13.4% user, 0.0% nice, 5.9% system, 3.1% interrupt, 77.6% idle

CPU 3: 22.0% user, 0.0% nice, 7.1% system, 2.8% interrupt, 68.1% idle

Mem: 16M Active, 1352M Inact, 1054M Wired, 814M Buf, 5398M Free

Swap: 4096M Total, 4096M Free

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

11366 root 101 0 1053M 159M CPU2 2 395:22 93.65% kipfw

11 root 155 ki31 0K 64K RUN 2 116.6H 76.17% idle{idle: cpu2}

11 root 155 ki31 0K 64K CPU0 0 112.7H 75.29% idle{idle: cpu0}

11 root 155 ki31 0K 64K CPU3 3 116.7H 75.20% idle{idle: cpu3}

11 root 155 ki31 0K 64K RUN 1 116.1H 74.27% idle{idle: cpu1}

12 root -92 - 0K 432K WAIT 2 152:36 1.95% intr{irq266: ix0:que }

12 root -92 - 0K 432K WAIT 1 152:09 1.76% intr{irq265: ix0

 

 

Насчет нескольких процессов kipfw. Как-то сомнительно ?

процесс запускается

/usr/local/netmap-ipfw/kipfw netmap:ix0 netmap:ix1

 

видимо захватывает hw буфера сетевых и делает map в userspace. Как несколько процессов смогут это дело расшарить ?

[DVM-Avgoor]

netmap не умеет (пока) много очередей в картах которые это умеют. Было бы 4 сетевые карты можно было бы запустить 2 kipfw. Можно поиграть с переносом его на отдельный cpu, однако практической пользы, думаю, не будет. Ну и как бы чудес не бывает, netmap дает только два плюса: короткий стек вызовов между попаданием пакета на сетевую до входа в фильтр и отсутствие переключений контекста между ядерным и прикладным пространством процесса. Это дает местами неплохое ускорение, но если у вас в ipfw куча правил - все это уже особого значения не имеет, плюсы тают. Потому что реальная работа ipfw по поиску правил и применению их уже занимает ощутимо большее время чем накладные расходы на перекладывание пакетов. 2.5Гбит/с собственно и в обычном ipfw вполне достижимо. Чуда не случилось :)

[t0ly]

могу разве что посмотреть.

менять без синтетического теста и полного понимание происходящего, еще и боевую машину, только карму портить.

суня по загрузке процесс прыгает на разные ядра, прибивать к одному (cpuset) не пробовали?

очереди самих сетевух прибиты к ядрам?

проверяли скорость проседает когда начинают работать dummynet-pipe's или когда просто заполняется большая таблица ? (если большая таблица то дело в ipfw_chk, и тут нужно думать дальше, с ходу не скажу что делать)

Изменено 5 января, 2015 пользователем t0ly

[t0ly]

кстати flow control отключен?

[Megas]

Чуть раньше задавал вопросы и довел идею до работы, но вот как с freebsd не скажу, в лине работает.

Можно в статический lacp по середине ставить прозрачный bridge, в данном случае можно эту технологию применить для отладки такой штуки.

[Azamat]

fc в 0 по умолчанию взлетает с sysctl.conf

в лоадере

net.isr.maxthreads=4

net.isr.numthreads=4

net.isr.bindthreads=1

 

процесс пробовал прибивать к 1 ядру - он его отжимает в те же 100% и так же скидывает трафик.

Процесс отъедает 100 проц примерно через минуту и скидывает обрабатываемый трафик в 2,5 раза (на приличном трафике) после того, как включается правило типа

ipfw add XXX pipe 20 ip from 192.168.0.0/16 to any

где 20 пайп выдает на каждый IP адрес какую нибудь полосу по маске.

 

Если убрать правило - трафик сразу восстанавливается.

Как-таковой таблицы с большим кол-вом адресов не использую.

[t0ly]

по поводу dummynet pipe какого размера ставили ограничение? т.е. я к тому что если ограничение все же ставится то это логично что трафик падает.

[GrandPr1de]

ну в идеале tablearg довольно таки оптимизирует, но там надо таблицу вида

table 10 list
192.168.0.2 1
192.168.0.3 2
....
192.168.10.5 5012

 

Где агрументы 1,2...,5012 - это номер пайпа.

А правило было б одно

pipe tablearg ip from table\(10\) to any

[Azamat]

По идее выдача полосы идет по маске:

pipe 10 config mask src-ip 0xffffffff bw 4096Kbit/s

 

это ограничение достаточно велико для исходящего трафика, чтобы вдруг упал входящий в 2,5 раза.

На основном мосту падение входящего при применении этого правила было порядка 2-3 процентов.

 

причем, даже если правило выдает 10Мбит/с на каждый ип адрес - все равно происходит срыв входящего потока при упоре в 100 проц. Это дело можно легко продемонстрировать, если хотите. Дам доступ, сами увидите :) Лучше даже в ЧНН - 10 сек потерпятся.

[GrandPr1de]

Что мешает попробовать то что я раньше написал?

Сомневаюсь, что kipfw не умеет tablearg.

[Azamat]

завтра проверю. правда придется заполнять таблицу /16 строками, эт сколько млн.

[GrandPr1de]

завтра проверю. правда придется заполнять таблицу /16 строками, эт сколько млн.

ээээ а вы абонентам по \16 выдаете? И на каждую \16 4 мегабита?

Или всё таки 1 абон - 1 ип, и на 1 ип нарезка скорости?

[Azamat]

в целях тестирования на каждого из /16 выдаю по 4Мбит исходящей. Будет таки 64К строк в таблице