Глюки в локалке...

[gorec2005]

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

 

кусочек вывода tcpdump -ni eth:

 

13:30:13.927990 arp who-has 192.168.24.81 tell 192.168.20.37

13:30:13.928111 arp who-has 192.168.24.81 tell 192.168.20.37

13:30:13.928315 arp who-has 192.168.24.81 tell 192.168.20.52

13:30:13.928441 arp who-has 192.168.24.81 tell 192.168.20.52

13:30:13.928575 arp who-has 192.168.24.81 tell 192.168.25.18

13:30:13.928682 arp who-has 192.168.24.81 tell 192.168.25.18

13:30:13.929213 arp who-has 192.168.24.81 tell 192.168.24.29

13:30:13.929314 arp who-has 192.168.24.81 tell 192.168.24.29

 

 

т.е. пакеты дублируются как будто кто-то получив их перепосылает еще раз.

Как проще (сейчас глюк ремонтируется путем последовательного отключения ветвей дерева с одновременным контролем пропадания дублей) это лечить? и можно ли совсем от этого избавиться?

 

PS. ответы вроде нечего было на неупр. свитчах сеть строить или переводить всех на vlan-ы давать не надо так как это малореально.

[Kirya]

Ключик -e к tcpdump добавте. :)

[gorec2005]

Ключик -e к tcpdump добавте. :)

06:23:46.158220 00:0c:29:36:05:1e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.21.32 tell 192.168.22.29

06:23:46.159313 00:0c:29:36:05:1e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.21.32 tell 192.168.22.29

 

при этом если отключить 00:0c:29:36:05:1e то истуация не исчезает...

Edited August 23, 2007 by gorec2005

[ShumBor]

смотреть комутаторы ибо петля или пробитый порт на каком то из них

Хотя может еще кто-то снупингом занимается, хотя тогда бы наверное дубляжа небыло бы

Edited August 23, 2007 by ShumBor

[gorec2005]

смотреть комутаторы ибо петля или пробитый порт на каком то из них

Хотя может еще кто-то снупингом занимается, хотя тогда бы наверное дубляжа небыло бы

петля исключена.

а как пробитый порт может влиять?

спуфинг знаю снифинг то-же, а что такое снупинг(snap-треск?)?

[ShumBor]

смотреть комутаторы ибо петля или пробитый порт на каком то из них

Хотя может еще кто-то снупингом занимается, хотя тогда бы наверное дубляжа небыло бы

петля исключена.

а как пробитый порт может влиять?

спуфинг знаю снифинг то-же, а что такое снупинг(snap-треск?)?

это я опечатался... жарас действует отвратительно :(

А побитый порт на неуправляемом только отключая сегменты искать тот сегмент откуда это идет.

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

[ram_scan]

У какого-то пациента может быть включен arp proxy еще.

[netdog]

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

 

кусочек вывода tcpdump -ni eth:

 

13:30:13.927990 arp who-has 192.168.24.81 tell 192.168.20.37

13:30:13.928111 arp who-has 192.168.24.81 tell 192.168.20.37

13:30:13.928315 arp who-has 192.168.24.81 tell 192.168.20.52

...........

 

т.е. пакеты дублируются как будто кто-то получив их перепосылает еще раз.

Как проще (сейчас глюк ремонтируется путем последовательного отключения ветвей дерева с одновременным контролем пропадания дублей) это лечить? и можно ли совсем от этого избавиться?

 

PS. ответы вроде нечего было на неупр. свитчах сеть строить или переводить всех на vlan-ы давать не надо так как это малореально.

Похожая фигня.. В нормальном режиме не редко пакеты двоятся, троятся n-тся...

Но в один прекрасный момент вообще случается чё-то вроде этого:

03:13:48.179025 00:0b:6a:7d:4b:f1 > 00:60:98:ef:39:53, ethertype IPv4 (0x0800), length 45: 10.16.113.152.1025 > 10.16.113.69.9999: UDP, length 3

03:13:48.179159 00:0b:6a:7d:4b:f1 > 00:60:98:ef:39:53, ethertype IPv4 (0x0800), length 45: 10.16.113.152.1025 > 10.16.113.69.9999: UDP, length 3

03:13:48.179282 00:0b:6a:7d:4b:f1 > 00:60:98:ef:39:53, ethertype IPv4 (0x0800), length 45: 10.16.113.152.1025 > 10.16.113.69.9999: UDP, length 3

03:13:48.179401 00:0b:6a:7d:4b:f1 > 00:60:98:ef:39:53, ethertype IPv4 (0x0800), length 45: 10.16.113.152.1025 > 10.16.113.69.9999: UDP, length 3

03:13:48.179525 00:0b:6a:7d:4b:f1 > 00:60:98:ef:39:53, ethertype IPv4 (0x0800), length 45: 10.16.113.152.1025 > 10.16.113.69.9999: UDP, length 3

03:13:48.179650 00:0b:6a:7d:4b:f1 > 00:60:98:ef:39:53, ethertype IPv4 (0x0800), length 45: 10.16.113.152.1025 > 10.16.113.69.9999: UDP, length 3

03:13:48.179657 00:0b:6a:7d:4b:f1 > 00:60:98:ef:39:53, ethertype IPv4 (0x0800), length 45: 10.16.113.152.1025 > 10.16.113.69.9999: UDP, length 3

03:13:48.179661 00:0b:6a:7d:4b:f1 > 00:60:98:ef:39:53, ethertype IPv4 (0x0800), length 45: 10.16.113.152.1025 > 10.16.113.69.9999: UDP, length 3

....

При всём при этом 10.16.113.69 и 10.16.113.152 может давно не быть в сети ну и пакеты соответственно тоже могут быть совершенно разные... как ICMP так и samba (445) и т.д. и т.п.

~

10-15

kPackets per second

==

все свитчи нефильтруя это рассылают во все стороны

==

сеть в полном дауне. Остальные сегменты немного спасают мосты с фильтрами (linux+iptables)

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

И вот фиг знает как дешевым способом это отловить. Всех админов не заставишь купить и поставить (полу)управляемые свитчи хотябы с счётчиками пакетов на портах а-ля ps2216.

 

Пологаю это проблема определенном чипе свитча(ей), потому что глюк иногда наблюдается и в других местах но не так жестоко.

Edited September 13, 2007 by netdog

[Rudz]

т.е. пакеты дублируются как будто кто-то получив их перепосылает еще раз.

это дешёвые д-линки (1005/1008) так со временем с ума сходят. один (иногда и несколько) порт будет светиться или даже моргать при отключеном кабеле.

рецепт: "заткнуть" порт, закоротив RX & TX. наши монтажники просто втыкали в порт джек, обмотаный фольгой от сигарет. :)

 

а вот вычисляется только последовательным отключением веток и контролем по снифферу "двоит/не двоит". :(

[netdog]

И вопрос на засыпку: Как этот флуд убивать iptables/ebtables 'ами..

Т.е. надо как-то детектить дублирующийся пакет и дропать.