А в какой ситуации, на практике, а не в теории, возможно кольцо между портами? Админ случайно сделал петлю на коммутаторе в серверной, ползователь соединил две сетевых розетки или два тупых коммутатора в помещении?

Да соседа, имеющие подключение кинули друг-другу веревку...
Или в "колхоз-нете" наступило утро.... Бывает. Редко, но бывает. Абоненты этого длинка страдают (выше у меня отрабатывает, а вот в длинке что-то не получается и чтоб на порту и между портами).

Александр, а с чем связано такое ограничение? Почему LBD и STP не могут мирно сосуществовать, ведь у них независимые сервисные пакеты?

Как я понял если мне нужно блокировать кольцо образовавшееся за одним портом коммутатора, в не управляемом сегменте сети, то нужно использовать LBD, а если между портами одного или нескольких коммутаторов, то тогда STP, я правильно понимаю?

Да, правильно.

Дело в том, что пакеты BPDU имеют более высокий приоритет чем ECTP, в итоге при возникновении петли порт захлёбывается BPDU пакетами, а ECTP пакеты не проходят и коммутатор не видит петли.

Alexandr Zaitsev: скажите, а может ли в этом случае помочь включение Multicast Storm Control на 3526? Чтобы он перестал захлебываться BPDU, часть их отбрасывал, и срабатывал LBD. Просто получается, если в кольце несколько 3526, а между ними неуправляемые коммутаторы, то RSTP использовать нельзя, т.к. если на одном из неуправляемых портов появится кольцо, то все свитчи в сегменте сразу же захлебнутся BPDU и ничего нельзя будет сделать.

Нет.

_________________
С уважением,
Бигаров Руслан.

Хотя свитч пишет в логах:

После образования закольцовки за 20-м портом на тупом свитче (на 3526 включены LBD+RSTP на 20-м порту)
Multicast storm is occurring (port: 20)
...

После выключения закольцовки:
Multicast storm has cleared (port: 20)

При этом, интересно что LBD срабатывает сразу же после выключения закольцовки и гасит порт. До выключения закольцовки, как и ожидается, не срабатывает.


Собственно еще вопрос - что значат эти сообщения storm is occuring/storm has cleared? Это он просто сообщает, что вот мол штром есть? Или свитч все-таки начинает что-то делать? По идее он должен shutdown'ить порт, но почему-то не shutdown'ит.

Да, просто показывает, что storm начался/закончился. Выключаться порт будет, если выбрано действие shutdown и после истечения таймера countdown.

А нет возможности сделать какую-нибудь функцию, препятствующую захлебыванию коммутатором собственными BPDU? Было бы крайне полезно для некоторых ситуаций

Т.к. по сути LBD не срабатывает в этом случае, а multicast storm control, судя по мануалу, режет все пакеты кроме опять же BPDU.

Или приоритет LBD и BPDU поменять

Нет возможности.

_________________
С уважением,
Бигаров Руслан.

Начал тут: viewtopic.php?t=126842

В итоге, работают обычный LBD и STP LBD. Работают вместе на-ура. Правда, пока на стенде.

Как понимаю, LBD нужен для обнаружения петли на 1 порту, и STP LBD между портами.

Вопрос. Что должно быть разрешено ACL, чтобы работали оба?

Если все разрешено - работает. Но все разрешать не хочется...

DES-3028, Firmware Version: Build 2.52.B11

Упс... При отключении STP LBD тоже все прекрасно работает. Значит и не надо - как "доктор советует"

Но все-же, что должно быть разрешено в ACL для работы STP?
LBD использует протокол 9000. А STP ??

Служебные пакеты не зафильтруются ACL.

_________________
LiveComm

Хм...

Имею ACL на клиентских портах:
Ethernet-800 (IP) разрешить
Ethernet-806 (ARP) разрешить
Остальное запретить.

Шторм появляется, петля не ловится.
Убираю последний запрет - все работает.