1.1, bobro (?), 13:59, 29/11/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кто нибудь пользовал этот коллектор
на потоках 2Мбит и больше ?
Раскажите, плиз, про нагрузку на процессор.
На сколько растет и на какож железе (процессор, память) ?
| |
1.3, Chris (??), 14:08, 29/11/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
При потоке 100 Мбит жрет до 50% максимум 2,4 Ghz проца... работает нормально, пока отклонений более 5% от провайдерского обсчета замечено не было. | |
1.5, Victor (??), 18:35, 29/11/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Теряет пакеты (до 10 %)
>Celeron 1100
теряет пакеты не ndsad, а libpcap
новая функция ULOG/divert тебе поможет - теряться ничего не будет | |
1.7, Skylord (??), 02:15, 30/11/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ndsad лучше всех работает с tun. Был бы другой такой же простой коллектор, который с меньше загрузкой нормально тянул бы tun - пользовал бы его. Но пока без альтернатив... А ng_netflow, как это ни удивительно, не всегда получается к ng прикрутить. Сейчас, вроде, что-то там сделали, а раньше (под бздей 5.4 - точно, ибо сам наступал на эти грабли) без патченья нетграфа хер будет на ng (а значит - mpd - а как тогда vpn считать?) ng_netflow садиться... Тип интерфейса ng был неподходящий...
В общем, ИМХО, недостаточно ng_netflow еще устаканился - часто то в нем, то в нетграфе меняют. Да и опять же - надо его индивидуально на каждый фейс вешать. А тут: запустил тулзу и она сама считает что надо. Разве что в конфиге поставить надо, какие фейсы игнорировать и какой трафик фильтровать, чтобы он даже не считался (это еще пинок в сторону ng_netflow, который тупо шлет все подряд)...
Но, естественно, за все приходится расплачиваться загрузкой проца... Так что... Се ля ви... | |
|
2.9, мимо шел (?), 13:06, 30/11/2005 [^] [^^] [^^^] [ответить]
| +/– |
Все работает на 5.4, пробовал и на 5.3 -- считает с 600 ng интерфейсов, плюс с обычных. Для всего этого используется _один_ ng_netflow узел. К которому посредством множества связей присоединены все интерфейсы. mpd4 умеет вставлять ng_tee узел в граф, к которому уже цепляется ng_netflow, mpd3.18 надо патчить, но патчи на каждом углу валяются -- проблем быть не должно. Интерфейсы, которые надо игнорировать просто не подключаешь к нетфлоу и он их игнорирует 8)
Впечатления от работы ng_netflow пока только положительные, загрузка процессора невелика, трафик бегает с минимальными задержками, кстати, в случае с userland решением величина задержек сильно возрастает при возрастании load averages. | |
|
3.10, Skylord (??), 21:25, 30/11/2005 [^] [^^] [^^^] [ответить]
| +/– |
> mpd3.18 надо патчить
Об том и речь. Не люблю я этого дела. Я привык к Бздишной "основательности" - все работает из коробки (дистро, порты - не важно). Всякие патчи - удел Линукса.... Эти - под mpd - уже внесли в stable? Или вообще куда-нибудь, откуда можно на них проCVSUPиться? Ежели да, то гуд - попробую. А экспериментировать на сервере в продакшене - не особо хочется. Возможно, что я параноик, но это личное мнение. :-)
А непосредственно про технологию подключения ng_netflow - я в курсе. :-) | |
|
4.11, Harunaga (?), 21:56, 30/11/2005 [^] [^^] [^^^] [ответить]
| +/– |
У меня большие объемы трафика на 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(). */
| |
|
3.14, slapsh (?), 17:11, 04/12/2005 [^] [^^] [^^^] [ответить]
| +/– |
" Все работает на 5.4, пробовал и на 5.3 -- считает с 600 ng интерфейсов, плюс с обычных. Для всего этого используется _один_ ng_netflow узел. К которому посредством множества связей присоединены все интерфейсы" -- а это как делается? | |
3.16, Dyr (ok), 12:54, 26/04/2006 [^] [^^] [^^^] [ответить]
| +/– |
А можно конфиг ng_netflow посмотреть? А то лично у меня голова кругом идёт, когда я пытаюсь разобраться с netgraph. Пипец какой-то, все эти хуки, узлы, ребра, и прочая херня... | |
|
|
1.8, OS (??), 10:28, 30/11/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
1. Чем оно лучше/хуже ipcad ?
2. Скомпилил в линуксе.
Собираю статистику flow-capture.
Явно даты в flow левые.
Вот такие в flow-print -f 5
0114.05:47:57.909 0114.05:47:57.909 ....
Кстати, мне показалось, что это не коллектор, а таки сенсор. | |
|
2.15, stealth (?), 06:38, 05/12/2005 [^] [^^] [^^^] [ответить]
| +/– |
Вот сегодня обновил на свою голову ! Ни одного пакета с ng* отловлено не было! Хорошо, что еще остальные iface считал. Указание force_family ng в конфиге ndsad'a ни к чему не привели. Пришлось к старому откатиться. Блин, у нетапа это уже в привычку входит, на каждый релиз 20 последующих багфиксов.
| |
|
|