Собственно почему ipt_netflow и как так получилось
Собственно
ipt_netflow — это модуль ядра Linux, который собирает и экспортит Netflow v5, а также модуль для iptables, через который управляется то, что именно мы собираемся экспортить.
Почему
Причина возникновения этого проекта — это отсутствие возможностей в Linux (февраль 2008 год) экспортить Netflow под большим трафиком. До 300Mbit можно легко использовать ipcad через ULOG, но если трафики выше, то мы получаем 100% CPU на машине по причине бурного контекстсвитчинга (порог наступал при 60-70к в секунду).
Для FreeBSD эту проблему решает ng_netflow, сидящий в ядре, но ставить FreeBSD не хотелось, а покупать Cisco для небольшого провайдера было слишком дорогим удовольствием.
Как
Чуть более недели я убеждал будущего автора ipt_netflow сделать для Linux такую радость, и он поддался. Все должно быть в ядре, паралелиться, экспортить в несколько направлений, агрегировать сети и порты по аналогии с ipcad и управляться через iptables (это удобно).
Сначала посмотрели, что умеет делать conntrack, это показалось довольно тяжелым механизмом. Кроме того, там нет (не было на тот момент, сейчас не знаю) информации об интерфейсах и ToS, и аккаунтинг, собираемый в conntrack, нужно было бы конвертить в правила поведения Netflow (в том виде, как это реализовано у Cisco: экспортим активные потоки раз в 30 минут и не активные потоки через 15 секунд, отличается и понятие потока), ну и патчить постоянно conntrack при выходе нового кернела еще более не хотелось. В итоге код получился не связанный с conntrack и может работать на машине там, где conntrack вообще не загружен.
Так
Примерно через год после создания и эксплуатации ipt_netflow сделали публичным на sourceforge.net. В январе 2009 мы попытались поговорить с бывшим майнтейнером iptables Harald Welte, чтобы найти способ включить проект в kernel. Он ответил, что дизайн «not the right way», и также сказал, что сейчас не занимается iptables, переслав нашу переписку Pablo Neira Ayuso, который являлся более активным участником iptables. Pablo, занимающийся ULOG2, сообщил нам, что все то, что делается в conntrack, это более адекватно, и в реализации ULOG2 он всячески акцентировался на IPFIX, но к сожалению “IPFIX plugin is not ready”. После наших возражений о том, что все не так просто, и кроме того, Linux роутеры могут быть и без conntrack, мы закончили темой с Patrick McHardy, что надо бы проверить кто быстрее и все такое, а без выяснения истины нет смысла добавлять код в ядро. На этом все и закончилось.
Получилось
Прошел еще один год, ipt_netflow код так и не попал в Linux kernel, хотя все так же справляется с нагрузкой, для которой он был сделан.
Желающие сделать тесты производительности могут изменить эту ситуацию, сравнив с ULOG2 и отправив результаты майненерам iptables.
Автор ipt_netflow рекомендует использовать последнюю версию из cvs, а не 1.6, что висит на sourceforge. Есть планы довести совместимость до current stable kernel, в котором есть приятные вещи для больших нагрузок на IRQ.
А тем временем машина, для которой он был сделан, все так же работает:
root@:~# cat /proc/net/stat/ipt_netflow
Flows: active 63754 (peak 2000000 reached 192d7h48m ago), mem 5478K
Hash: size 200000 (mem 1562K), metric 1.2, 1.2, 1.0, 1.0. MemTraf: 63379321 pkt, 55989408 K (pdu 45, 4238).
Timeout: active 1800, inactive 15. Maxflows 2000000
Rate: 786605950 bits/sec, 116169 packets/sec; Avg 1 min: 723693351 bps, 108527 pps; 5 min: 757117696 bps, 112801 pps
ipt_netflow — это модуль ядра Linux, который собирает и экспортит Netflow v5, а также модуль для iptables, через который управляется то, что именно мы собираемся экспортить.
Почему
Причина возникновения этого проекта — это отсутствие возможностей в Linux (февраль 2008 год) экспортить Netflow под большим трафиком. До 300Mbit можно легко использовать ipcad через ULOG, но если трафики выше, то мы получаем 100% CPU на машине по причине бурного контекстсвитчинга (порог наступал при 60-70к в секунду).
Для FreeBSD эту проблему решает ng_netflow, сидящий в ядре, но ставить FreeBSD не хотелось, а покупать Cisco для небольшого провайдера было слишком дорогим удовольствием.
Как
Чуть более недели я убеждал будущего автора ipt_netflow сделать для Linux такую радость, и он поддался. Все должно быть в ядре, паралелиться, экспортить в несколько направлений, агрегировать сети и порты по аналогии с ipcad и управляться через iptables (это удобно).
Сначала посмотрели, что умеет делать conntrack, это показалось довольно тяжелым механизмом. Кроме того, там нет (не было на тот момент, сейчас не знаю) информации об интерфейсах и ToS, и аккаунтинг, собираемый в conntrack, нужно было бы конвертить в правила поведения Netflow (в том виде, как это реализовано у Cisco: экспортим активные потоки раз в 30 минут и не активные потоки через 15 секунд, отличается и понятие потока), ну и патчить постоянно conntrack при выходе нового кернела еще более не хотелось. В итоге код получился не связанный с conntrack и может работать на машине там, где conntrack вообще не загружен.
Так
Примерно через год после создания и эксплуатации ipt_netflow сделали публичным на sourceforge.net. В январе 2009 мы попытались поговорить с бывшим майнтейнером iptables Harald Welte, чтобы найти способ включить проект в kernel. Он ответил, что дизайн «not the right way», и также сказал, что сейчас не занимается iptables, переслав нашу переписку Pablo Neira Ayuso, который являлся более активным участником iptables. Pablo, занимающийся ULOG2, сообщил нам, что все то, что делается в conntrack, это более адекватно, и в реализации ULOG2 он всячески акцентировался на IPFIX, но к сожалению “IPFIX plugin is not ready”. После наших возражений о том, что все не так просто, и кроме того, Linux роутеры могут быть и без conntrack, мы закончили темой с Patrick McHardy, что надо бы проверить кто быстрее и все такое, а без выяснения истины нет смысла добавлять код в ядро. На этом все и закончилось.
Получилось
Прошел еще один год, ipt_netflow код так и не попал в Linux kernel, хотя все так же справляется с нагрузкой, для которой он был сделан.
Желающие сделать тесты производительности могут изменить эту ситуацию, сравнив с ULOG2 и отправив результаты майненерам iptables.
Автор ipt_netflow рекомендует использовать последнюю версию из cvs, а не 1.6, что висит на sourceforge. Есть планы довести совместимость до current stable kernel, в котором есть приятные вещи для больших нагрузок на IRQ.
А тем временем машина, для которой он был сделан, все так же работает:
root@:~# cat /proc/net/stat/ipt_netflow
Flows: active 63754 (peak 2000000 reached 192d7h48m ago), mem 5478K
Hash: size 200000 (mem 1562K), metric 1.2, 1.2, 1.0, 1.0. MemTraf: 63379321 pkt, 55989408 K (pdu 45, 4238).
Timeout: active 1800, inactive 15. Maxflows 2000000
Rate: 786605950 bits/sec, 116169 packets/sec; Avg 1 min: 723693351 bps, 108527 pps; 5 min: 757117696 bps, 112801 pps
1 комментарий