WTPIX

Вот что получилось по предоставленным вами скриншотам: toster-rstp-costs.pdf

Вот что получилось при эмуляции: toster-rstp-lab-results.pdf

Учитывая разницу в теории и практике, к вам просьба предоставить данные повторно (состояния портов, cost, примерно как здесь ) для коммутаторов sw1-sw5.

Мне кажется или тут все равно что-то не то и при очередном отключении какого-либо свитча трафик не пойдет в обход?

Мне все-таки представляется, что на некоторых портах RSTP выключен и соответствующие коммутаторы всего лишь перенаправляют чужие BPDU (опция BPDU handling, значение flooding). Точнее смогу сказать немного позже, когда разберусь со значениями designated cost - соответствуют ли они топологии.

Возник вопрос

Вы не могли бы прояснить, что означают символы e/d в колонке STP для коммутаторов sw1, sw2, sw5? Если проводить аналогию с корневым коммутатором, то, вероятно, это означает enabled/disabled. Это многое бы объяснило. Проверьте, пожалуйста, чем отличаются настройки для 25 и 26 портов этих коммутаторов (sw1, sw2, sw5).

Да, лучше разобраться, какой сервер использует какой влан. Так как вланы 350 и 1 по факту объединены, проще будет посмотреть, IP-адреса из каких префиксов на каком сервере/хосте настроены и дальше уже отобразить префикс на номер влана, используя конфигурацию роутера, находящегося зя коммутатором root.

Предлагаю:
1) для порта 49 коммутатора root задать нетегированный влан 1
2) порт 26 коммутатора sw2 перевести в аксесс-режим (задать нетегированный влан 1)
Делать это желательно поэтапно. Учитывая общую неординарность дизайна сети, стоит быть готовым к её неработоспособности (в том числе отказ управляющего влана), хотя это и маловероятно. То есть лучше это делать в нерабочее время, возможно придется откатывать настройки на месте, используя консольный доступ на коммутатор.

Вот черновая диаграмма топологии. Осталась пара неясностей - модель коммутатора sw5 (судя по MAC-адресу это 3com, у вас указан HP, но пока некритично, думаю) и транк со стороны root до sw1 (на нем, как я понял, тегируются все вланы кроме 1, так какие вланы на нем вообще присутствуют?).

Самое главное - настройки линков sw2<->sw3и root<->sw9. В каждом случае нетегируемый влан с одной стороны 1, с другой - 350. В результате у вас фактически на L2 они объединены. Любой хост из влана 1 может получить доступ к любому хосту во влане 350, при желании. Пока непонятно, почему вообще у вас до сих пор широковещательного шторма не наблюдается, условия для него, как я понимаю, есть.

не может ли мое кольцо не работать из-за этого свитча, который, собственно, отростком в кольце состоит...

Вряд ли причина в этом коммутаторе (о причине ниже), но просьба указать, какие еще STP-коммутаторы есть в L2-домене.

нет, состояния портов не изменились. Действительно, странно.

Я все больше утверждаюсь в предположении, что двусторонней проходимости BPDU на каждом линке не наблюдается, и вероятная причина в неконсистентном распределении вланов по портам. К примеру, коммутаторы Cisco работают в RSTP (IEEE 802.1w) режиме или на аксессных портах, или во влане 1 транков (см. здесь). Я думаю, в вашем случае творчество вендора также вполне вероятно.

Далее, вы писали:

sw3 vlan1<-> vlan1; tag 75,350 sw2 vlan 350; tag 75<-> vlan1; tag 75,350 sw3 vlan1; tag 75,350 <-> trunk vlan1 root bridge vlan350<-> vlan1 sw9

Я не вполне понял, где какие вланы. Вы можете предоставить скриншоты настроек каждого порта в плане вланов и прочего?

Далее, я тут рисую более внятную схему сети, уточните, пожалуйста bridge ID коммутаторов sw3-4,sw6-9. На вашей схеме часть, определяемая MAC-адресом, имеет длину 7 октетов вместо 6 (пример - sw9 32768-20:38:ea:a7:bb:7a:40), я этого тоже не понял.

Я надеюсь, если каждый линк будет настроен одинаково (одинаковые вланы с каждой стороны линка), дерево выстроится как надо. Только пока не будет четкого плана, изменять VLAN-конфигурацию линков нежелательно. Я пока предполагаю, необходим нетегированный влан 1 в каждом линке между коммутаторами.

ничего не изменилось.

На приведенных вами скриншотах ( состояния портов, 1, 2, 3)все порты находятся в состоянии (port state) Forwarding. В случае нормальной работы RSTP в кольце один порт должен быть в состоянии Blocking (вероятно, использован другой, схожий термин). Просьба проверить, не изменилось ли где-либо состояние порта, участвующего в RSTP с Forwarding на Blocking.

И дешевый линк до сих пор в блокировке находится.

Повторяя предыдущее, все порты находятся в состоянии Forwarding, что странно. Скажите пожалуйста, как вы определяете заблокированный статус линка? По уровню трафика?

п.с. есть еще мысли отчего кольцо не срабатывает

Если мои предположения оправдаются и значения root path cost изменятся после отмены режима Edge порта 1 коммутатора sw3, то вероятно RSTP работает нормально,и будем более предметно смотреть на распределение вланов по портам.

Вообще говоря, так как все коммутаторы определили корневой коммутатор правильно, то BPDU хотя бы в одном направлении кольца проходят нормально.

Далее, после того, как переключили порт 1 коммутатора sw3 из режима Edge в обычный, пришлите, пожалуйста, еще раз состояние RSTP-портов всех коммутаторов. Должны измениться значения root port и root path cost на некоторых из них. С вланами предлагаю разобраться позже.

Я подозреваю, до сих пор почему-то BPDU не проходят по кольцу.
Пришлите, пожалуйста, для каждого коммутатора состояние портов-аплинков (в смысле STP) с полной легендой. Как здесь:

И просьба как-то пометить, где какой коммутатор, чтобы скриншоты не перепутались.

Включил, действительно свитчи увидели рут бридж, стоимости нормально посчитали,

Хорошо. Какой линк сейчас блокируется?

RSTP все равно на портах выключен, насколько я могу судить из выделенного. Попробуйте включить RSTP на этих портах (раздел Spanning tree per port в документации).

Также проверьте, на всех линках между коммутаторами режим Edge port обязательно должен быть выключен с каждой стороны. Иногда этот режим называют portfast.

Root guard, если где-то активен, тоже пока надо выключить.

Посмотрите по легенде, обведенные красным значения - это что? Случайно не активность STP на интерфейсе?

Сравните, пожалуйста, конфигурацию STP корневого коммутатора и одного из sw1/sw2/sw5.
Общую конфигурацию STP и по портам-аплинкам до других коммутаторов (страницы 49,58).

Спасибо за схему.

Все интерфейсы в полнодуплексном режиме.

Это хорошо.

у меня 3 свитча выбиваются от всех остальных. У них значения cost (4 - 1Гб, 19 - 100Мб) у остальных (20000 - 1Гб, 200000 - 100 Мб). Значения стоят правильно (в схеме указал в одной системы дабы проще понять было).

Вот здесь не понял. Эти три коммутатора - случайно не sw1,sw2,sw5, о которых дальше говорите? Видимо я непонятно выразился, я считаю, что на всех коммутаторах надо добиться единообразия представления стоимости пути (root path cost). Иначе нам остается гадать, как отображаются друг на друга 16- и 32-битные значения, учитывая, что в BPDU поле имеет длину 32 бита. Чтобы разобраться в этом, потребуется изучение дампа BPDU и прочее. Поэтому прошу повторно привести к единому режиму вычисление стоимости пути. Ключевые слова для поиска в интерфейсе - root path cost short (16-битный вариант), root path cost long (32-битный вариант).

Когда смотрел bridge id заметил странную вещь:
sw1, sw2, sw5 имеют root bridge id точно такой же как и их bridge id. На остальных свитчах все хорошо.

Это плохо. Значит, каждый из них считает себя корневым коммутатором. Возможные причины - непрохождение BPDU. Что еще общего у этих трех коммутаторов? Производитель, может быть?

Установка cost в 300 не помогла. Сеть не перестраивается. Ребут sw9 не является возможным, а ребут sw1 не дает результатов, так же как и ребут sw8.

Я думаю, при правильной работе сети перезагрузка коммутаторов после изменения стоимости линка не потребуется.

priority(128), admin edge(non-edge), point-to-point(forced true) оставлять по умолчанию для всех портов?

Значение priority имеет смысл понижать для корневого коммутатора. Пока предлагаю этого не делать.

Edge port - порт, на котором гарантированно нет петли. Как правило, подключен к рабочей станции или серверу. Соответственно порты, соединяемые линком между коммутаторами не могут быть edge.

Point-to-point - порт, соединенный, как правило, полнодуплексным линком лишь с одним другим портом. Для нормальной работы RSTP все порты должны быть в режиме point-to-point. Если порт переключается в режим shared (например, дуплекс сломался), то RSTP работает, насколько мне известно, в режиме совместимости со 'старым' STP (802.1d).

Вопрос: как мне сделать так, чтобы разрыв был между "Отдел гл. энергетика" и "правое крыло" ?

Для этого необходимо, на мой взгляд, увеличить значение cost для этого линка с каждой стороны до достаточно высокого значения.

Теперь, что касается этого самого значения. Учитывая гетерогенность вашей сети, стоит убедиться, какие именно значения cost установлены для каждого из интерфейсов, участвующих в RSTP-процессе. Они могут быть как 16-, так и 32-битными, насколько мне известно. Если все значения cost установлены в 4 для гигабитных и 19 для 100-мегабитных портов, должно хватить значения cost 300 для соответствующего линка (с каждой стороны, на случай дальнейшего изменения корневого коммутатора).

Необходимо также убедиться, что каждый из вышеупомянутых интерфейсов работает в полнодуплексном режиме (т.е. является, с точки зрения RSTP, p2p-портом). Это необходимо для корректной обработки изменения топологии (topology change).

Если это не поможет и возникнут дополнительные вопросы, то будьте добры, потрудитесь нарисовать нормальную читаемую схему сети с необходимой информацией (bridge id каждого коммутатора, cost для каждого интерфейса, участвующего в RSTP).

можно попробовать положить порт в одну сторону на рутовом свиче, тогда по идее кольцо перестоится.