Jump to content
Калькуляторы

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

2.6.36_remove_nipquad_hipquad.patch.gz

Share this post


Link to post
Share on other sites

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

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

 

[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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Супер!!!

Share this post


Link to post
Share on other sites

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

 

[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

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

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

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

Share this post


Link to post
Share on other sites

под 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 by silitra

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Подскажите , кто сталкивался с подобным. с 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 , все сразу же начинает работать и обсчитываться.

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Накой в 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)

Share this post


Link to post
Share on other sites

2. put eth0 to promisc

делали?

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

Share this post


Link to post
Share on other sites

2. put eth0 to promisc

делали?

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

brctl setageing br0 0 

Share this post


Link to post
Share on other sites

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

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 by crown

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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 by crown

Share this post


Link to post
Share on other sites

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

 

P.S. ebtables?

 

 

Edited by Dyr

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.