LAN Flood: MPCP Pause

[dobriloff]

Здравейте,

 

За последните 2 седмици в локалната мрежа се случва някакъв станен Flood с пауза пакети вероятно причинени от кофти устройство.

В tcpdump вижда следното:

Opcode: MPCP Pause

Opcode: MPCP Pause

Opcode: MPCP Pause

Като отворя дъмпа в Wireshark се вижда малко повече но пак недостатъчно:

Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: Spanning-tree-(for-bridges)_01 (01:80:c2:00:00:01)

 

и така по няколко десетки в секунда. докато в един момент крашва лан картата

 

dmesg:

[172669.795399] irq 38: nobody cared (try booting with the "irqpoll" option)
[172669.795438] Pid: 0, comm: swapper Not tainted 2.6.32-layer7-imq-amd64 #2
[172669.795442] Call Trace:
[172669.795446]  <IRQ>  [<ffffffff81074ea1>] ? __report_bad_irq+0x30/0x7d
[172669.795464]  [<ffffffff81074ff5>] ? note_interrupt+0x107/0x16e
[172669.795471]  [<ffffffff8107559c>] ? handle_edge_irq+0xd2/0xff
[172669.795479]  [<ffffffff8100ddd1>] ? handle_irq+0x17/0x1d
[172669.795485]  [<ffffffff8100d4b3>] ? do_IRQ+0x54/0xb2
[172669.795491]  [<ffffffff8100c293>] ? ret_from_intr+0x0/0xa
[172669.795495]  <EOI>  [<ffffffff81012177>] ? mwait_idle+0x6d/0x72
[172669.795506]  [<ffffffff81012129>] ? mwait_idle+0x1f/0x72
[172669.795512]  [<ffffffff8100abfb>] ? cpu_idle+0x9d/0xd7
[172669.795516] handlers:
[172669.795532] [<ffffffffa000c2a4>] (e1000_msix_other+0x0/0xa5 [e1000e])
[172669.795575] Disabling IRQ #38
[172676.467306] ------------[ cut here ]------------
[172676.467323] WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0xef/0x18e()
[172676.467328] Hardware name: To be filled by O.E.M.
[172676.467332] NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0 timed out
[172676.467336] Modules linked in: tun bridge ipt_MASQUERADE xt_layer7 iptable_nat nf_nat xt_comment nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp xt_multiport iptable_filter iptable_mangle ip_tables x_tables 8021q garp stp llc imq it87 hwmon_vid loop i2c_i801 i2c_core aufs sd_mod uhci_hcd ahci libata ehci_hcd usbcore nls_base e1000e [last unloaded: scsi_wait_scan]
[172676.467392] Pid: 0, comm: swapper Not tainted 2.6.32-layer7-imq-amd64 #2
[172676.467396] Call Trace:
[172676.467400]  <IRQ>  [<ffffffff81035a5d>] ? warn_slowpath_common+0x76/0x8c
[172676.467415]  [<ffffffff81035ac5>] ? warn_slowpath_fmt+0x40/0x45
[172676.467422]  [<ffffffff81248a21>] ? netif_tx_lock+0x3d/0x64
[172676.467428]  [<ffffffff81248b37>] ? dev_watchdog+0xef/0x18e
[172676.467436]  [<ffffffff81048d6c>] ? __queue_work+0x27/0x38
[172676.467444]  [<ffffffff810419b7>] ? run_timer_softirq+0x1c5/0x262
[172676.467452]  [<ffffffff8103b42c>] ? __do_softirq+0xda/0x196
[172676.467459]  [<ffffffff8101a268>] ? lapic_next_event+0x18/0x1d
[172676.467467]  [<ffffffff8100ca1c>] ? call_softirq+0x1c/0x28
[172676.467474]  [<ffffffff8100dd85>] ? do_softirq+0x31/0x66
[172676.467480]  [<ffffffff8103b293>] ? irq_exit+0x36/0x79
[172676.467487]  [<ffffffff8101aa92>] ? smp_apic_timer_interrupt+0x88/0x96
[172676.467493]  [<ffffffff8100c3f3>] ? apic_timer_interrupt+0x13/0x20
[172676.467497]  <EOI>  [<ffffffff81012177>] ? mwait_idle+0x6d/0x72
[172676.467508]  [<ffffffff81012129>] ? mwait_idle+0x1f/0x72
[172676.467514]  [<ffffffff8100abfb>] ? cpu_idle+0x9d/0xd7
[172676.467522]  [<ffffffff814b8c52>] ? start_kernel+0x395/0x3a0
[172676.467529]  [<ffffffff814b837a>] ? x86_64_start_kernel+0xe5/0xe9
[172676.467534] ---[ end trace 91d49e8947278f21 ]---
[172676.659718] LAN: port 1(eth2) entering disabled state
[173315.475744] LAN: port 1(eth2) entering disabled state
[173322.066941] ADDRCONF(NETDEV_UP): eth2: link is not ready

Въпроса ми е мога ли по някакъв начин да хвана проблемното устройство или единствения начин е физически с изключване на кабели от суича докато проблема изчезне.

В момента реших проблема с рестарт на всички компютри и суичове , тъй като практически е най-бързо , съответно след това няма проблем.. но реално погледнато това не е решение а отлагане

 

Мрежата се състои от неуправляеми суичове които са навързани последователно , както и 1 микротик който разтагва 1 VLAN пуснат в сегмента за да могат да се отделят няколко машини.

На микротика имам разтагване на VLAN и бриджване на няколко интерфейса.

 

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

Прилагам статистиките на интерфейса:

# ethtool -S eth2
NIC statistics:
     rx_packets: 35069450
     tx_packets: 49535199
     rx_bytes: 6205998167
     tx_bytes: 52356904727
     rx_broadcast: 308633
     tx_broadcast: 54902
     rx_multicast: 436348
     tx_multicast: 30
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 436348
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 3355
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 2
     tx_restart_queue: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 5414
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 3357
     rx_long_byte_count: 6205998167
     rx_csum_offload_good: 34192052
     rx_csum_offload_errors: 1
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     rx_dma_failed: 0
     tx_dma_failed: 0

 

[111111]

За да е сигурно пробвал ли от друга ланка?

а и тоя исторически кърнел... 

 

каква е топологията и техниката в мрежата

[dobriloff]

Дам пробвах да местя LAN-a на съседния порт. Топологията е Debian 6 (4 LAN ports) 1 - Internet , 2 - Backup Internet , 3 - LAN , 4 - Free . Lan порта е вързан към 8 портов неуправляем суич. към който суич са вързани още 9 неуправляеми. Въпроса единствено физически или мога да хвана машината която трови.. 

[hgd]

На първо време, изключи си пауза опциите на мрежовата карта:

ethtool -A eth2 rx off tx off

01:80:c2:00:00:01 ти идва от някой суич или рутер (това ти е STP - spanning tree protocol). Не ти забива от него.

Най-добре качи дъмп тук за да видим реално какво се движи в мрежата.

 

Инвестирай в поне един управляем суич, например Tp-Link TL-SG3210 който е около 150лв.

Edited June 2, 2015 by hgd

[dobriloff]

Дам , мисля да спра тези паузи на интерфейса.

Относно суичовете мисля да сложа 2-3 микротика RB951.. който да ползвам като управляеми суичове с WiFi AP . Обмислях и варианта за тези  TL-SG3210 , но реших че Микторика би бил по функционален. Като крайната идея е да имам нещо като Main Switch и към него да се връзват останалите суичове и тогава отдалечено да мога да си свалям портове а не да пращам някой и да му казвам сега изключи този кабел ... Цялата драма е ,че офиса в който се случват драмите ми е отдалечен. Всепак за тези лоши пакети , от какво може да са причинени? Забиваща мрежова карта или някакъв друг компонент по компютъра , или пък софруерно ?

Прикачил съм и дъмп-а
 

BAD.zip

[hgd]

Обмислях и варианта за тези  TL-SG3210 , но реших че Микторика би бил по функционален.

 

Нужен ти е суич, а ти мислиш за рутер. Сам решаваш, но суичът ще е по-функционален за L2 мрежа, каквато е твоята.

 

Пакетите идват най-вероятно от лан карта - на компютър или лаптоп. Може да е предизвикан отговор (възоснова на пакет от микротика - имаш RSTP пуснат на него - спри го по-добре).

[dobriloff]

Спрях STP-то , то автоматично се създава при създаването на бриджове , и реших ,че не ми пречи

Относно избора на устройство още наистина се чудя. Защото Mikrotik е router но със Switch модул в него. Реално погледнато има малко по-малко L2 функционалности но тези на стандартерн L2 Management Switch , но като се замисля аз освен STP друго май не си настройвам по суичовете. Ползвам един TL-SG3210 на друго място и от време на време устройството си работи но мениджмънта ми пада и трябва да го рестартирам ако искам да пипам по него. Идеята ми при избора на такова устройство е ако може да е по унивесално тъй като не се знае другия месец какво ще се налага да правим и да се налага да обяснявам ,че устройстово което сме купили преди няколко месеца не може да прави тези неща и трябва да купуваме ново..

[hgd]

Имам доста суичове TL-SG3210 версия 1 с последен софтуер (1.9.2). Никога не са забивали или спирали. Почти всички са на 20-30км от мен. Мениджмънта им (през ssh и web) си работи отлично.

 

Универсалността е интересно нещо. Хем да бъде колкото пощенска марка, хем да замества маркова техника за десетки хиляди.

Ако всички суичове са ти управляеми, то проблема с пауза пакетите, ще го засечеш къде е за около 2 минути.

 

P.S. До момента не съм чувал за ДОМАШНИ управляеми суичове, но е пълно с ДОМАШНИ рутери.

 

P.P.S. Вероятно твоята версия на суича е версия 2. За нея има нов firmware с кръпка на този бъг:

"Fix the bug of CPU 100% occupied and inaccessible management page within a short period after working for 10 days."

Edited June 2, 2015 by hgd

[dobriloff]

Имам доста суичове TL-SG3210 версия 1 с последен софтуер (1.9.2). Никога не са забивали или спирали. Почти всички са на 20-30км от мен. Мениджмънта им (през ssh и web) си работи отлично.

 

Универсалността е интересно нещо. Хем да бъде колкото пощенска марка, хем да замества маркова техника за десетки хиляди.

Ако всички суичове са ти управляеми, то проблема с пауза пакетите, ще го засечеш къде е за около 2 минути.

 

P.S. До момента не съм чувал за ДОМАШНИ управляеми суичове, но е пълно с ДОМАШНИ рутери.

 

P.P.S. Вероятно твоята версия на суича е версия 2. За нея има нов firmware с кръпка на този бъг:

"Fix the bug of CPU 100% occupied and inaccessible management page within a short period after working for 10 days."

Стана ми интересно за управляемите суичове и бързото засичане. Освен с гасене на портове 1 по 1 , по друго може ли да се познае къде е проблема. В статистиката на порта ще логне нещо ?

Edited June 2, 2015 by dobriloff

[hgd]

Стана ми интересно за управляемите суичове и бързото засичане. Освен с гасене на портове 1 по 1 , по друго може ли да се познае къде е проблема. В статистиката на порта ще логне нещо ?

Имаш много възможности и начини - по броячи (counters, traffic statistics), по лог, през SNMP (включително да си чертаеш графики).

Изолация на клиенти - по портове, VLAN-ове и др. И това само в прост L2 manageable суич (не Smart, да се прави разлика).

За повече пари, може да имат и много по-интересни функции и методи за детекция на проблеми.

[dobriloff]

Благодаря за полезните насочки относно проблема с Pause пакетите. Относно подмянята на част от неуправляемите суичове мисля да направя микс между TL-SG3210 и RB951G-2HnD . Тъй като ми се иска и WiFi да подобря.

[Mile]

С тия сапунерки... ще е страхотно подобрение.

Сегментирай си мрежата с един суич преди рутера.

Най-малкото ще знаеш от кой клон на мрежата идва проблема.

[gbdesign]

Дълго ми е за четене, та дано повтарям някого. Пауза фрейм си е болест, на интелските чипсети, които ги дрискат при забил, заспал или по някога, само включен в контакта компютър. Голям проблем е ако мрежата ти е изградена със суичове, които поддържат IEEE P802.1p но нямат възможност за настройка на политиката към него. Такива са всички TP-LINK и D-LINK unmenaged, RACK mountable боклуци. Неомонтанските, колкото и да ги недолюбват някои колеги, имат възможност за настройка на flow control. До като се занимавах с LAN, си настройвах суичовете да аксептват въпросните фреймове /в същност управляващи МАС адреси/, но не и да ги предават. На сегашната ми работа, като почнах преди години, всички суичове бяха от цитираните по-горе недоразумения и когато някой заспал комп почнеше да бълва pause  frame, цялата мрежа моментално спираше. Като обясних на шефа естеството на проблема, бързо се нави да подменя всички суичове с умни и проблема беше решен кардинално.