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