RSTP — как изменить рут порты?

Question

[WTPIX]

Есть у меня такое вот кольцо. Работало себе нормально блокировало порт в "Отдел гл. энергетика" и все было хорошо. Потом выпал у меня "Узел связи 3CoM" а когда появился заблочило его порт и теперь от рута трафик до "HP" (выше "Отдел. гл. энергетика") бежит через такую длинную цепочку. Качество связи упало очень сильно.

Пробовал перезапускать "правое крыло", "HP" все без толку. Трафик через "Узел связи 3CoM" не хочет бежать, хоть застрелись. Была проблема на "Узел связи" стоял sfp модуль и он автоматом скорость не определял(из-за этого его стоимость была 65535) - исправил, стоимость стала 4. перезапуски не помогают. Неужели, надо перезапускать рут свитч ?

p.s. самое печальное, что не могу через веб-морду hp1810 назначить рут порт, а ssh и telnet у него не предусмотрены =(

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

Comments

[WTPIX]

Answer 1

[WTPIX]

в итоге:
посидел покурил протоколы, на одном свитче стоял древний протокол, изменил на свежий. На еще одном свитче на линках был включен edge, выключил. Повключал везде, кроме магистральных линков, portfast\edge. Задал приоритет рут свитчу 12288.
Теперь изменения топологий на всех свитчах обозначается правильно, при падении линка в течении 30-60 секунд трафик начинает бежать в обход. Проверил пока только на паре свитчей, до конца недели остальные проверю. Пока все работает - все стабильно.

Answer 2

[throughtheether]

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

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

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

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

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

Comments

[WTPIX]

@throughtheether

[WTPIX]

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

у меня 3 свитча выбиваются от всех остальных. У них значения cost (4 - 1Гб, 19 - 100Мб) у остальных (20000 - 1Гб, 200000 - 100 Мб). Значения стоят правильно (в схеме указал в одной системы дабы проще понять было).
Когда смотрел bridge id заметил странную вещь:
sw1, sw2, sw5 имеют root bridge id точно такой же как и их bridge id. На остальных свитчах все хорошо.

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

Сейчас вообще при падении какого-либо линка сеть падает, а не работает бесперебойно. Что за фигня ж такая?

Answer 3

[Валентин]

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

Comments

[WTPIX]

@vvpoloskin ну тогда же оно точно так же перестроится в другую сторону, по логике, не?

[WTPIX]

@vvpoloskin могу попробовать ночью перезапустить корневой свитч, но тогда вместо него кто-то рутом станет, что тоже не ок...

[Валентин]

Это все от того, что у вас неконтролируемая ситуация( Определитесь, кого сделать рутом и выставите на нем минимальный bridgeid. Судя по схеме, у вас у всех портов разная цена (1GE, 100M, где-то вручную). Я сомневаюсь, что в вашем случае критичен приоритет 1GE порта, поэтому выставите цену всех одинаковой. Дальше поразмыкайте кольцо в разных местах и сразу все увидите. И в следующий раз, даже после перезагрузок и/или размыкания линков вы получите управляемую ситуацию)

[WTPIX]

@vvpoloskin только в двух местах 100м. везде оптика. в одном месте оптика допотопная многомодовая, а в другом не хочет свитч кушать sfp модуль ...
кстати, вопрос еще такой:
priority(128), admin edge(non-edge), point-to-point(forced true) оставлять по умолчанию для всех портов?

[Валентин]

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

[WTPIX]

@vvpoloskin


bridge priority стоит везде 32768. Я сейчас наоборот завысыл стоимость на линке, который хочу, чтобы был запасным, но это не помогло.

Answer 4

[throughtheether]

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).

Answer 5

[throughtheether]

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

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

Это хорошо.

у меня 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.

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

Comments

[WTPIX]

@throughtheether
именно sw1, sw2, sw5. Но уже переключил их на cost long и теперь все в 32-битах стоимость отправляют.

2 коммутатора это 3com 2226 plus, один HP v1905. По факту вебморда у них один в один.

[throughtheether]

Вы можете уточнить (на схеме), какие сейчас значения cost каждого интерфейса по факту и какие значения root path cost и root bridge id для каждого коммутатора?

[WTPIX]

@throughtheether
Значения такие же с учетом, что
4 = 20000
19 = 200000
300 = 5000000
root bridge id сейчас правильный на всех свичах, кроме sw1, sw2, sw5

Answer 6

[throughtheether]

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

Answer 7

[throughtheether]

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

Answer 8

[throughtheether]

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

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

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

Comments

[WTPIX]

@throughtheether внезапно о_О
что-то как-то об этом даже не задумался. Оказывается, помимо общего включения рстп, надо было еще стп на портах включить. Включил, действительно свитчи увидели рут бридж, стоимости нормально посчитали, но вот сеть все равно не построилась так как надо(учитывая, что я стоимость одного линка искусственно завысил).

Answer 9

[throughtheether]

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

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

Comments

[WTPIX]

линк sw2-sw3, а надо линк sw4-sw5 блокировать

[throughtheether]

Удостоверьтесь, что линк заблокирован (трафика нет), деактивируйте интерфейс к этому линку с одной стороны и через секунд 30 снова включите. Если я правильно понял, проблем это создать не должно.

[WTPIX]

это вы про интерфейс между sw2-sw3 говорите?

[WTPIX]

@throughtheether
что-то опять же кольцо не работает... отвалился свитч по середине кольца и все, дальше линия легла мертвым грузом и лежала ждала пока свитч поднимется. не зашибись это, однако...

[throughtheether]

Да, любой из интерфейсов этого линка (с одной стороны). Деактивировать - в смысле выключить порт, а не STP на нем.

[WTPIX]

@throughtheether выключил, подождал(с минуту), включил. толку ноль =(
не везет мне что-то с кольцом этим...

[throughtheether]

@WTPIX
>отвалился свитч по середине кольца
на схеме он как обозначен?

[WTPIX]

@throughtheether sw4

Answer 10

[throughtheether]

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

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

Comments

[WTPIX]

[throughtheether]

Switch 3 interface 1 выключите режим Edge, пожалуйста.

[WTPIX]

@throughtheether отключил. Хотя странно, стоял автомат.
А не может быть проблема во вланах? у меня на руте, sw1, sw2 прописаны 3 влана : 1, 75(voip), 350. Может, bpdu уходят в 350 vlan и там теряются?

[throughtheether]

Вообще-то вланы не должны влиять на RSTP. Однако никто не застрахован от вендор-специфичных 'улучшений' протокола. У вас между коммутаторами линки в каком режиме (аксесс/транк) и в каких вланах?

[WTPIX]

@throughtheether

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

%) как-то так

p.s. %uplink% <-> %uplink% sw* %uplink <-> ...

[WTPIX]

@throughtheether вообще порты в аксесс

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

Answer 11

[throughtheether]

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

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

Comments

[WTPIX]

@throughtheether
ничего не изменилось. Вернул линк в автомат(которому стоимость завышали) все свитчи стоимость посчитали нормально и почти мгновенно.

[WTPIX]

в общем, стоимости считает нормально(если на пути поменять вручную значения), счетчик изменения топологии с тех пор как делал скрины вырос, но линк по прежнему работает не правильно.
От sw2 до root стоимость 40000
От root до sw3 стоимость 320000
И дешевый линк до сих пор в блокировке находится.

Answer 12

[throughtheether]

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

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

Answer 13

[throughtheether]

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

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

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

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

Comments

[WTPIX]

@throughtheether
нет, состояния портов не изменились. Действительно, странно.
Да, у меня в мониторинге измеряется уровень трафика на каждом узле связи. В сторону sw3 трафик порядка 15-50 кб\с, а от sw3 до sw2 вообще 0.

гкхм, дергнуло что-то меня глянуть "а не включил ли кто-то stp на свитче(в который воткнуто куча серверов), включенном в root bridge одним линком. И таки включен, рута нормально определяет, подсчет стоимость не в той системе исчеслений ведет, но волнует другое: не может ли мое кольцо не работать из-за этого свитча, который, собственно, отростком в кольце состоит...

Answer 14

[throughtheether]

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

Вряд ли причина в этом коммутаторе (о причине ниже), но просьба указать, какие еще 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 в каждом линке между коммутаторами.

Answer 15

[throughtheether]

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

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

Comments

[WTPIX]

@throughtheether
у меня пишется hp1905, но веб-морда от 3com'овской отличается только логотипом HP (так что думаю, что 3com замаскированный под HP). На root до sw1 тэгируются 75 и 350(что-то пропустил этот момент).
root <-> sw9 нетегируемый 350 и все
sw2 <-> sw3 указал.

Я вообще дело с vlan не имел. Настраивал человек несколько лет назад такую систему. Смысл в этой системе для телефонии. За рутом стоит роутер, который через вланы пропускает телефонную связь от другого провайдера.

Answer 16

[throughtheether]

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

Comments

[WTPIX]

@throughtheether
ну, с этимим свитчами легче в том плане, что применение настроек без сохранения после перезагрузки вернет в нормальный режим.
Но, в любом случае это все будет делаться как минимум во вторник рано утром.

Но, есть большое НО. На 49 порту свитча 350 влан кинут в сторону sw9, на котором большое кол-во серверов(скорее всего использующих этот влан). Попробую с вланами разобраться в понедельник более конкретно, но что-то мне кажется, что с предложенным Вами вариантом рухнет телефония. Буду пробовать и отписывать.

Answer 17

[throughtheether]

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

Comments

[WTPIX]

@throughtheether
в общем, перевод sw2 26 порта на нетегированный влан1 прошел успешно, а вот перевод 49 порта рута с 350 на 1 влан завалил всю сеть.

[throughtheether]

>перевод sw2 26 порта на нетегированный влан1 прошел успешно,
это хорошо

>а вот перевод 49 порта рута с 350 на 1 влан завалил всю сеть.
я правильно понимаю, что сеть не работала более минуты как минимум и затем вы откатили изменения?

[WTPIX]

@throughtheether
да, подождал с минуту, затем пошел к рут свитчу(минуты 2) проверил, снова, работоспособность сети, а затем откатил настройки.

з.ы. с sw2 сеть перестала работать всего на 1 секунду.

Answer 18

[throughtheether]

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

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

Comments

[WTPIX]

@throughtheether
в мануале написано, что это enable\disable, НО настройки портов вообще ничем не отличаются.
и такой момент, на остальных портах:
1 D
2 i
3 s
4 a
5 b
6 l
7 e
8 d
9 ,
10 D
11 i
12 s
13 a
14 b
15 l
16 e
17 d
18 ,
19 D
20 i
21 s
22 a
23 b
24 l
25 e
26 d
так что терзают сомнения, что это enable\disable. Но что это за буквы найти не могу информации.

[WTPIX]

в мануле:

STP - Displays if STP is enabled on the port. The possible field values are:
Enabled - Indicates that STP is enabled on the port.
Disabled - Indicates that STP is disabled on the port.

и ничего о других буквах нет. Так же, stp точно включен на 25 и 26 портах.

[WTPIX]

@throughtheether
уф, в общем, нашел в чем затык был на sw2 - sw3 это оказался SFP модуль, который не хотел работать адекватно. Заменил его, трафик пошел в обе стороны, НО, кольцо так и не срабатывает. Ждал 2 минуты. Сейчас линк sw2-sw3 отключен т.к. при его включении ложится sw3, sw4, sw5.

Answer 19

[throughtheether]

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

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

Answer 20

[throughtheether]

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

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

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

Comments

[WTPIX]

[WTPIX]

@throughtheether что еще странно:
трафик сейчас бегает по всем кольцу. Должен блокироваться от sw5 до sw4 на sw5 этот порт пишется alternate, но по факту там трафик в 10 Мбит и по всему кольцу нет места, где трафика нет. Должен быть флуд и сеть должна лежать, но этого не происходит. Какой-то бред творится с этим кольцом.
Может, стоит рутом другой свитч назначить?

з.ы. есть два свитча, которые могу пустить дополнительно в расход на это дело:
hp1810 8g
hp 3100a

[WTPIX]

@throughtheether
в общем, поигрался я немного с ними. В итоге: не воспринимает рут свитч изменения топологий, считает их по-своему как-то, из кольца один свитч выбиваю на секунд 20 и все участники кольца говорят о изменении топологии кроме рутового(он говорит о изменении топологии более суток). Мне кажется, что это из-за того что свитч Allied Telesyn, а все остальное типа HP. как насчет рутом сделать sw9 ? Я так понимаю для этого нужно бридж приорити ему поставить выше.

[WTPIX]

@throughtheether
еще заметил странную вещь
на sw1 designated bridge id:
25port 32768-00:15:77:fd:40:00 (id root bridge)
26port 32768-20:fd:f1:96:cb:90 (id this bridge)
на sw2 такая же история: айдишник sw1 и айдишник sw2
а вот на sw5 идет айдишник sw4 и sw6

Answer 21

[WTPIX]

Answer 22

[WTPIX]

нет.

Answer 23

[WTPIX]

@throughtheether

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

больше нет таких. Спецом проверил все.

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

грешен. Свитчи, которые hp, не дают инфо про bridge-id и я думал он составляется по принципу "Switch priority-max age:mac address".
Информация которую предоставляет свитч вот:

Comments

[throughtheether]

Bridge ID (термин RSTP) в данном случае составляется как Switch Priority-Switch MAC address. (термины из интерфейса со скриншота). Я понял, октет сразу за значением приоритета в случае с sw3-4,sw6-9 лишний.

Answer 24

[WTPIX]

@throughtheether

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

на всех остальных нетегированый 1влан.
Я так понимаю, загвоздка именно в sw2 с нетегированым 350 вланом.

Answer 25

[WTPIX]

@throughtheether на серверах эти вланы не задействованы. Просто в рут свитч в 4 порт заходит другой провайдер, вланом через 8 порт, в который воткнут маршрутизатор, он заворачивает этот провайдер и отправляет до sw2, дабы там работала телефония.

Answer 26

[WTPIX]

@throughtheether
В общем, подумалось, что мало 2 минут. Опять замкнул кольцо, 5 минут ждал ничего не поднималось, решил на sw2 вернуть 350влан в сторону sw3 и все завелось так, как я этого хотел и sw5 говорит, что 26 порт "Alternate". Но вот беда: sw1, sw2, sw3, sw4, sw5 говорят, что топология изменилась (5 минут назад), все остальные свитчи в т.ч. root, говорит, что топология поменялась 2 часа назад. хотя все свитчи признают рута верно. Мне кажется или тут все равно что-то не то и при очередном отключении какого-либо свитча трафик не пойдет в обход?

Answer 27

[throughtheether]

на sw5 этот порт пишется alternate, но по факту там трафик в 10 Мбит и по всему кольцу нет места, где трафика нет

Линк блокируется только с одной стороны (sw5). Другая сторона, видимо, продолжает слать трафик и в этот порт, ничего страшного. Я думаю, что это какой-то броадкаст. Если это юникаст, то, теоретически, соответствующая запись таблицы MAC-адресов через некоторое врем должна устареть и быть удалена.

еще заметил странную вещь
на sw1 designated bridge id:
25port 32768-00:15:77:fd:40:00 (id root bridge)
26port 32768-20:fd:f1:96:cb:90 (id this bridge)
на sw2 такая же история: айдишник sw1 и айдишник sw2
а вот на sw5 идет айдишник sw4 и sw6

Это нормально, так и должно быть, учитывая, что именно на sw5 блокируется порт. Можете сравнить с результатами эмуляции.

посидел покурил протоколы, на одном свитче стоял древний протокол, изменил на свежий. На еще одном свитче на линках был включен edge, выключил

Для корректной работы RSTP важно, чтобы edge режим использовался только на портах, подсоединенных к рабочим станциям, чтобы все STP-коммутаторы работали в режиме RSTP, и чтобы линки между коммутаторами работали в режиме p2p. Я, по-моему, неоднократно об этом упоминал.

Answer 28

[throughtheether]

Пока все работает - все стабильно.

Рад, что все работает, но позволю себе еще пару наблюдений (см. исправленную схему топологии). Судя по предоставленным вами данным (см. поля Path cost и Designated bridge ID), вы назначили на sw5 высокую стоимость интерфейсу до sw6, вместо интерфейса до sw4. Также, для устранения дальнейших эффектов (наблюдаются при смене корневого RSTP-коммутатора), лучше назначить интерфейсам линка одно и то же значение стоимости с разных сторон.