On Tue, Mar 04, 2008 at 09:33:01PM +0300, Oleg Frolkov wrote: > Сорри, всем отбой..... все оказалось проще...... серв не при чем, нашел > уже в сети урода - надо еще кого-нибудь > к нему заслать посмотреть как он так умудрился сделать. смысл в том что > малая часть broadcast трафика уходящего в его порт разворачивается и > топает назад портя ARP таблицы свитчей.
Из того же самого порта выходит, куда влез? Или же в сети есть цикл? Циклов в одном бродкастовом домене быть не должно. Если они там нужны для отказоустойчивости -- то на свитчах должны быть правильно включены STP/RSTP/etc, причём эти протоколы обычно включаются на конкретных портах и не мешает проверить, что STP-enabled порт не подсоединён к STP-disabled. > Вот и получалась лотерея - если > чей-то бродкаст возвращался - свитчи разворачивали таблицы и его трафик > шел в тот порт пока он очередным пакетом не поворачивал на себя, странно > только что проблема не локализовалась в одном VLAN и проявлялась в > других..... Ну это уже тараканы настройки vlan'ов... > по идее за пределы VLAN в котором она возникла она не должна > была выходить. В общем-то конечно ethernet технология задница..... Нормальная технология, если ею правильно пользоваться. Молотком тоже можно по пальцу попасть. :) > Кстати в принципе можно и автоматическую диагностику подобных вещей > делать, может кто знает реализацию? Некоторые свитчи умеют детектировать бродкастовый шторм и поднимать тревогу, от SNMP traps до посылки e-mail'а админу. > Или такого еще не реализовывали? Теоретически если регулярно опрашивать > свитчи по SNMP и следить за изменениями > таблиц соответствия MAC адресов и портов - вполне можно сразу находить > направление с которого идет эта фигня. Вариантов масса, в зависимости от способностей свитча: прибить маки к порту гвоздями и запретить обучение, поставить порт в "down on new mac", поставить лимит learning macs на порту, и так далее. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]