В рамках проекта ipdivert (http://sourceforge.net/projects/ipdivert/) создана реализации BSD divert сокетов для Linux ядра 2.6.x.
Данная технология позволяет перенаправлять пакеты пользовательскому приложению через задания iptables правил, но в отличии от ранее присутсвовавшего ip_queue/libipq, появилась возможность распараллеливания потоков для нескольких пользовательских приложений.URL: http://sourceforge.net/projects/ipdivert/
Новость: http://www.opennet.me/opennews/art.shtml?num=5823
cool!!! жаль что только под 2.6.x
Да ладно... Для ядра 2.2.16 (если я не ошибаюсь с последней цифрой) тоже патчик был, благополучно мною эксплуатировался. Вот правда для 2.4.X подобного патча вроде как не было...
как раз хотелось бы для 2.4.X
Не умеем пользоваться sf.net? Под 2.4 давно есть. http://sourceforge.net/project/showfiles.php?group_id=63197
Класс!!!
...пройдёт ещё пять лет и у линуксоидов появится production quality демон под это дело. У нас к тому времени уже 7 лет как будет использоваться netgraph версия ipacctd.... 8-)
Не, у нас уже давно стоит ng_netflow :)
Опасающиеся потери netflow-пакетиков на хреновых линках, могут завернуть его на 127.0.0.1, поставить на этой же машине flow-capture или другой коллектор netflow и периодически забирать данные оттуда, скажем по sftp :)
Если не секрет, чем ng_netflow лучше ng_ipacctd?
>Если не секрет, чем ng_netflow лучше ng_ipacctd?Полагаю, удобством. Для обработки netflow существует уже достаточно полезного софта.
>Если не секрет, чем ng_netflow лучше ng_ipacctd?В принципе, оба модуля выполняют одни и те же функции. Разница в том, как они это делают.
ng_ipacct все накопленные данные складывает в буфер в ядре, откуда их надо периодически забирать. Соответственно, если траффик неоднородный и его много, то есть возможность, что буфера не хватит.
ng_netflow все данные по сессиям отдает протоколом NetFlow 5й версии на коллектор - сервер, где запущена софтина, слушающая определенный udp-порт и складывающая все это в файлики или БД. Соответственно, нет возможности переполнения буффера, но на хреновых линках могут потеряться пакетики. Другая проблема - нет возможности идентифицировать источник пакетиков кроме как по ip-адресу. Способ борьбы с этими проблемами я описал в предыдущем комменте. Преимущество - есть куча разного софта для сбора данных netflow (в том числе и встроенных в различные системы биллинга).
Я пользуюсь flow-capture. Есть еще cflowd, netramet.Что выбрать, как обычно, зависит от выполняемых задач и личных предпочтений.
>>> ...пройдёт ещё пять лет и у линуксоидов появится production quality демон под это дело.Через пяток лет повторится ситуация, что текущий проект будет заброшен и снова начнут выдумывать костыли для существующего linux-a.b.c.d.e.f.g....
интересно сколько пройдет лет когда на БСД появится что-то типа Linux Advanced Routing (iproute2) или iptables или traffic control tools типа HTB. или скажем Linux Virtual Server
:)
>интересно сколько пройдет лет когда на БСД появится что-то типа Linux Advanced
>Routing (iproute2) или iptables или traffic control tools типа HTB. или
>скажем Linux Virtual Server
>:)
про LVS - cорри, он вроде уже там появился
http://www.opennet.me/opennews/art.shtml?num=5606
> iptables
why we need it? PF works good, does all i need.
> traffic control tools типа HTB
ALTQ works ok.
> Linux Virtual Server
i'd better add limits to jail...
А слухи о том, что ng_ipacctd теряет пакеты, остаются лишь слухами ? Я не в курсе, просветите, пожалуйста.
Аноним, может быть вы на самом деле один из core team и знаете что-то такое, чего простые админы не знают. Тогда я попался на вашу провокацию.
По наблюдениям простого админа, ничего не теряется, считает очень точно.
По рассуждениям простого админа, ng_tee не должен позволять пакетам теряться.
Очень хорошо, спасибо. Только зачем таким тоном?
Ну что ж, рад, что мои опасения оказались напрасными.
забыли упомянуть почемуто про NFQUEUE