bird_of_Luck

Ага. То есть все-таки ipfw table swap номер номер - актуально?

7.x неитнресно, увы, там все совсем другое. Мне больше интересно, не починилось ли оно после http://svnweb.freebsd.org/base?view=revision&revision=237309 -- дальше там, кажется, остается только в радикс смотреть.

Есть вот такая штука: http://code.google.com/p/flowd/ . Коллектор умеет v5/v9 (то есть +ipv6), а позитивен тем, что может отдавать в unix-сокет распарсенные фловы, что позволяет у себя в софте не заморачиваться парсингом N протоколов. Можно было упростить себе жизнь и использовать его. Я, в принципе, могу поделиться частью кода, который из этого сокета читает фловы, если есть желание. Единственное, что хочется понять - под какой лицензией живет существующий код :)

Оно рабочее, знаю одного провайдера, который этим больше сотни микротиков терминирует :)

Без отказа от PF тут оптимизировать ничего не получится. Лучше попробуйте ipfw nat, если проблемы будут оставаться - можно будет в этом же тредике пооптимизировать систему/рулсет.

Попробуйте обновиться до -STABLE, есть некоторая уверенность, что проблема исчезнет. Если не исчезнет - пишите сюда, или мне на melifaro@freebsd.org - попробуем зачинить. Я давно за ней гоняюсь :) Если возможности обновиться нет - действительно, тогда или не пользоваться flush, и делать точечные add/delete, или действительно придумывать схему с ifpw swap для рулсета, где в правилах меняется только номер таблицы. Ну и да, хочется чуть более точного описания проблемы (можно в приват) с описанием всех вызовов ipfw(8)

Новая версия, 20130301. Changelog: * bird 1.3.9 в качестве базы * Появилась возможность конвертации префиксов IPv6 unicast в Labeled unicast (обход "особенностей" (не)работы send-labeled в ряде cisco платформ). Ссылка: http://bird.mpls.in/distfiles/bird/bird-20130301.tar.gz Пользователи FreeBSD могут просто обновить порты.

..Поменять softflowd на ng_netflow Обновить систему до 8.3-STABLE

Цена/время разработки существенно снижается и этого, собственно, достаточно. Кроме того, не надо думать ни про какую совместимость со старым кодом (а в роутинг, напомню, лезут еще и разные TCP и прочие протоколы, и вообще много-много завязок, развязывать которые - это человекогоды) Нетграф решает вообще другую задачу. Как минимум там нет пакетной обработки, которая key point, и вообще это всего лишь часть айсберга (которую, впрочем, можно подумать про портировать в юзерленд тоже).

Мы планируем через пару месяцев начать смотреть и катить в продакшн. Кроме того, luigi@ как раз для юзерленда обещает сделать компилятор правил в нативный код.

Новый уровень софторварда - это, например, то что сделал Intel в своем DPDK, где речь идет про ~100MPPS с userland routing на сходной софтовой платформе. А единицы мегапакетов - это, извините, не уровень. Вот, у нас например на более слабом 2x Xeon E5645 без HT с 11 очередями и одной Intel 82599 - на FreeBSD8 2.5MPPS 64байтными пакетами с включенным ipfw.

Не надо такое советовать, лучше не будет. Тем более что в случае dummynet indirect isr там и так вылезет. Вообще говоря, ситуация довольно странная. На вид оно в принципе должно молотить как минимум несколько гигабит без проблем (если, конечно, там не совсем все плохо с файрволллом). У нас достаточно большое количество коробок с десяточными интелями на 8-S, в целом по больнице симптомов зависания насмерть при хоршем железе - нету.

На восьмерке, кажется, это тоже встречается, но на порядки реже (жаловался один человек в ML). Скорее всего у вас при обновлении на 8 это пропадет

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

Про файрволл без комментариев, выше все написано. Тут, скорее, забава вот в чем: #if __FreeBSD_version >= 800000 rxr->fmp->m_pkthdr.flowid = que->msix; rxr->fmp->m_flags |= M_FLOWID; #endif © sys/dev/e1000/if_igb.c То есть для всего non-ip трафика всем пакетам выставляется нулевая очередь. Можно это просто вынести из драйвера, можно патч применить и выкрутить dev.igb.X.use_flowid=0 на тех картах, где бегает PPPoE. Патч вот: http://static.ipfw.ru/patches/e1000_flowid.diff Ну и да, если лучше не станет (да и вообще, в любом случае) интересно взглянуть на netstat -Q, netstat -B, systat -vm 1 или top -HSP

А это кто с т.з. интелевых драйверов? em? igb? Вообще это 4хпортовый вариант 82576, примерно этим же кодом и поддерживается. А как при этом трафик ходит, опишите? (роутинг, или нетграф, есть ли шейпинг, etc, чего с фиреволлом, в общем хочется услышать путь прохождения пакета). Есть идея, которая легко реализуется и скорее всего поможет. С 71EB лучше не будет, тут дело не в карте вовсе.

Это я больше для себя (и Ivan_83) ng_nat и прочее libalias-based прямо из коробки без дополнительных ухищрений организует очередь из желающих - потому что защищается мьютексом, то есть не более одного пользователя одноврменно. Это, кстати, еще одна мораль - не пихайте всех в один нат, а сделайте большую их пачку

Можно, но зачем? Лучше честно перевести netisr на buf_ring, как и большинство сетевых драйверов.

Вообще довольно странно звучит. Тем более, что у человека проблема в файрволле, а не в карточках. Во-первых, igb igb'у рознь, а em - вообще legacy, через который трафик-то особо и не погонять. Ну а во-вторых, фиреволлинг - это процентов 30, а в случаях, как выше - и все 80. Грешить на карточки стоит далеко не всегда. Если есть возможность посетапить еще коробку, указать конфигурацию, подать трафик и тюнить - то могу попробовать полечить по фотографии.

Вообще странно, нонешний netisr жрет 10-15-20% дополнительной нагрузки по сравнению с direct, это в результате какой-то искусстенный шейпер получился :) Но если очень хочется - можно вместо дополнительных флагов выставлять M_FLOWID и m->m_pkthdr.flowid в curcpu там же. В netisr код простой - u_int netisr_default_flow2cpu(u_int flowid) { return (nws_array[flowid % nws_count]); }

Через недельку будет в -STABLE, можно пробовать. Оно немного хуже, чем skipto XXXX via iface-name, потому что skipto tablearg работает за логарифм от количества правил, но все равно лучше, чем 5-6 skipto подряд. Поэтому лучше комбинировать - если есть интерфейс, где бегает куча трафика - указать его явным skipto, а для остальных - делать skipto tablearg.

Ага, уже лучше. Тут еще можно поделить-таки на in-out вот так: skipto 500 ip from any to any out 00007 143928863 49229232396 setfib 2 ip from table(91) to any 00008 16410435 5024164499 setfib 3 ip from table(71) to any 00110 176067271 85046336428 nat tablearg ip from any to table(92) recv vlan136 00130 10275850 9414368266 nat tablearg ip from any to table(72) recv igb1 00140 91971055 40780631803 nat tablearg ip from any to table(82) recv vlan134 allow ip from any to any 00550 33536343 12997457095 nat tablearg ip from table(81) to any xmit vlan134 00590 58437065 20594511126 nat tablearg ip from table(91) to any xmit vlan136 00592 8203108 2512191916 nat tablearg ip from table(71) to any xmit igb1 65535 387265807 175454005095 allow ip from any to any А если клиенты реально только за igb0 и там нет вланов - то еще проще, например как-то так: allow ip from any to any via igb0 (на входе от клиента мы не натим, на выходе в него - тоже) skipto 500 ip from any to any out 00007 143928863 49229232396 setfib 2 ip from table(91) to any 00008 16410435 5024164499 setfib 3 ip from table(71) to any 00110 176067271 85046336428 nat tablearg ip from any to table(X) allow ip from any to any 00550 33536343 12997457095 nat tablearg ip from table(X+1) to any 65535 387265807 175454005095 allow ip from any to any (Ну и помним еще про setfib tablearg в STABLE) P.S. и one_pass включаем, разумеется, если еще не P.P.S. Точнее все даже еще проще - в STABLE вот такое есть: vlan262: flags=808943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 fib 13 description: CLIENT: XXXX

1) Там дерево. От того, что ты добавишь туда еще 1000 записей к 100 - даст тебе еще 1 ступенькю люкапа (т.к. он делается за логарифм), а так - ты делаешь 2 записи в фиреволле с двумя деревьями. Это дороже 2) Опять же, там дерево, там most specific match

Тут надо понимать, что примерно процентов 80 сейчас жрет фиреволл, в первую очередь имеет смысл оптимизировать его. А после уже можно прибивать ядра, уменьшать количество очередей на картах, еще чего-то делать. По поводу ната: Во-первых ipfw умеет recv vlanX. Но я говорю про вещь попроще: Нельзя например 00120 1701 104173 nat tablearg ip from any to table(42) in recv igb1 00130 739419 665839692 nat tablearg ip from any to table(72) in recv igb1 обьединить в одно правило? 00100 34525 13624121 nat tablearg ip from any to table(22) in recv vlan134 00110 421269 398346782 nat tablearg ip from any to table(32) in recv vlan136 00140 4245292 2191123296 nat tablearg ip from any to table(82) in recv vlan134 00150 9955923 4645520197 nat tablearg ip from any to table(92) in recv vlan136 тоже. Ну или хотя бы два. Тут же ведь не надо все же два раза натить, ведь правда? Я, честно говоря, не очень понимаю еще всю конструкцию в целом: Можно описать, что из этого что? То есть вот, igb1 - аплинк. vlan134/136 - тоже? А клиенты где?

Вполне может быть. Оно даже на вид не очень лучше. Еще раз: надо добиваться того, чтобы общая масса трафика ходила через 5 например правил на IN и 5 на out. Вот нельзя таблички с натами на IN обьединить в одну, например (опционально включив потом verrevpath) ? И с out так же поступить? Да и первые четыре правило даже с текущей версией системы можно смешать в два, если сделать 2 общие таблицы. Судя по конфигурации, one_pass выключенный тут совершенно незачем