Re: (Решено) Re: Странности работы сети в etch/xen
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
Reply to: