[NiTr0]

Надо будет отключить conntrack фичи по умолчанию, чтоб не было таких проблем.

А не проще пару патчей втянуть? http://ehc.ac/p/leaf/bering-uclibc/ci/master/tree/repo/iptables/ - лежит пара патчей с которыми собирается под 3.14 (патчи не мои, нашел в каком-то дистре - mageia что ли).

[aabc]

Надо будет отключить conntrack фичи по умолчанию, чтоб не было таких проблем.

А не проще пару патчей втянуть? http://ehc.ac/p/leaf/bering-uclibc/ci/master/tree/repo/iptables/ - лежит пара патчей с которыми собирается под 3.14 (патчи не мои, нашел в каком-то дистре - mageia что ли).

Спасибо. Эти патчи "втянуты" ещё в сентябре 2013. Модуль компилится с 2.6.18 по 3.16.

[aabc]

Если кому интересно, у Korxif была проблема, что сама машинка не справлялась даже без модуля. На другой машине (мать S5500BC) спокойно держит 10Gbit с >1500000 pps.

 

Rate: 11479090850 bits/sec, 1611313 packets/sec

 

Из последних фич (в git):

 

- Поддержка options templates для netflow v9/ipfix. В них - общая статистика работы модуля.

- Flow sampling (deterministic/random/hash). С соотв. экспортом sampling настроек и статистики. Sampling работает и для netflow v5.

- Экспорт имен интерфейсов в v9/ipfix.

- Мониторинг и управление модулем по snmp (dlmod плюгин к net-snmp).

Изменено 11 сентября, 2014 пользователем aabc

[Megas]

Народ, подскажите, уже сутки воюю с этой шутки, задача не совсем простоя: принять mirror трафик с порта на jun, внутри сыпятся vlan, то есть порт транковый.

Пару раз делал что работало и трафик был, nfdump даже отрисовал, потом перезагрузка и снова не работает, востановить не получается. Сейчас есть бридж: br0 в котором по tcpdump видно все пакеты.

Логирование таблиц raw, filter в iptables показывает что кроме текущего ssh подключения к серверу, другого трафика просто нету, хотя tcpdump говорит об обратном.

 

Складывается впечатление что iptables отбрасывает трафик или не обрабатывает его, из-за того что он приходит с mirror, rp_filter для всех в 0, куда еще копнуть?

[Megas]

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

net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-filter-vlan-tagged=1

[Megas]

Похоже для CentOS что-то поменялось и natevents не работает.

 

options ipt_NETFLOW hashsize=160000 destination=127.0.0.1:6343 protocol=9 natevents=1

 

Sep 27 21:18:14 last kernel: [ 7432.380799] ipt_NETFLOW: Unknown parameter `natevents'

 

nf_conntrack_ftp 12929 1 nf_nat_ftp

nf_conntrack_pptp 12214 1 nf_nat_pptp

nf_conntrack_proto_gre 6891 1 nf_conntrack_pptp

nf_conntrack_ipv4 9946 15 iptable_nat,nf_nat

nf_conntrack 80313 12 xt_state,xt_CONNMARK,iptable_nat,vzrst,vzcpt,nf_nat_ftp,nf_conntrack_ftp,nf_nat_pptp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_nat,nf_conntrack_ipv4

nf_defrag_ipv4 1531 1 nf_conntrack_ipv4

[NiTr0]

Похоже для CentOS что-то поменялось и natevents не работает.

Скорее в гите что-то поменялось в опциях сборки...

[aabc]

Megas ./configure --enable-natevents

[Antares]

под ядро 3.17 не собирается

 

make all install
Compiling for kernel 3.17.0
make -C /lib/modules/3.17.0/build M=/install/ipt-netflow modules CONFIG_DEBUG_INFO=y
make[1]: Entering directory `/usr/src/kernels/linux-3.17'
 CC [M]  /install/ipt-netflow/ipt_NETFLOW.o
/install/ipt-netflow/ipt_NETFLOW.c:1304: ошибка: expected ‘)’ before ‘*’ token
/install/ipt-netflow/ipt_NETFLOW.c:1321: ошибка: expected ‘)’ before ‘*’ token
/install/ipt-netflow/ipt_NETFLOW.c:1356: ошибка: expected ‘)’ before ‘*’ token
/install/ipt-netflow/ipt_NETFLOW.c:1373: ошибка: expected ‘)’ before ‘*’ token
/install/ipt-netflow/ipt_NETFLOW.c:1463: ошибка: expected ‘)’ before ‘*’ token
/install/ipt-netflow/ipt_NETFLOW.c:1492: ошибка: expected ‘)’ before ‘*’ token
/install/ipt-netflow/ipt_NETFLOW.c:1525: ошибка: expected ‘)’ before ‘*’ token
/install/ipt-netflow/ipt_NETFLOW.c:1589: ошибка: ‘hsize_procctl’ не описан в этой области (не в функции)
/install/ipt-netflow/ipt_NETFLOW.c:1595: ошибка: ‘sndbuf_procctl’ не описан в этой области (не в функции)
/install/ipt-netflow/ipt_NETFLOW.c:1602: ошибка: ‘destination_procctl’ не описан в этой области (не в функции)
/install/ipt-netflow/ipt_NETFLOW.c:1610: ошибка: ‘aggregation_procctl’ не описан в этой области (не в функции)
/install/ipt-netflow/ipt_NETFLOW.c:1624: ошибка: ‘flush_procctl’ не описан в этой области (не в функции)
/install/ipt-netflow/ipt_NETFLOW.c:1630: ошибка: ‘protocol_procctl’ не описан в этой области (не в функции)
/install/ipt-netflow/ipt_NETFLOW.c:1687: ошибка: ‘natevents_procctl’ не описан в этой области (не в функции)
make[2]: *** [/install/ipt-netflow/ipt_NETFLOW.o] Ошибка 1
make[1]: *** [_module_/install/ipt-netflow] Ошибка 2
make[1]: Leaving directory `/usr/src/kernels/linux-3.17'
make: *** [ipt_NETFLOW.ko] Ошибка 2

[Tamahome]

Добрый день,

ipt_NETFLOW version 2.0, srcversion 378CA032A71B2B36F44E57F

Пишется это так (/usr/bin/nfcapd -w -D -p 9997 -S 2 -t 60 -I Nat -T nel -l /opt/flows/ -x "gzip -8 /opt/flows/%f")

Читается на другой машине (nfdump: Version: NSEL-NEL1.6.12 $Date: 2014-04-02 20:08:48)

nfdump -R ... 'nat event add' -onel

Выводит время в виде 1970-01-01 05:00:00.058.

Куда копать?

Изменено 8 октября, 2014 пользователем Tamahome

[aabc]

Tamahome, каким протоколом экспортируете? Попробуйте другой.

 

Посмотреть пакеты, которые шлет модуль можно с помощью Wireshark.

Изменено 8 октября, 2014 пользователем aabc

[Tamahome]

Tamahome, каким протоколом экспортируете? Попробуйте другой.

ipt_NETFLOW protocol version 9 (NetFlow) enabled.

ipt_NETFLOW: enable natevents.

 

Пойду дампы запишу, действительно.

[Tamahome]

Проблема в nfdump откатил nfcapd до 1.6.11 - все ок, странно nfdump-1.6.11 не читает файлы nfcapd-1.6.12, наоборот же всё ок.

ipt_NETFLOW не причём похоже.

Изменено 8 октября, 2014 пользователем Tamahome

[pavel.odintsov]

Меня давно мучает вопрос, почему ipt_netflow не реализовать в user space? Никакого профита при живых pf_ring от размещения в ядре нету, один негатив - постоянные падения и доточка под ядра.

[aabc]

pavel.odintsov

 

"постоянные падения" - работает годами и не падает.

 

"почему не реализовать в user space при pf_ring" — PF_RING случаем не модуль ядра? Причем, с багами и доточкой под ядра.

grep KERNEL_VERSION https://svn.ntop.org/svn/ntop/trunk/PF_RING/kernel/pf_ring.c
grep -i fix https://svn.ntop.org/svn/ntop/trunk/PF_RING/ChangeLog

Изменено 9 октября, 2014 пользователем aabc

[pavel.odintsov]

За почти полтора года использования PF_RING на различных ядрах я не фиксировал ни единого его падения, разработчики очень оперативно добавляют поддержку новых ядер и новых фич, при этом не нарушая стбильность.

 

ipt_NETFLOW падал у меня где только можно, падал на 2.6.39 squeeze backports, падал на 2.6.32 squeeze stable, падал на 3.2 wheezy stable (дада, ECC, Xeon, Dell). Сначала он валил мне боевой роутер и мы не могли понять - что творится и почему, эвристически определили причину - ipt_netflow и падения прекратились. Перенесли анализ трафика на некритичную машину на mirror порту, но она падала раз в день и такое нас решительно не устраивало - мои техники задолбались бегать смотреть, что творится с машиной и почему произошел очередной лок.

 

После этого мой коллега Pavel Boldin почти месяц занимался выпилкой и полировкой блокировок в ipt_netflow, что было выражено в набор патчей: http://sourceforge.net/p/ipt-netflow/bugs-requests-patches/62/ после этого ipt_netflow падать перестал где-то на месяц, но после очередного обновления (пришлось - поменялась версия ядра) все опять начало падать и на тех же самых ошибках - обращение к разделяемым ресурсам без mutex'ов (именно то, с чем воевал Pavel Boldin, получается, зря?), но в очередной раз тратить время квалифицированного спеца мне стало жалко и мы просто выкинули ipt_netflow заменив его на простенькую самопальную обертку на pf_ring.

 

Я никоим образом не хочу сказать, что продукт плох, я лишь хочу сказать, что стабильность работы моудля ядра удручает и постоянные вои юзеров в теме "опять ядро встало колом" - это подтверждают. Поэтому и родилось предложение - вынести этот код из ядра, пусть падает себе в юзер спейсе до посинения, но систему не валит.

[aabc]

За почти полтора года использования PF_RING на различных ядрах я не фиксировал ни единого его падения,

 

Люди пользуются ipt-netflow 1.7.1 четыре с половиной года и не фиксируют ни одного падения.

 

Ссылку на "kernel panic PF_RING" я дал. Могу дать ещё: https://www.google.com/search?q=kernel+panic+OR+crash+OR+oops+PF_RING

 

разработчики очень оперативно добавляют поддержку новых ядер и новых фич, при этом не нарушая стбильность.

 

Я вот только-что очень оперативно добавил поддержку 3.17 не нарушив стабильность. И вообще, поддержка компиляции на новом ядре как правило не влияет на стабильность. Последний раз на стабильность влияла свежая поддержка ipv6, в редких случаях при приходе пакетов с определенными options, что я не мог протестировать без полноценной нагрузки, это было исправлено. Еще модуль не выдерживал 10гбит нагрузки, это было исправлено.

 

ipt_NETFLOW падал у меня где только можно, падал на 2.6.39 squeeze backports, падал на 2.6.32 squeeze stable, падал на 3.2 wheezy stable (дада, ECC, Xeon, Dell). Сначала он валил мне боевой роутер и мы не могли понять - что творится и почему, эвристически определили причину - ipt_netflow и падения прекратились. Перенесли анализ трафика на некритичную машину на mirror порту, но она падала раз в день и такое нас решительно не устраивало - мои техники задолбались бегать смотреть, что творится с машиной и почему произошел очередной лок.

 

Чтоб не было "лока" настройте watchdog.

 

Чтоб не было багов их надо репортить.

 

Чтоб уменьшить вероятность багов надо юзать не девелопмент версию из git, а стабильный релиз.

 

После этого мой коллега Pavel Boldin почти месяц занимался выпилкой и полировкой блокировок в ipt_netflow, что было выражено в набор патчей: http://sourceforge.net/p/ipt-netflow/bugs-requests-patches/62/ после этого ipt_netflow падать перестал где-то на месяц, но после очередного обновления (пришлось - поменялась версия ядра)

 

Спасибо ему!

 

все опять начало падать и на тех же самых ошибках - обращение к разделяемым ресурсам без mutex'ов (именно то, с чем воевал Pavel Boldin, получается, зря?),

 

Не зря.

 

но в очередной раз тратить время квалифицированного спеца мне стало жалко и мы просто выкинули ipt_netflow заменив его на простенькую самопальную обертку на pf_ring.

 

Вы гении.

 

Я никоим образом не хочу сказать, что продукт плох, я лишь хочу сказать, что стабильность работы моудля ядра удручает и постоянные вои юзеров в теме "опять ядро встало колом" - это подтверждают.

 

Как я уже сказал, кто-то юзает годами - "поставил и забыл". Кое у кого глючная память, после замены планок глюки пропали. Третьи юзают экспериментальную фичу, которая не слишком интенсивно тестировалась. Четвертые случайный коммит из git, для которого давно есть исправления.

 

Когда у людей все хорошо они как правило об этом не пишут, поэтому глюки заметнее.

 

Поэтому и родилось предложение - вынести этот код из ядра, пусть падает себе в юзер спейсе до посинения,

 

PR_RING - модуль в ядре, так что ваши аргументы не попадают.

 

ipt-netflow - таргет для iptables, предназначен для использования по аналогии с таргетом LOG, при этом вместо syslog отсылает данные по NetFlow/IPFIX. Если сделать "самопальную обертку на pf_ring", то это будет что-то другое, другой "продукт".

 

но систему не валит.

 

На данный момент (в git head и 2.0.1) ничего не падает и не валит. Не закрытых жалоб нет.

 

Если у вас ipt-netflow вызывает отвращение, то я тут поделать не могу, я его делал и фиксил глюки для тех кто его использует.

[pavel.odintsov]

Ну что же я могу сказать - хозяин барин. А спасибо, все же, говорить стоит не только автору, но и компании, которая эту разработку спонсировала - можете указать Fastvps Eesti OU, а Павлу благодарность я передал.

[pppoetest]

Стоит 1.7.2 пару лет, перебои только по питалову. Автору - спасибо.

[Antares]

Я вот только-что очень оперативно добавил поддержку 3.17 не нарушив стабильность.

Спасибо, собралось )))

[aabc]

Ну что же я могу сказать - хозяин барин. А спасибо, все же, говорить стоит не только автору, но и компании, которая эту разработку спонсировала - можете указать Fastvps Eesti OU, а Павлу благодарность я передал.

 

Вы не спонсировали эту разработку. Про эту компанию я впервые слышу, тем более никаких денег от неё не получал.

Изменено 9 октября, 2014 пользователем aabc

[pavel.odintsov]

Вы бы хотя бы Павла упомянули в readme или хотя бы коде, хотя решать Вам, безусловно :)

Изменено 9 октября, 2014 пользователем pavel.odintsov

[aabc]

Вы правда думаете,

Я ничего не думаю.

 

Вы его даже ни в readme, ни в коде не поблагодарили - это просто по человечески не хорошо.

 

Это ложь. Pavel Boldin атрибутирован четыре раза в Changelog:

 

* 73a3fcd calculate hash only once (Pavel Boldin)

* 7574cd3 return of instanteous flush (thx Pavel Boldin)

* 43627cb Prevent flush on unload (Pavel Boldin).

* 900a55f Fix: locking race condition. Replacing spin_lock with mutex_lock (Pavel Boldin).

 

судя по Вашей реакции и Вашему откровенно хамскому поведению на совершенно тривиальную критику - мне лично все ясно.

 

Я вам не хамил.

 

1. Про компанию "Fastvps Eesti OU" я впервые слышу.

2. Ни в какие отношения я с ней не вступал.

3. Никаких денег ("спонсирования") от неё я не получал.

 

Это научный факт. Если вы кого-то спонсировали, то обращайтесь к ним, а не ко мне.

 

Лично я признателен за оказанную помощь Pavel Boldin'у - реальному человеку, который со мной общался.

 

Мне не жалко спасибо сказать, упомянуть, подписать и т.п., даже за простой багрепорт. В каждом тикете я благодарю людей за помощь (упомянутый #62 не исключение). Каждый коммит со сторонним патчем идет с указанием авторства. Но, почему надо подтверждать публично якобы "спонсирование" (денежные отношения) о котором я впервые слышу? Я денег у вас не брал, это факт. Вам надо, чтоб я признал обратное? Странное желание.

[aabc]

Вы бы хотя бы Павла упомянули в readme или хотя бы коде, хотя решать Вам, безусловно :)

 

Если не достаточно записи в Changelog, то можно завести в проекте файл AUTHORS, как это обычно делают, и перечислить там. У меня совершенно нет желания кого-то недоблагодарить. Хорошо, что сказали, я же не знаю, что кто думает (и, возможно, тайно обижен) пока люди не скажут. Считал, что упоминания в Changelog достаточно (как этого достаточно в linux kernel).

Изменено 9 октября, 2014 пользователем aabc

[aabc]

Вы бы хотя бы Павла упомянули в readme или хотя бы коде, хотя решать Вам, безусловно :)

 

Если не достаточно записи в Changelog, то можно завести в проекте файл AUTHORS, как это обычно делают, и перечислить там. У меня совершенно нет желания кого-то недоблагодарить. Хорошо, что сказали, я же не знаю, что кто думает (и, возможно, тайно обижен) пока люди не скажут. Считал, что упоминания в Changelog достаточно (как этого достаточно в linux kernel).

 

Сделал файл CREDITS: https://github.com/aabc/ipt-netflow/blob/master/CREDITS

pavel.odintsov, спасибо, думаю это хорошая идея.

Изменено 9 октября, 2014 пользователем aabc