ipt_NETFLOW

[Max P]

Да вот патчик, у себя сейчас гоняю на локальном компе - пока вроде бы работает, не проверил пока только аггрегацию по адресам, накладывать на CVS версию

2.6.36_remove_nipquad_hipquad.patch.gz

[uropek]

Спасибо, будем пробовать.

[marikoda]

Вот такое начало сыпаться по вечерам в часы наибольшей нагрузки

Куда смотреть?

 

[221054.459997] BUG: soft lockup - CPU#0 stuck for 61s! [events/0:15]
[221054.462548] Modules linked in: iptable_raw ts_kmp xt_limit xt_state xt_string xt_tcpudp iptable_nat iptable_mangle nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack bridge iptable_filter ip_tables ipt_NETFLOW ipt_ULOG x_tables 8021q garp stp asus_atk0110 snd_hda_codec_via fbcon tileblit font bitblit softcursor vga16fb s3fb snd_hda_intel snd_hda_codec svgalib ppdev snd_hwdep snd_pcm parport_pc vgastate edac_core edac_mce_amd snd_timer i2c_piix4 snd soundcore snd_page_alloc lp parport raid10 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx usb_storage raid1 raid0 r8169 multipath mii ahci pata_atiixp linear
[221054.462548] CPU 0:
[221054.462548] Modules linked in: iptable_raw ts_kmp xt_limit xt_state xt_string xt_tcpudp iptable_nat iptable_mangle nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack bridge iptable_filter ip_tables ipt_NETFLOW ipt_ULOG x_tables 8021q garp stp asus_atk0110 snd_hda_codec_via fbcon tileblit font bitblit softcursor vga16fb s3fb snd_hda_intel snd_hda_codec svgalib ppdev snd_hwdep snd_pcm parport_pc vgastate edac_core edac_mce_amd snd_timer i2c_piix4 snd soundcore snd_page_alloc lp parport raid10 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx usb_storage raid1 raid0 r8169 multipath mii ahci pata_atiixp linear
[221054.462548] Pid: 15, comm: events/0 Not tainted 2.6.32-25-server #44-Ubuntu System Product Name
[221054.462548] RIP: 0010:[<ffffffff814a36ad>]  [<ffffffff814a36ad>] ip_forward+0x28d/0x420
[221054.462548] RSP: 0018:ffff880005803c88  EFLAGS: 00000292
[221054.462548] RAX: 0000000000000000 RBX: ffff880005803cb8 RCX: 0000000000000000
[221054.462548] RDX: 000000010150d835 RSI: ffff8800d75b2100 RDI: ffff880118589040
[221054.462548] RBP: ffffffff81012cb3 R08: 0000000000000001 R09: 0000000000000150
[221054.462548] R10: 000000000f71d7a3 R11: 0000000000000000 R12: ffff880005803c00
[221054.462548] R13: ffff8800c49a5d38 R14: ffff8800c49a5d00 R15: ffffffff8155f31c
[221054.462548] FS:  00007ffb64390700(0000) GS:ffff880005800000(0000) knlGS:0000000000000000
[221054.462548] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[221054.462548] CR2: 000000000275e9a8 CR3: 0000000001001000 CR4: 00000000000006f0
[221054.462548] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[221054.462548] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[221054.462548] Call Trace:
[221054.462548]  <IRQ>  [<ffffffff814a3610>] ? ip_forward+0x1f0/0x420
[221054.462548]  [<ffffffff814a179d>] ? ip_rcv_finish+0x12d/0x440
[221054.462548]  [<ffffffff814a1d25>] ? ip_rcv+0x275/0x360
[221054.462548]  [<ffffffff81534bb8>] ? vlan_hwaccel_do_receive+0x38/0xf0
[221054.462548]  [<ffffffff814724ca>] ? netif_receive_skb+0x38a/0x5d0
[221054.462548]  [<ffffffff81534db0>] ? __vlan_hwaccel_rx+0x140/0x230
[221054.462548]  [<ffffffffa0032596>] ? rtl8169_rx_interrupt+0x216/0x5b0 [r8169]
[221054.462548]  [<ffffffffa0032aad>] ? rtl8169_poll+0x3d/0x270 [r8169]
[221054.462548]  [<ffffffff81472fcf>] ? net_rx_action+0x10f/0x250
[221054.462548]  [<ffffffff8106d487>] ? __do_softirq+0xb7/0x1e0
[221054.462548]  [<ffffffff810132ec>] ? call_softirq+0x1c/0x30
[221054.462548]  <EOI>  [<ffffffff81014cb5>] ? do_softirq+0x65/0xa0
[221054.462548]  [<ffffffff8106cf48>] ? local_bh_enable_ip+0x98/0xa0
[221054.462548]  [<ffffffff8155a1c9>] ? _spin_unlock_bh+0x19/0x20
[221054.462548]  [<ffffffffa01af993>] ? netflow_scan_inactive_timeout+0x1a3/0x340 [ipt_NETFLOW]
[221054.462548]  [<ffffffffa01afb30>] ? netflow_work_fn+0x0/0x30 [ipt_NETFLOW]
[221054.462548]  [<ffffffffa01afb45>] ? netflow_work_fn+0x15/0x30 [ipt_NETFLOW]
[221054.462548]  [<ffffffff8107f6b7>] ? run_workqueue+0xc7/0x1a0
[221054.462548]  [<ffffffff8107f833>] ? worker_thread+0xa3/0x110
[221054.462548]  [<ffffffff81084250>] ? autoremove_wake_function+0x0/0x40
[221054.462548]  [<ffffffff8107f790>] ? worker_thread+0x0/0x110
[221054.462548]  [<ffffffff81083ed6>] ? kthread+0x96/0xa0
[221054.462548]  [<ffffffff810131ea>] ? child_rip+0xa/0x20
[221054.462548]  [<ffffffff81083e40>] ? kthread+0x0/0xa0
[221054.462548]  [<ffffffff810131e0>] ? child_rip+0x0/0x20

[marikoda]

В общем, flow отправлялось по сети с сервера на коллектор, когда поставили flow-capture локально, ошибки пропали. Заодно и LA упало с 5-6 до 0.05

[salexexpa]

Супер!!!

[marikoda]

Проблема повторяется

 

[396702.054555] netflow_send_pdu[0]: sendmsg error -1: data loss 76 pkt, 11421 bytes
[396721.000898] INFO: task bash:12069 blocked for more than 120 seconds.
[396721.004078] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[396721.011605] bash          D 0000000000000000     0 12069      1 0x00000000
[396721.011617]  ffff8800513458e8 0000000000000046 0000000000015bc0 0000000000015bc0
[396721.011627]  ffff88009610c890 ffff880051345fd8 0000000000015bc0 ffff88009610c4d0
[396721.011635]  0000000000015bc0 ffff880051345fd8 0000000000015bc0 ffff88009610c890
[396721.011644] Call Trace:
[396721.011661]  [<ffffffff815583ad>] schedule_timeout+0x22d/0x300
[396721.011678]  [<ffffffff810fb259>] ? __pagevec_free+0x59/0xb0
[396721.011687]  [<ffffffff81557656>] wait_for_common+0xd6/0x180
[396721.011697]  [<ffffffff8105a350>] ? default_wake_function+0x0/0x20
[396721.011706]  [<ffffffff815577bd>] wait_for_completion+0x1d/0x20
[396721.011716]  [<ffffffff8107fb55>] flush_cpu_workqueue+0x65/0xa0
[396721.011723]  [<ffffffff8107fcd0>] ? wq_barrier_func+0x0/0x20
[396721.011729]  [<ffffffff8107fe4c>] flush_workqueue+0x4c/0x80
[396721.011735]  [<ffffffff8107fe95>] flush_scheduled_work+0x15/0x20
[396721.011749]  [<ffffffff8133410c>] tty_ldisc_release+0x3c/0x90
[396721.011757]  [<ffffffff8132deed>] tty_release_dev+0x40d/0x5e0
[396721.011767]  [<ffffffff81156d7f>] ? __d_free+0x3f/0x60
[396721.011778]  [<ffffffff8132e0de>] tty_release+0x1e/0x30
[396721.011791]  [<ffffffff8114535f>] __fput+0xdf/0x1f0
[396721.011803]  [<ffffffff81145495>] fput+0x25/0x30
[396721.011814]  [<ffffffff811415dd>] filp_close+0x5d/0x90
[396721.011827]  [<ffffffff81067fbf>] put_files_struct+0x7f/0xf0
[396721.011839]  [<ffffffff81068084>] exit_files+0x54/0x70
[396721.011852]  [<ffffffff8106a49b>] do_exit+0x14b/0x380
[396721.011863]  [<ffffffff81079022>] ? __send_signal+0x172/0x360
[396721.011875]  [<ffffffff8106a725>] do_group_exit+0x55/0xd0
[396721.011887]  [<ffffffff8107af77>] get_signal_to_deliver+0x1d7/0x3d0
[396721.011902]  [<ffffffff81011a25>] do_signal+0x75/0x1c0
[396721.011958]  [<ffffffff810798b0>] ? kill_something_info+0x40/0x150
[396721.011971]  [<ffffffff81079a3e>] ? sys_kill+0x7e/0x90
[396721.011984]  [<ffffffff81011bcd>] do_notify_resume+0x5d/0x80
[396721.011997]  [<ffffffff8101247e>] int_signal+0x12/0x17

[marikoda]

Подкрутил:

 

sysctl net.netflow.active_timeout=300

sysctl net.netflow.sndbuf=10485760

 

пока полёт нормальный

[Max P]

кто нить под 2.6.37 уже запилил?

[marikoda]

пока полёт нормальный

Опять повторяется..

 

Лечится так (уже протестировано несколько раз):

 

1) Отключаем правила netflow в iptables

2) Ждём, пока LA упадёт ниже 1

3) Включаем правила

[silitra]

под CentOS

2.6.37

iptables-1.4.6

ipt_netflow-1.7

 

sysctl net.netflow.sndbuf=10485760

sysctl net.netflow.active_timeout=300

sysctl net.netflow.hashsize=32768

 

iptables -nvL

Chain INPUT (policy ACCEPT 97841 packets, 12M bytes)

pkts bytes target prot opt in out source destination

 

Chain FORWARD (policy ACCEPT 3 packets, 128 bytes)

pkts bytes target prot opt in out source destination

9394M 6874G NETFLOW all -- * * 0.0.0.0/0 0.0.0.0/0 NETFLOW

9394M 6874G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

 

Chain OUTPUT (policy ACCEPT 18M packets, 27G bytes)

pkts bytes target prot opt in out source destination

top - 14:29:59 up 1 day, 10:09, 1 user, load average: 0.00, 0.01, 0.05

Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie

Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 98.0%id, 0.0%wa, 1.0%hi, 1.0%si, 0.0%st

Cpu1 : 0.0%us, 1.0%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st

Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st

Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 4053456k total, 609332k used, 3444124k free, 70496k buffers

Swap: 6094844k total, 0k used, 6094844k free, 297924k cached

1.5 дня полет нормальный.

500 Мбит/c., тут же шейпер in/out 7к юзеров

 

 

 

 

Edited March 3, 2011 by silitra

[silitra]

рано радовался, с приходом вечера все встало колом.

пришлось откатится на 2.6.35.9

[lionsimba]

Возможно кому-то окажется полезным - PPA (deb-пакеты) с ipt_netflow для Ubuntu 10.04/10.10: https://launchpad.net/~lion-simba/+archive/stargazer

Использует DKMS, так что при обновлении ядра модуль будет сам пересобираться. Разумеется, при стабильном API.

 

PS. Данный пакет является также доказательством того, что для сборки ipt_netflow НЕ нужны полные исходники iptables и ядра.

[passer]

ipt_netflow у кого работает с iptables-1.4.12 ? У меня собирается, но не находит модуль при загрузке правил iptables.

[Мартен]

Данный пакет является также доказательством того, что для сборки ipt_netflow НЕ нужны полные исходники iptables и ядра.

Ага, тока хедеры нужны

[orlik]

Подскажите , кто сталкивался с подобным. с cisco 3400 делается миррорится трафик на порт сервера.

На сервере все собран bridge (eth1+dummy), в iptables

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

pkts bytes target prot opt in out source destination

5 372 NETFLOW all -- br0 * 0.0.0.0/0 0.0.0.0/0 NETFLOW

5 372 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0

 

т.е. трафик в iptables не попадает и

cat /proc/net/stat/ipt_netflow | grep Rate

Rate: 296 bits/sec, 0 packets/sec; Avg 1 min: 1222 bps, 0 pps; 5 min: 2210 bps, 0 pps

 

но на eth1 и br0 весь трафик виден (там ~300мбит)

 

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

Может кто подкинуть идею в чем может быть проблема ?

[orlik]

дополнение , проблема проявляется когда делаю копию трафика и tx и rx , если делать например только RX то все работает нормально

[NiTr0]

Накой в FORWARD пихать? С чего вы взяли вообще, что железка решит форвардить неведомый траффик? :) Я совсем не уверен, что она даже согласится принимать на ифейсе совершенно левый траффик, ей не предназначенный - скорее всего дропнет пакеты, предназначеные для совершенно левого с ее т.з. мак-адреса получателя.

[orlik]

Накой в FORWARD пихать? С чего вы взяли вообще, что железка решит форвардить неведомый траффик? :) Я совсем не уверен, что она даже согласится принимать на ифейсе совершенно левый траффик, ей не предназначенный - скорее всего дропнет пакеты, предназначеные для совершенно левого с ее т.з. мак-адреса получателя.

 

неуверен - потому что доку не читал

> raw promisc hack is not needed
> there is a more elegant way to capture port mirrored traffic:
>
> 1. create a bridge of eth0 and dummy0
> 2. put eth0 to promisc
> 3. add a "-i br0 -j NETFLOW" rule to FORWARD (possibly also -j DROP after that)

[NiTr0]

2. put eth0 to promisc

делали?

хотя у меня все равно сомнения, что iptables к пакетам, гуляющим по бриджу, будет иметь отношение...

[orlik]

2. put eth0 to promisc

делали?

хотя у меня все равно сомнения, что iptables к пакетам, гуляющим по бриджу, будет иметь отношение...

 

естественно делал, это глупый вопрос с вашей стороны, особенно если учесть, что я ранее уже писал что проблема наблюдается только при span и rx и tx.

 

P.S. net.bridge.bridge-nf-call-iptables = 1 - значение по умолчанию, можно поставить в 0 , тогда будет идти мимо iptables.

[orlik]

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

brctl setageing br0 0 

[crown]

Парни, нужна ваша помощь!

Centos 6, 2.6.32-131.21.1.el6.x86_64, iptables v1.4.7:

Eth0 –management interface;

Eth1 подключен к “span port-y” + promisc mode.

Трафик порядка 10 MB :) Tcpdump видит трафик. Fprob работает без проблем, но теряется информация 3 уровня (весь трафик выдает в одном напровление (libcap ограничения!)).

Нашел ipt_netflow 1,6, скомпилирывал, все ОК! (ядро raw_promisc.patch –ом не патчил! ) README.promisc напосанно, что достаточно создать бридж!!!

iptables: Loading additional modules: ipt_NETFLOW [ OK ]

sysctl.conf >> net.bridge.bridge-nf-call-iptables = 1

 

Brctl addbr br0

brctl addif br0 eth1

Ifconfig Br0 up >> Трафика нема, Ок >> ifconfig br0 promisc. Трафик ОК!

Iptables –F

iptables -A FORWARD -j NETFLOW

iptables -A INPUT -j NETFLOW

iptables -A OUTPUT -j NETFLOW

cat /proc/net/stat/ipt_netflow ну нема трафика!!! (несколько битов всего)

что интересно:

ifstat –I eth1 -b >> 9587

ifstat –I br0 -b >> ~ 9025 ну трафик есть же!!!

Пробывал отключить обучение мак адресам в бридже.. трафика нема :(

 

Кстати, если вписать iptables –I FORWARD/INOUT –I br0 –j NETFLOW и смотреть counter-ы. показывает 0-и. То есть iptables невидет трафик на бридже!!!

P.S.

net.bridge.bridge-nf-call-iptables = 0 эфект аналогичный :(

 

______________________________

06/01/2012

 

да, забыл указать, что система не является gateway-ом, а только пасивно слушает span траффик. т.е. -t raw PREROUTING -j NETFLOW непашет :(. да и вообше пишет ip_tables: NETFLOW target: only valid in filter table, not raw

Edited January 6, 2012 by crown

[pfexec]

Может лучше взять правильный софт, например pmacct ? Данный продукт может слушать на интерфейсе (в промиск режиме использую libpcap)и на весть этот трафик генерить netflow

всё что на либпкапе - уныние а не неправильный софт. так что да, надо побеждать либо ipt_netflow, либо ставить фряшечку с ng_netflow. :)

[crown]

Парни, нужна ваша помощь!

Centos 6, 2.6.32-131.21.1.el6.x86_64, iptables v1.4.7:

Eth0 –management interface;

Eth1 подключен к “span port-y” + promisc mode.

Трафик порядка 10 MB :) Tcpdump видит трафик. Fprob работает без проблем, но теряется информация 3 уровня (весь трафик выдает в одном напровление (libcap ограничения!)).

Нашел ipt_netflow 1,6, скомпилирывал, все ОК! (ядро raw_promisc.patch –ом не патчил! ) README.promisc напосанно, что достаточно создать бридж!!!

iptables: Loading additional modules: ipt_NETFLOW [ OK ]

sysctl.conf >> net.bridge.bridge-nf-call-iptables = 1

 

Brctl addbr br0

brctl addif br0 eth1

Ifconfig Br0 up >> Трафика нема, Ок >> ifconfig br0 promisc. Трафик ОК!

Iptables –F

iptables -A FORWARD -j NETFLOW

iptables -A INPUT -j NETFLOW

iptables -A OUTPUT -j NETFLOW

cat /proc/net/stat/ipt_netflow ну нема трафика!!! (несколько битов всего)

что интересно:

ifstat –I eth1 -b >> 9587

ifstat –I br0 -b >> ~ 9025 ну трафик есть же!!!

Пробывал отключить обучение мак адресам в бридже.. трафика нема :(

 

Кстати, если вписать iptables –I FORWARD/INOUT –I br0 –j NETFLOW и смотреть counter-ы. показывает 0-и. То есть iptables невидет трафик на бридже!!!

P.S.

net.bridge.bridge-nf-call-iptables = 0 эфект аналогичный :(

 

______________________________

06/01/2012

 

да, забыл указать, что система не является gateway-ом, а только пасивно слушает span траффик. т.е. -t raw PREROUTING -j NETFLOW непашет :(. да и вообше пишет ip_tables: NETFLOW target: only valid in filter table, not raw

 

update:

 

AS it's not a router, net.ipv4.ip_forward should be 0!!! After that I;m able to use Iptables for raw table!!! cat /proc/net/stat/ipt_netflow shows traffic. But the problem is that netflow analyzer (manegeengine) still shows IP counts as "single direction traffic". in for br0 out for eth1 :( So, why do I need netflow than if I could use libcap :(

Edited January 12, 2012 by crown

[Dyr]

Add more smiles! ;-) :-) o_O ^_^ And exclamation marks!!! In english, of course!!!

 

P.S. ebtables?

 

 

Edited January 12, 2012 by Dyr