Компания НетАП подготовила новую версию коллектора статистики ndsad (http://sourceforge.net/projects/ndsad), бесплатно распространяемого в исходных кодах под лицензией GPL.Коллектор ndsad предназначен для сбора информации по трафику с интерфейсов PC-маршрутизатора и экспорта ее в формате Cisco NetFlow v.5. Поддерживаются Linux, FreeBSD, Windows и другие операционные системы.
В новой версии добавлена поддержка tee/divert сокетов в FreeBSD (при использовании ipfw), поддержка ULOG интерфейса в Linux (при использовании iptables), а так же поддержка интерфейса \Device\NPF_GenericDialupAdapter в Windows 2003 server (данный интерфейс используется при организации VPN-сервера на базе Windows 2003). Добавление этих функций расширяет возможности учета трафика и повышает гибкость конфигурирования. В частности, легко решаются проблемы с дублированием трафика в сложных, распределенных сетях.
Релиз ndsad-1.33 доступен в исходных кодах на сайте проекта sourceforge.net (http://sourceforge.net/projects/ndsad).URL: http://www.netup.ru/?news=59
Новость: http://www.opennet.me/opennews/art.shtml?num=6523
Кто нибудь пользовал этот коллектор
на потоках 2Мбит и больше ?
Раскажите, плиз, про нагрузку на процессор.
На сколько растет и на какож железе (процессор, память) ?
no problem.
Pen-200, 10% at 10 clients, traffic - 1-3 Mbit
При потоке 100 Мбит жрет до 50% максимум 2,4 Ghz проца... работает нормально, пока отклонений более 5% от провайдерского обсчета замечено не было.
Теряет пакеты (до 10 %)
Celeron 1100
256RAM40-50 Mbit
>Теряет пакеты (до 10 %)
>Celeron 1100теряет пакеты не ndsad, а libpcap
новая функция ULOG/divert тебе поможет - теряться ничего не будет
А зачем оно на фряхе, когда там есть ng_netflow?
ndsad лучше всех работает с tun. Был бы другой такой же простой коллектор, который с меньше загрузкой нормально тянул бы tun - пользовал бы его. Но пока без альтернатив... А ng_netflow, как это ни удивительно, не всегда получается к ng прикрутить. Сейчас, вроде, что-то там сделали, а раньше (под бздей 5.4 - точно, ибо сам наступал на эти грабли) без патченья нетграфа хер будет на ng (а значит - mpd - а как тогда vpn считать?) ng_netflow садиться... Тип интерфейса ng был неподходящий...
В общем, ИМХО, недостаточно ng_netflow еще устаканился - часто то в нем, то в нетграфе меняют. Да и опять же - надо его индивидуально на каждый фейс вешать. А тут: запустил тулзу и она сама считает что надо. Разве что в конфиге поставить надо, какие фейсы игнорировать и какой трафик фильтровать, чтобы он даже не считался (это еще пинок в сторону ng_netflow, который тупо шлет все подряд)...
Но, естественно, за все приходится расплачиваться загрузкой проца... Так что... Се ля ви...
Все работает на 5.4, пробовал и на 5.3 -- считает с 600 ng интерфейсов, плюс с обычных. Для всего этого используется _один_ ng_netflow узел. К которому посредством множества связей присоединены все интерфейсы. mpd4 умеет вставлять ng_tee узел в граф, к которому уже цепляется ng_netflow, mpd3.18 надо патчить, но патчи на каждом углу валяются -- проблем быть не должно. Интерфейсы, которые надо игнорировать просто не подключаешь к нетфлоу и он их игнорирует 8)Впечатления от работы ng_netflow пока только положительные, загрузка процессора невелика, трафик бегает с минимальными задержками, кстати, в случае с userland решением величина задержек сильно возрастает при возрастании load averages.
> mpd3.18 надо патчить
Об том и речь. Не люблю я этого дела. Я привык к Бздишной "основательности" - все работает из коробки (дистро, порты - не важно). Всякие патчи - удел Линукса.... Эти - под mpd - уже внесли в stable? Или вообще куда-нибудь, откуда можно на них проCVSUPиться? Ежели да, то гуд - попробую. А экспериментировать на сервере в продакшене - не особо хочется. Возможно, что я параноик, но это личное мнение. :-)
А непосредственно про технологию подключения ng_netflow - я в курсе. :-)
У меня большие объемы трафика на VPN-серверах (mpd 3.18), userlevel-агенты сильно тормозят систему под такой нагрузкой, с ng_netflow никаких проблем. А еще userleve-агенты часто неправильно определяют ifindex для интерфейсов, а для меня это важно при учете трафика на динамических адресах, когда нельзя привязаться к клиентскому ip-адресу. Да, mpd 3.18 пришлось пропатчить, ну что делать. С 5.4-RELEASE ng_netflow входит в состав базовой системы, так что почти "все из коробки".Что касается ng_netflow в 6.0-RELEASE... Его тоже пришлось патчить...
Вот патч от Глеба Смирнова:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89417--- netflow.c.orig Mon May 16 23:10:08 2005
+++ netflow.c Mon Nov 28 15:57:31 2005
@@ -621,12 +621,9 @@
getnanotime(&ts);
header->unix_secs = htonl(ts.tv_sec);
header->unix_nsecs = htonl(ts.tv_nsec);
+ header->flow_seq = htonl(atomic_fetchadd_32(&priv->flow_seq,
+ header->count));
header->count = htons(header->count);
- header->flow_seq = htonl(atomic_load_acq_32(&priv->flow_seq));
-
- /* Flow sequence contains number of first record, so it
- is updated after being put in header. */
- atomic_add_32(&priv->flow_seq, header->count);
if (priv->export != NULL)
/* Should also NET_LOCK_GIANT(). */
mpd4 есть в портах -- ничего патчить не надо
" Все работает на 5.4, пробовал и на 5.3 -- считает с 600 ng интерфейсов, плюс с обычных. Для всего этого используется _один_ ng_netflow узел. К которому посредством множества связей присоединены все интерфейсы" -- а это как делается?
А можно конфиг ng_netflow посмотреть? А то лично у меня голова кругом идёт, когда я пытаюсь разобраться с netgraph. Пипец какой-то, все эти хуки, узлы, ребра, и прочая херня...
1. Чем оно лучше/хуже ipcad ?
2. Скомпилил в линуксе.
Собираю статистику flow-capture.
Явно даты в flow левые.
Вот такие в flow-print -f 5
0114.05:47:57.909 0114.05:47:57.909 ....Кстати, мне показалось, что это не коллектор, а таки сенсор.
Вот сегодня обновил на свою голову ! Ни одного пакета с ng* отловлено не было! Хорошо, что еще остальные iface считал. Указание force_family ng в конфиге ndsad'a ни к чему не привели. Пришлось к старому откатиться. Блин, у нетапа это уже в привычку входит, на каждый релиз 20 последующих багфиксов.