Тяжела и неказиста
Балансировать входящий трафик по трём каналам с BGP, имея всего два десятка префиксов, дело не вполне тривиальное. Отчаявшись получить от ребят, управляющих биллингом, процентное потребление входящего трафика префиксами, отзеркалировал netflow-трафик (v5) на свою FreeBSD и нарисовал перловый скрипт на 110 строк, который через Net::Pcap выбирает netflow из bpfilter, через Net::NetPacket достаёт из трафика собственно netflow, через Net::Flow его парсит и считает нужные мне проценты.
На десяти мегабитах отзеркалированного netflow скрипт в пиках кушает по 90% одного из четырех ядер Xeon E5420 2.5Ghz, причём всё это время он проводит внутри Net::Flow::decode(). К счастью, пики случаются не всё время. Но ставить в постоянную работу такой CPU-hog боязно.
Update: выкинул Net::Flow и переписал скрипт на ручное декодирование netflow v5 через unpack(). Теперь в пике скрипт грузит CPU на 15% (и это ещё не чистил циклы особо).
no subject
no subject
no subject
no subject
no subject
no subject
Может быть, включить promisc и делать ipfw fwd в того, кто честно слушает сокет?
И да, есть еще и flowd с возможностью отдачи скушанного netflow со всех сенсоров в unix socket в своем определенном формате. Куском софтины, которая это жует (для целей предаггрегации) могу поделиться
no subject
Сам по себе интерфейс в состоянии monitor способен пережевывать сотни мегабит без заметной нагрузки на CPU.
> Может быть, включить promisc и делать ipfw fwd в того, кто честно слушает сокет?
Это будет сильнее грузить, чем ifconfig monitor. А интерфейс и так в promisc.
> И да, есть еще и flowd с возможностью отдачи скушанного netflow со всех сенсоров в unix socket в своем определенном формате. Куском софтины, которая это жует (для целей предаггрегации) могу поделиться
Спасибо, у меня уже всё хорошо стало (обновил пост).