Pull to refresh

Comments 18

Надо больше аббревиатур, и почаще, почаще!
Если серьезно — пожалуйста, во вступлении хотя бы делайте пометку,
какая теоретическая подготовка нужна для понимания статьи.
А то первый же абзац откровенно пугает неподготовленного читателя.
Знаете, как в учебниках пишут — требуются базовые знания стека сетевых протоколов, ну и так далее.
И таки да — я не сетевой инженер, и с трудом понял содержание статьи. Тем не менее, спасибо.
Это не я, это MSTP такой) По поводу пометки, я там указываю на то, что почитать перед этим.
А, ссылки на STP и RSTP. Как-то не заметил, виноват
инстанция, -и; ж. [лат. instantia — непосредственная близость] Отдельная ступень в системе подчинённых друг другу органов власти

instance — экземпляр, копия

Стоит отметить что MSTP может работать не очень корректно если в одной сети используются разные поставщики оборудования. Может знатного "трясти" кольца иногда.
Спасибо за статью, в своё время её ох как не хватало.

RPVST+ и PVST+ есть только на оборудовании Cisco, а на Cisco нет классического STP и RSTP. Что нам делать, если в топологии участвуют другие вендоры?

Просто подключать это оборудование к Cisco :). В рамках Vlan 1 корректно построится loop-free топология. Для этого BPDU в рамках vlan 1 использует формат IEEE, а вот в рамках других vlan'ов — прориетарный. И даже если на транке убрать vlan 1, всё равно BPDU для него будет передаваться. Всё это обеспечивает совместимость при работе с оборудованием других вендоров.
Пакеты ходить будут, петли не будет, но просто подключив, скорее всего, все будет работать не так как ожидалось.
Из практики, всё работает нормально. И это рабочий вариант, не «костыли».
Если стыковать Rapid PVST+ с MSTP, нужно, так как long path-cost в MST — единственный вариант.

Стоит отметить, что Long Path-Cost имеет отношение и к самому Rapid PVST+. Если у нас есть линки 40 Гбит/с и более, то его следует включить. И не важно, есть у нас в сети коммутаторы других вендоров или нет.

Безусловно для при взаимодействии коммутаторов разных вендоров рекомендуется использовать именно MSTP. Не призываю для этого использовать Rapid PVST+ :). Я лишь указал, что это работает, так как изначально задумано в самой реализации протокола.
Спасибо за статью. Люблю задавать вопрос на собеседовании — какие способы балансировки нагрузки знаете. Люди называют кучу технологий от multichassis etherchannel и GLBP, до HA Proxy и Round Robin DNS, а вот про MSTP обычно даже не вспоминают :) Что, вероятно, так же говорит о популярности MSTP в современных сетях.
Рад, что понравилась. Пару раз встречал ситуацию, что, к примеру, HP коммутаторы подключают к Cisco, включают там RSTP и забывают. Работает типа, и не думают что за топология построилась и что там не то, что балансировка, но и оптимальность выбора пути страдает.
На Cisco есть ограничение в количестве инстанций STP или RSTP на одном коммутаторе в зависимости от модели. То есть добавив 128 вланов на каком-то коммутаторе, мы сталкнемся с таким ограничением. Ссылка тут

Обычно про ограничения для Cisco девайсов пишут в Scalability Guide:
Verified Scalability for Cisco Nexus 5600:
www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/verified_scalability/730N11/b_N5600_Verified_Scalability_730N11/b_N6000_Verified_Scalability_700N11_chapter_01.html
Virtual Ports:

Verified Value Mode
48000 Rapid PVST+
96000 MST
Указал ту сслыку, так как там несколько моделей рассмотрены и показана какая ошибка вылезает.
Verified Value Mode
48000 Rapid PVST+
96000 MST

Резанули цифры. Максимальное количество инстансов MSTP — 65. И это не аппаратное ограничение, какой либо платформы. Это ограничение самого стандарта. Информация обо всех инстансах должна умещаться в одном BPDU. Размер пакета — 1500 байт. И хоть получается максимум 88 инстансов, в стандарте в итоге прописали 65. Чего с лихвой хватает для любых сетей.

То что Вы привели — количество виртуальных портов на коммутаторе. Очень абстрактная сущность равная кол-ву VLAN * на кол-во портов.
Спасибо за статью, очень полезная, попутно два вопроса (к сожалению, в настоящий момент не на чем проверить):
1. После подключения региона B к региону A, не переехал ли Regional Root а регионе A с SW3 на SW4 или если CIST Root Bridge находится внутри региона он (Reg. Root) не меняется при подключении других регионов? Как тогда быть с формулировкой, что «и никогда не может Regional Root Bridge быть коммутатор без граничных портов»?
2. По поводу «Таким образом, выбор Regional Root Bridge...» пункт 2 может быть лучше сформулировать не «Lowest Regional Bridge Identifier» а «Lowest Boundary Bridge Identifier (BID)»?
Спасибо.
Очень тонкое замечание, спасибо.
1) Здесь у меня оговорка, точнее в случае региона, где находится CIST Root, то именно он и будет Regional Root. и никогда не может Regional Root Bridge быть коммутатор без граничных портов»- надо добавить за исключением CIST Root.
2) Boundary Bridge ID — это добавления нового понятия, мне кажется первое ничем не хуже)
Sign up to leave a comment.

Articles