LINUX.ORG.RU
решено ФорумAdmin

Опыт использования ipt_NETFLOW (формат v5)

 ,


1

1

Есть http://sourceforge.net/projects/ipt-netflow/

Интересует опыт использования на потоке от 300MBit/s с числом коннектов > 150000. Формат v5 (v9 работает странно и исправлять его нет смысла).

Данные принимаются nfcapd (из nfdump-1.6.12) локально. Интервал 5 минут.

Есть ли грабли или неадекватное поведение при нехватке памяти/cpu ?

Проблемы переполнения счетчика 32бит считаю что нет (гигабит в один коннект пока не реален)

★★★★★

на потоке от 300MBit/s с числом коннектов > 150000.

Пока никого таких нет, для затравки. Хотя и поток чуть поменьше, и количество flow сильно меньше:

# cat /proc/net/stat/ipt_netflow
Flows: active 34174 (peak 57583 reached 1d20h24m ago), mem 2936K
Hash: size 8192 (mem 64K), metric 3.8, 3.3, 1.0, 1.0. MemTraf: 3638819 pkt, 2711511 K (pdu 1369, 89610).
Timeout: active 300, inactive 15. Maxflows 2000000
Rate: 261617524 bits/sec, 44043 packets/sec; Avg 1 min: 255678128 bps, 43630 pps; 5 min: 255524563 bps, 43053 pps
cpu#  stat: <search found new, trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes>
Total stat: 37767921379 18010924592 789152120,    0    0    0    0, sock: 52567308 0 0, 75154823 K, traffic: 18800076712, 13256134 MB, drop: 0, 0 K

А какие проблемы ожидаются ? Тут ещё вопрос, на самом деле, в количестве ядер, сетевых платах...

(v9 работает странно и исправлять его нет смысла).

В чём тут беда ? Это интересно на ближайшую перспективу. В общем-то, тесты с небольшим потоком уже есть, пока не заметил ничего. В опытах v9 и IPv4+IPv6 с одного хоста.

AS ★★★★★
()
Ответ на: комментарий от AS

Работает отлично, сейчас нагрузка до 800мбит и потоках более 200к

# cat /proc/net/stat/ipt_netflow
ipt_NETFLOW version 1.8.2, srcversion (null)
Flows: active 190493 (peak 396783 reached 9d3h1m ago), mem 31252K, worker delay 3/1000.
Hash: size 1048576 (mem 8192K), metric 1.12 [1.09, 1.00, 1.00]. MemTraf: 12074930 pkt, 9508998 K (pdu 35, 6897), Out 82627460761 pkt, 60882623670 K.
Rate: 562833410 bits/sec, 93171 packets/sec; Avg 1 min: 591024959 bps, 96291 pps; 5 min: 601187468 bps, 97819 pps
cpu#  stat: <search found new [metric], trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes>
Total stat: 12642743332 78929798867 3709736789 [92.04],    0    0    0    0, sock: 191289075 0 0, 273483599 K, traffic: 82639535656, 59464973 MB, drop: 0, 0 K
cpu0  stat: 3678975360 23265945356 1191845193 [9.43],    0    0    0    0, sock:      0 0 0, 0 K, traffic: 24457790549, 25243566 MB, drop: 0, 0 K
cpu1  stat: 2668174524 16331053055 662960848 [4.78],    0    0    0    0, sock:      0 0 0, 0 K, traffic: 16994013903, 4625269 MB, drop: 0, 0 K
cpu2  stat: 3625316968 22959503526 1187076115 [10.39],    0    0    0    0, sock:      0 0 0, 0 K, traffic: 24146579641, 24893405 MB, drop: 0, 0 K
cpu3  stat: 2670276480 16373296931 667854633 [4.74],    0    0    0    0, sock: 191289075 0 0, 273483599 K, traffic: 17041151564, 4702731 MB, drop: 0, 0 K
Protocol version 5 (netflow). Timeouts: active 300, inactive 45. Maxflows 2000000
Natevents enabled, count start 1013097954, stop 1005351102.

gibbon
()

А зачем оно? Биллинг? Инфа по траффику историческая? Или требования регуляторов (вроде когда в прове работал обязывали 3 года чтоль хранить)? Может можно как-то проще задачу решить, нативными средствами.

А то более или менее разумных анализаторов нетфлоу не так много. С цысок собираю в manageengine netflow analyzer - один из немногих адекватных, хоть и платный да на яве писан... FlowViewer опенсорсный показался мне какой-то говноподелкой.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Ещё пару лет назад использовал ipt_NETFLOW для отдачи на flow-capture, а оттуда скриптами flow-report получаешь всё, что нужно. Если бы остался там, может и осуществил бы планы по потоковому анализу и выдаче отчётов.

А по NetFlow Analyzer'у под линукс, тут как и во всём линуксовом: скрипты пиши, мелкие утилиты есть. Зато как сделаешь под себя, останешься доволен как слон.

Кстати, на Pentium D нагрузка на проц вообще не была заметна. Гигабитный линк, чуть больше 50 пользователей. Drop'ы были, но после правки параметров запуска модуля, всё встало на свои места.

leader32
()
Ответ на: комментарий от blind_oracle

А зачем оно ? Биллинг ? Инфа по траффику историческая ?

Да всё, что хочешь.

Может можно как-то проще задачу решить,

Проще - может быть, но не так полно. Быстрее (с точки зрения нагрузки) - вряд ли: ipt_NETFLOW очень быстр.

нативными средствами.

А это чем не нативно ? В ALT, к примеру, apt-get install kernel-modules-ipt-netflow-<...>, и готово.

А то более или менее разумных анализаторов нетфлоу не так
много. С цысок собираю в manageengine netflow analyzer

Ну так хоть в него.
Или http://nfsen.sourceforge.net/ (этакий фронтэнд к nfdump)
Или http://www.netams.com/

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)

Всем спасибо.

Есть еще более быстрый способ - conntrack ( и с NAT-ом проблем нет). Раз в N минут делается дамп со сбросом счетчиков, а в остальное время смотрим события удаления соединений.

Но в нем не видно того, что дропается правилами в состоянии NEW. т.е. не видно неудачных попыток соединений, сканирований и т.п.

vel ★★★★★
() автор топика
13 сентября 2016 г.
Ответ на: комментарий от vel

Есть еще более быстрый способ - conntrack ( и с NAT-ом проблем нет). Раз в N минут делается дамп со сбросом счетчиков, а в остальное время смотрим события удаления соединений.

Но в нем не видно того, что дропается правилами в состоянии NEW. т.е. не видно неудачных попыток соединений, сканирований и т.п.

Поподробней, пожалуйста, как делается дамп, как смотрятся события удаления.

anonymous
()
Ответ на: комментарий от vel

спасибо.

btw, даже не знал, что в эту сторону копать можно. вик живи, век учись.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.