gorec2005 Опубликовано 22 августа, 2007 · Жалоба Подскажите - из чего могут появляться подобные глюки в локалке (сеть большая более 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-ы давать не надо так как это малореально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 22 августа, 2007 · Жалоба Ключик -e к tcpdump добавте. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 23 августа, 2007 (изменено) · Жалоба Ключик -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 то истуация не исчезает... Изменено 23 августа, 2007 пользователем gorec2005 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShumBor Опубликовано 23 августа, 2007 (изменено) · Жалоба смотреть комутаторы ибо петля или пробитый порт на каком то из них Хотя может еще кто-то снупингом занимается, хотя тогда бы наверное дубляжа небыло бы Изменено 23 августа, 2007 пользователем ShumBor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 24 августа, 2007 · Жалоба смотреть комутаторы ибо петля или пробитый порт на каком то из нихХотя может еще кто-то снупингом занимается, хотя тогда бы наверное дубляжа небыло бы петля исключена. а как пробитый порт может влиять? спуфинг знаю снифинг то-же, а что такое снупинг(snap-треск?)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShumBor Опубликовано 24 августа, 2007 · Жалоба смотреть комутаторы ибо петля или пробитый порт на каком то из них Хотя может еще кто-то снупингом занимается, хотя тогда бы наверное дубляжа небыло бы петля исключена. а как пробитый порт может влиять? спуфинг знаю снифинг то-же, а что такое снупинг(snap-треск?)? это я опечатался... жарас действует отвратительно :(А побитый порт на неуправляемом только отключая сегменты искать тот сегмент откуда это идет. потом делить его пополам и смотреть из какой половины и так до выяснения глючащего свича.. ну или пройтись постмреть можно по индикаторам - обычно порт такой линк показывает без кабеля Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ram_scan Опубликовано 24 августа, 2007 · Жалоба У какого-то пациента может быть включен arp proxy еще. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
netdog Опубликовано 13 сентября, 2007 (изменено) · Жалоба Подскажите - из чего могут появляться подобные глюки в локалке (сеть большая более 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. Пологаю это проблема определенном чипе свитча(ей), потому что глюк иногда наблюдается и в других местах но не так жестоко. Изменено 13 сентября, 2007 пользователем netdog Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rudz Опубликовано 13 сентября, 2007 · Жалоба т.е. пакеты дублируются как будто кто-то получив их перепосылает еще раз. это дешёвые д-линки (1005/1008) так со временем с ума сходят. один (иногда и несколько) порт будет светиться или даже моргать при отключеном кабеле. рецепт: "заткнуть" порт, закоротив RX & TX. наши монтажники просто втыкали в порт джек, обмотаный фольгой от сигарет. :) а вот вычисляется только последовательным отключением веток и контролем по снифферу "двоит/не двоит". :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
netdog Опубликовано 14 сентября, 2007 · Жалоба И вопрос на засыпку: Как этот флуд убивать iptables/ebtables 'ами.. Т.е. надо как-то детектить дублирующийся пакет и дропать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
