Здравствуйте.
Прошу помочь в настройке кольца, состоящего из 9-ти коммутаторов соединенных по схеме, как указано ниже.
Задача - заставить работать кольцо так чтобы при разрыве соединения между какой-нибудь парой коммутаторов происходила перенастройка дерева и трафик во всех VLAN начинал ходить с другой стороны от разрыва.
Сейчас на коммутаторах включен глобально RSTP, loopback detect глобально отключен, также отключен на портах.
На магистральных портах включен STP и FBPDU. Граничными портами выбраны те, которые не участвуют в кольце.
На магистральных портах выбрано edge - false
На портах настроены VID 10,20,30,40,50,60,70.
На схеме показаны статус и роль магистральных портов, модели коммутаторов, версии их прошивок, параметры магистральных портов, а также стоимость пути - External root cost.

Как видно из схемы, между коммутаторами O и D порты, смотрящие друг на друга имеют одинаковые роли и статус -
Designated и Forwarding. Если я правильно понимаю принцип работы STP, то на этих портах
в такой схеме должно быть состояние Discarding - Alternate.
Проблема заключается в том, что при разрыве соединения между коммутаторами S и O или между P и D
дерево не перестраивается и коммутаторы O и D соответственно перестают отвечать на пинги.
Прошу помочь разобраться в настройке STP. Может быть лучше в такой схеме вместо RSTP использовать
ERPS ?

На картинке между O и D разные скорости 100 и 1000 мегабит, если это не ошибка то это разные порты, и в общем это все объясняет. Проверьте что они реально смотрят друг в друга, можно по lldp посмотреть.


STP использовать можно и с рядом настроек типа p2p оно довольно быстро будет перестраиваться, но в вашей схеме где все порты включены в "умные" коммутаторы, можно развернуть и ERPS, мне кажется оно попроще будет, и время перестроения стремится к нулю.

Да, действительно, скорости на портах между O и D разные. Забыл уточнить что коммутаторы соединены между собой через радиомост. После подключения коммутатора D в порт 100М все заработало как надо.
Спасибо.

Неплохо бы еще ПО везде обновить

_________________
D-Link Switches: Tips & Tricks

А какие можно устанавливать ? Последние бэта версии подойдут или лучше брать не самые свежие ?

Актуальные прошивки в теме: viewtopic.php?f=2&t=92700

Спасибо.

Если на трассе есть радиомост, и он не поддерживает ERPS, то тогда ERPS применить не сможете, он требует прямых линков, а так рад, что заработало.

Для ускорения сходимости можно повыключать stp на всех свичах, кроме одного.
На остальных достаточно включённого fbpdu.

почему это? Для тех устройств, кто его не поддерживает - RAPS vlan обычный vlan. У меня erps даже через qinq других провайдеров поднят, всё нормально работает.

Если есть устройство не поддерживающее ERPS то через одно такое - работать будет, конечно. Устройства непосредственно присоединенные к нему при обрыве линков сгенерируют событие, но если это РРЛ пролет на оборудовании не поддерживающем ERPS, и допустим рвется радиолинк из-за дождика, то некому будет сгенерировать это событие ERPS, у коммутаторов то присоединенных к релейкам связь то не падает. Хотя если релейку украли, допустим, а не дождик пошел, то тогда сработает. Скорее всего по таймауту таки все перестроится, но на малое время сходимости тут рассчитывать уже не стоит. Поэтому преимуществ перед STP, для которого парочка тупых свитчей на линке - нормальное решение, я не вижу.

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

Ну отключение меня даже не сильно волнует, вопрос когда линк поднимется релейный и по кольцу побежит трафик с ацкой силой, не потонут ли сообщения ERPS в этом флуде. Как -то статус портов, и предварительное прослушивание STP меня тут более беспокоят. В общем готов собрать стенд и посмотреть как ERPS работает в таких условиях. STP точно нормально все отрабатывает, хоть порой и долго ждать приходится.

Повторюсь - при правильной настройке stp сходится быстро, ждать не придётся.
Достаточно оставить в кольце одно устройство с stp и выкрутить ему тайминги в минимум.

Имхо, товарищ не прав про "оставить в кольце одно устройство с stp", отключение stp на транзитных коммутаторах и замены stp на простой форвардинг stp-пакетов. При изменении топологии коммутатор должен быстро переучить маки (не все конечно) и если он не участвует в stp, то tcn он не получит и age маков не будет урезан. Как следствие, источник будет посылать пакеты, которые свич будет форвардить в порт, за которым уже клиент не сидит (вследствие изменения топологии. особенно заметно обычно в вилане управления), пока приёмник не ответит и не переучит этот свич.
Есть ещё засада с тупыми (не умеющими блочить stp на клиентских портах) свичами в кольце :) когда вредитель, подключенный с такого коммутатора, объявляет себя корнем топологии и длина цепочки в соседних кольцах начинает превышать ~19 коммутаторов.