Протокол Spanning Tree - Выбор Regional Root в MST

Здравствуйте, коллеги! С вами Online Academy Network Education. Меня зовут Некенти Солнцев, и мы говорим с вами по-прежнему про протокол Spanning 3. Предыдущее видео про МСТ получилось достаточно объемным, и в него не вошел один важный вопрос. Как МСТ выбирает регионального рута в дереве АСТ? Мы этот вопрос сейчас разберем. Для того, чтобы понять, как МСТ выбирает регионального рута, нам нужно будет руководствоваться двумя простыми правилами. Первое. Если коммутатор считает, что рут за все дерево Common and Internal Spanning 3, или CIST, находится внутри региона, то есть рут за все-все-все дерево – это МСТ-шный товарищ, то тогда мы указываем его BridgeID в качестве регионального рута. Например, если вы только начали пересчет топологии, то есть вы еще ничего не знаете о соседях, вы считаете рутом самого себя за все дерево, за дерево АСТ, за дерево МСТ. Ну, вот вы ничего не знаете про других соседей, про другие коммутаторы. Естественно, вы считаете

рутом самого себя. Естественно, вы считаете, что вы сами находитесь самим с собой в одном регионе. Естественно, что вы в этом случае региональным рутом тоже считаете себя. Если вы считаете, что рут за дерево CIST, то есть за все дерево Spanning 3, включая не МСТ-шные свечи, находится внутри региона, но это не вы. Ну, то есть вы знаете, кто root, вы знаете, что он MST-шный товарищ, вы знаете, что external post cost за него нулевая. Ну, вот в этом случае вы указываете его ID-шник. В противном случае вы говорите, что root находится за пределами региона MST, и мы не можем воспользоваться этим правилом для указания регионального root. То есть у нас будет использоваться второе правило. Если наш коммутатор знает, что root за все дерево CIST находится за пределами региона, то root в региональном должен стать тот коммутатор, который находится ближе к root. Ну, в общем-то, логично, правда? Смысл в этом будет следующий. Если у вас есть какой-то root, который находится за пределами региона, весь регион MST схлопывается до одного как бы виртуального

свеча, внутри которого нет петель. И, соответственно, все возможные варианты, как добраться до root, который находится за пределами региона, ну, из них надо выбрать самый короткий. Ну, и, соответственно, после того, как мы выбрали самый короткий, надо убедиться, что внутри нашего региона не заблокированы никакие связи, как добраться до внешнего root. Поэтому использоваться будет очень простое правило. Если мы знаем, что root за все дерево CIST не находится внутри региона, то мы проставляем региональным root в ближе ID того коммутатора, у которого есть root-порт, который пограничный. Смысл в следующем. Допустим, у нас есть вот топология, как изображена на рисунке. 8 коммутаторов, 4 из них находятся в центре. Это MST-регион, то есть у них одинаковые настройки MST. Остальные пограничные свечи, они не MST-шные, то есть они используют обычные растопешные BPD-ушки для того, чтобы связываться с соседями. Здесь на картинке на коммутаторах изображены некие числа. Эти числа – это bridge ID. Естественно, bridge ID настоящая немножко длиннее, но мы воспользуемся

более короткой записей, потому что настоящие bridge ID, они просто не влезут на экран. Мы предположим, что у нас bridge ID двухбайтовый и два байта – вот они такие, как задано на экране. Понятно, что в этих двухбайтах есть какая-то часть, отвечающая за приоритет, есть какая-то часть, отвечающая за MAC-адрес, но вот в итоге у нас есть получается двухбайтовое значение, и мы будем это двухбайтовое значение считать bridge ID, имея в виду, что у настоящих свечей, естественно, bridge ID 8 байт. Так вот, после того, как у нас MST согласует всю сеть, естественным образом мы должны будем убедиться, что рутом за все дерево CIST должен стать тот коммутатор, у которого bridge ID самый маленький. В нашем случае это будет вот этот товарищ. Он будет рутом за дерево CIST. У него bridge ID самый маленький, более того, у него приоритет самый маленький, ну даже если бы приоритеты были бы одинаковые, ну значит у него MAC-адрес был самый маленький. И дальше мы посмотрим, как у нас коммутаторы будут строить до него root-порты. Те свечи, которые обычные RST, при условии, что у нас все линки имеют одинаковую

стоимость. Ну, если предположить, допустим, что это гигабитные каналы, ну значит они там будут по умолчанию в нацистских свечах иметь 4 копеечки стоимость. Ну, в нашем случае мы предполагаем, что вот root-порт на коммутаторе втором будет, который напрямую смотрит. Вот на вот этом вот свече root-порт у нас будет тоже непосредственно, который смотрит на CIST-шного root-а. Внутри региона у нас будут свечи знать, что 10 копеечек external root-path-cost и 10 копеечек internal root-path-cost. Ну, в нашем случае у нас вот этот вот root-порт будет и вот этот вот root-порт будет. И здесь, ну, какой-нибудь либо вот этот вот, либо вот этот вот. В нашем случае, BPDU-шка от 6-го приходит получше, поэтому верхний порт будет root-овым. Ну, и здесь root-порт, root-порт. На четвертом свече у нас root-порт будет, скорее всего, вот этот вот. Потому что BPDU-шки, которые будут приходить вот отсюда и вот отсюда, они будут одинаковые. У них будет только sender, bridge-id и различаться. А cost у них будет одинаковый. Соответственно, та BPDU-шка, которая будет приходить вот отсюда, она будет менее выгодная. Но, понятное дело,

что здесь нам не сильно интересно, какой из портов в итоге будет диссигнейт. Какой будет альтернает, главное, что root-ового порта там не будет. Что у нас в итоге получается? У нас есть некоторое количество CST-шных свечей. То есть, обычные RSTP-шные, например, свечи. Вот этот вот свеч второй, у него root-порт смотрит напрямую на root-а. Вот этот вот свеч, который смотрит на наш MST-шный регион. И четвертый свеч, который тоже смотрит на наш MST-шный регион. С ними все, в общем, понятно. А вот что происходит внутри региона? Внутри региона, как мы помним, у нас все свечи схлопываются до одного большого свеча. Как бы виртуального. То есть, они показывают всему остальному миру, что они на самом деле одинаковые. Один такой большой мега-свеч. А внутри между собой уже разбираются, какие порты надо будет заблокировать. Давайте разберемся, что за BPD-ушки будут отправлять наши свечи. То есть, у нас есть некоторое количество MST-шных свечей, и каждая из них будет отправлять BPD-ушку. В этих BPD-ушках будут проверить вектора. Вот здесь у нас шпаргалочка есть. Что у нас в MST-шных BPD-ушках содержится, и в каком порядке оно проверяется. Самым первым, с точки зрения

правительства вектора, будет идти root-bridge-id. Root-bridge-id у всех будет одинаковый. Это root за все дерево CIST, и здесь будут все единицы. То есть, у всех свечей в MST root-bridge-id будет 1,1,1,1. External root-path-cost. Мы предполагаем, что все линки здесь по 4 копеечки, гигабитные. Поэтому восьмой будет отправлять указание, что он может добраться за 4 копеечки. Седьмой будет говорить, я могу добраться за 8 копеечек. Но все остальные будут уже что-то еще свое отправлять, если они знают, как добраться до root-а. Но 6-й и 5-й свечи, они рассказывают, что они знают root-а 3-го и 4-го, что, в общем, не сильно интересно. То есть, потом их переубедят, и потом external root-path-cost у них всех будет синхронизировано. То есть, мы видим, что уже на этапе выбора между 8-м и 7-м свечом у 8-го свеча BPD-ушка оказалась круче. Потому что 8-й знает, как добраться до внешнего root-а за 4 копеечки, а 7-й знает, как добраться за 8 копеечек. Поэтому 7-й перековывается на самом деле и говорит, да, ты знаешь лучше root-а, чем я знал. И, соответственно, у меня будет через некоторое время

отправляться уже не за 8 копеечек, а за 4 копеечки BPD-ус External root-path-cost. И когда 8-й свеч говорит, я знаю, как добраться за 4 копеечки, он говорит, у меня root-порт смотрит наружу. То есть, я знаю root-а, который находится за пределами нашего региона, я до него могу добраться за 4 копейки, и у меня root-порт, соответственно, смотрит наружу региона МСТ. 7-й свеч, как только перековывается, начинает говорить, я знаю, как добраться до root-а, и external root-path-cost у этого root-а будет 4 копейки через 8-го, говорит, у меня root-овый порт уже смотрит на 8-й свеч. Но, соответственно, регионального root-а 7-й свеч уже не может поставить себя, потому что он не знает, что у нас root находится внутри региона МСТ. Он знает, что root находится за пределами региона МСТ, потому что 4 копейки external root-path-cost, на это непозрачные намекают. Ну и, соответственно, в этом случае он должен указать bridge ID того коммутатора в регионе, у которого root-порт – это boundary-порт. То есть, посмотрит наружу региона. У самого 7-го свеча root-порт смотрит внутрь региона,

поэтому он себя не может заставить быть региональным рутом. Поэтому 7-й свеч говорит, если 8-й свеч заявил себя региональным рутом, то, соответственно, мы его передаем дальше, что он будет региональным рутом. Вот 8-й свеч, когда себя заявлял региональным ртом, он пользовался правилом, что у него root-порт – это boundary-порт. Значит, мы знаем его ID-шник, мы знаем, что он себя не просто так поставил. Поэтому 7-й свеч заявляет, региональный root-ID – это 8-й свеч. Дальше. Что делает, допустим, 6-й свеч? 6-й свеч говорит, окей, я вижу в ПДУ-шке МСТ-шное, приходящее от 8-го свеча, и, соответственно, я вижу, что external root-path-cost – 4, internal root-path-cost – тоже 4, региональный root – 8-й. Ну, все, в общем-то. То же самое делает 5-й. 5-й говорит, я вижу в ПДУ-шке, которые приходят с указанием, что 8-й свеч – региональный root, первый свеч – это общий root, external root-path-cost – тут получается 4 копейки, internal root-path-cost – 8 копеек. И дальше пятому свечу надо сравнить только две БДУ-шки,

которые приходят от 6-го и от 5-го. Ну, он говорит, вот в порядке, в котором они у нас проверяются, root-ID одинаковые, external root-path-cost одинаковые, в нашем случае 4 копейки, региональный root-ID. Здесь у нас, получается, восьмерки, потому что восьмой свеч заявил, что знают, как добраться до рута за 4 копейки. Internal root-path-cost одинаковые, получается, здесь 4 копейки, здесь 4 копейки, здесь 4 копейки, здесь 4 копейки, то есть 8. Internal root-path-cost, которые приходят на пятый свеч. И дальше проверяются sender-bridge-ID, sender-port-ID, receiving-port-ID. Кто послал, в нашем случае 6-й свеч послал и 7-й свеч послал. Ну, соответственно, у 6-го свеча получается бы подушка круче, чем у 7-го. Поэтому мы root-ом объявляем порт, который смотрит на 6-й свеч, а порт, который смотрит на 7-й свеч, мы говорим, что это у нас будет alternate-порт и блокируем его. Ну и вот по такому правилу у нас получается следующее. Давайте сотру все с экрана. Что у нас в итоге получается? Резюмируя предыдущие все высказывания,

root-ом за все дерево CIST у нас будет выбран первый коммутатор. У него самый маленький bridge-ID вообще из всех свечей, поэтому он закономерно становится root-ом. Дальше. Коммутатор, который ближе всего к root-у в регионе MST, который будет получать самую выгодную BPD-ушку, это 8-й свеч. Он будет региональным root-ом. Исходя из этих двух правил, у нас будет вычисляться, какие порты получат роль root-овых портов, какие порты получат роль alternate-портов. В нашем случае root-овые порты будут, ну, у 8-го свеча, это понятно, порт, который смотрит на рута напрямую, у 2-го то же самое. У 7-го свеча порт, который смотрит на оригинального рута, будет рутовой. У 6-го свеча тоже порт, который смотрит на оригинального рута, будет рутовой. У 5-го свеча BPD-ушки, которые приходят со стороны 6-го и 7-го, держатся между собой. Контент одинаковый, поэтому по CACE выигрывает 6-й свеч. Поэтому рутовый порт у нас будет тот, который смотрит на 6-й свеч. На 3-м и на 4-м свече картинка будет одинаковая. Рутовый порт будет смотреть на регион MST. То есть, соответственно, вот здесь будет root-порт и вот здесь будет root-порт.

Все остальные порты, которые формируют петлю до root-а, до root-а CIS-тишного, они будут заблокированы. Они будут назначены alternate-портами. То есть, вот этот вот порт у нас будет заблокирован, это будет alternate-порт. На пятом свече порт с стороны 7-го будет заблокирован, этот снова alternate-порт. И на третьем и четвертом свече между собой эти два свеча подерутся. И на основании того, у кого sender bridge ID будет меньше, тот свечу получит роль designated свеча. А второй будет заблокирован. Ну, соответственно, опять же, это у нас вот четвертый будет. У него bridge ID будет больше, чем у третьего. Вот по такому правилу вы сможете легко определить, какие порты должны быть заблокированы или разблокированы в регионе МСТ и за его пределами. Теперь задачка на понимание. У нас есть 9 свечей. Эти 9 свечей разбиты на 3 группы. Все свечи в группе настроены одинаково, однотипно. И у нас вся топология разбивается на 3 регионы МСТ. Соответственно, верхний регион – это условно первый регион. В нем свечи первый, второй и третий. В нижнем левом регионе втором, условно втором, свечи четвертый, шестой, восьмой.

И, соответственно, в третьем регионе у нас свечи пятый, седьмой и девятый. Опять же, то же самое правило. Bridge ID у нас двухбайтовый для упрощения записи. Возникает вопрос. Исходя из того, что вы теперь знаете правила, как ведут себя свечи внутри региона и за его пределами, что произойдет, какие порты Spanning 3 здесь заблокируют и какие разблокируют. Я сейчас предлагаю вам поставить видео на паузу, перерисовать эту картинку к себе на бумажку и на этой бумажке решить задачу. Соответственно, показать, какие порты будут заблокированы, какие порты будут разблокированы. Прямо вот напротив каждого порта напишите, этот порт будет root, этот порт будет alternate, этот порт будет designated. Бэкапных портов у нас тут, очевидно, нет. После чего снимайте видео с паузы и посмотрите, как эта задача правильно решается. Итак, ставьте видео на паузу. Раз, два, три. Для тех, кто решил задачу, или для тех, кто любопытный, мы сейчас разберемся, как эту задачу можно решить.

Итак, что мы здесь знаем? У нас есть три региона. Первый, второй и третий. То есть три свитча в каждой группе настроены однотипно. И вот таких групп у нас тоже три. Давайте посмотрим, кто будет root за все дерево CIST. Это будет свитч с самым маленьким BridgeID. Ну, очевидно, здесь это будет самый первый свитч. И внутри региона первого у нас получается CIST-шный root. Первый регион у нас работает довольно просто. Первый свитч выбирается root и CIST-шным, и региональным. И, соответственно, второй и третий свитчи выбирают root-овые порты, как они могут добраться до первого свитча выгодным образом, и блокируют свои порты, которые формируют петлю. Но в нашем случае у третьего свитча порт формирует петлю, он будет назначен alternate-портом. Те порты, которые в первом регионе никак не обозначены, и не пограничны при этом, они у нас будут десигнает портами. Давайте разберемся, что будет происходить во втором регионе. ВПДУшки, которые будут приходить от второго и от третьего свитча, они будут примерно одинаковые. У них будет почти одинаковый priority-вектор,

за исключением sender-bridge-id, sender-port-id или saving-port-id. На самом деле здесь показан priority-вектор, как будто бы он имеет немножко другой формат по сравнению с RSTP. Но если вы вспомните, как устроен формат MST-шной ВПДУшки, вы, безусловно, вспомните, что эти поля там идут не по порядку. Сначала идет root-bridge-id, потом external root-path-cost, потом региональный root и потом sender-port-id. Когда вы отправляете MST-шную ВПДУшку на boundary-порт, сосед будет читать ее не как MST-шную ВПДУшку, он будет читать ее как RSTP-шную ВПДУшку, если он сможет. Ну или как STP-шную, опять же, если он сможет. Они по формату, в принципе, совпадают. У них шапка примерно одинаковая. Root-bridge-id. Ну, там и будет root-bridge-id. Здесь ничего нового не придумали. External root-path-cost превращается в обычный root-path-cost. Соответственно, региональный root-id – это sender-bridge-id. И sender-port-id – это и есть sender-port-id.

Так вот, когда приходят ВПДУшки от первого региона, вот этот первый регион выглядит для всех свечей за пределами своего региона как один такой большой мега-свитч. У него отправляются одинаковые ВПДУшки с одинаковым root-bridge-id, с одинаковым root-path-cost, с одинаковым полем sender-bridge-id, который на самом деле показывает регионального рута. И у них единственное, что будет различаться – sender-port-id. То есть, для ВПДУшек, которые приходят на 6-й и на 8-й свитч, они будут одинаковые, у них только sender-port-id будут различаться. А может, и не будет. То есть, может быть, что они будут посылать одним и тем же портом. То есть, допустим, представьте себе, что это две одинаковые железки одной и той же модели. И у нее вот здесь, допустим, Fast Ethernet 0.0. И вот здесь Fast Ethernet 0.0. Ну, соответственно, у них тогда и sender-port-id тоже будет одинаковый. Ну, такое может быть. Тогда ВПДушки просто будут идентичны. Что делают 6-й и 8-й свитч между собой, когда они принимают такие ВПДушки? На 6-й свитч приходит ВПДушка. У нее root-bridge-id указан первый.

То есть, здесь у нас root-bridge-id единички. Дальше. Root-path-cost external-rpc 0. В ВПДушки, которые приходят к нам со стороны первого региона, у них указан root-path-cost 0. Как будто бы вот этот вот один большой мега-свитч за первый регион – это root. Дальше. Сender-bridge-id. Кто послал эту ВПДушку? Сender-bridge-id. Тоже получается единички. И у 6-го свитча, и у 8-го свитча ВПДушки приходят одинаковые. Ну и sender-port-id. Там уже не важно, что написано. В этом случае у нас и 6-й, и 8-й свитч могут быть одинаково хорошими региональными рутами за второй регион. 4-й свитч региональным рутом не должен быть ни при каких обстоятельствах. Он до рута дальше, чем 6-й и 8-й. Поэтому он по факту не принимает участие в выборах регионального рута. А вот 6-й и 8-й подерутся между собой. 6-й отправит ВПДушку, я знаю, как добраться до хорошего рута.

8-й отправит ВПДушку, я знаю, как добраться до хорошего рута. Кто из них выиграет? Правильно, 6-й. У него айдишник меньше. Поэтому ВПДушка, отправляемая 6-м свитчом, будет суперер по отношению ко всем остальным в регионе. И он будет выбран региональным рутом. А, соответственно, 8-й свитч проиграет. Он скажет, да, у меня, конечно же, рутовый порт был, который смотрит наружу. Но ВПДушка, которая приходит со стороны 6-го свитча, она лучше. То есть у нее сендер бриджа ID будет меньше. Ну и, соответственно, 8-й свитч говорит, окей, я сдаюсь, я не буду региональным рутом. Я помечаю как рутпорт, то, что вот рутпорт смотрит на 6-й свитч. И вот что у нас получится. 6-й свитч выбирается рутом. У него рутпорт смотрит на первый регион самым выгодным образом. Поэтому он же является региональным рутом. Он рассылает свои БПДушки всем остальным. Все остальные говорят, да, мы действительно признаем тебя региональным рутом. 8-й свитч с рутовым портом смотрит на 6-й.

4-й свитч с рутовым портом смотрит на 6-й. 8-й и 4-й подрались в сегменте горизонтальном, который связывает их между собой. 4-й свитч выиграл эти выборы за право стать диссигнаетом свитчем. 8-й свитч свой порт заблокировал, потому что он будет альтернейтом. В третьем регионе у нас абсолютно та же самая картина. 5-й и 7-й свитч, соответственно, получают БПДушки от 2-го и 3-го. Ну, то есть от 3-го и 2-го. 5-й получает от 3-го, 7-й от 2-го. И у нас получается следующая картина. БПДушки, которые принимают 5-й и 7-й свитч, в общем-то, практически идентичны. У них одинаковое то, что стоит на месте root bridge ID нормальной БПДушки. Это root за CIST. Это одинаковые, соответственно, root path cost, потому что БПДушки, которые отправляют что 2-й, что 3-й свитч, и на месте root path cost, в том месте, где у нормальной БПДушки root path cost, они отправляют external root path cost, MST-шную. А external root path cost для первого региона, она нулевая, потому что CIST-шный root находится внутри первого региона.

Дальше. Сендер-бридж ID у этих БПДушек тоже одинаковый, потому что что 2-й, что 3-й свитч на месте сендер-бридж ID отправляют ID-шник регионального рута. Ну, то есть вот тот самый 1-1-1-1-1. Поэтому единственное, чем будут отличаться эти БПДушки, это сендер-порт ID. Вот второй свитч и третий свитч, они отправляют каждый свой ID-шник. Но, может быть, опять же так получится, что эти БПДушки могут быть в части даже порт ID, отправляемые в одинаковые. Ну, такое теоретически может произойти. Что происходит на пятом и седьмом свитчах, соответственно, когда они получают такие БПДушки? Они оба говорят, ух ты, какая клевая БПДушка. Я, видимо, буду считать рутом его, потому что рут ID, который там пришел, единички, они круче, чем мой. Поэтому я буду рутом считать его, и они дружно начинают по МСТ друг к другу рассылать информацию. Я знаю, как добраться до рута через наружу, потому что у них рут-порт внешний, они ставят рутом региональным самих себя. Внешний рут идет в рут ID, а региональный рут идет в региональный рут ID. Ну, так вот, они отправляют БПДушки.

Что пятый, что седьмой свитч отправляют БПДушку со следующим МСТ-шным priority-вектором. Root Bridge ID, единички, потому что они знают, какой внешний рут у нас будет. External root path cost, четверочка, ну там сколько у нас линк стоит до первого региона. Вот столько они и заявляют. Дальше, региональный рут, они говорят, у нас у обоих рут-порты пока что смотрят наружу, поэтому пятый свитч заявляет себя региональным рутом, седьмой свитч заявляет себя региональным рутом. Они в какой-то там центр порта ID тоже поставляют. Дальше, седьмой свитч принимает БПДушку пятого и говорит, ага, у нас есть походу более правильный кандидат на становление региональным рутом. Если он мне отправил БПДушку с указанием себя в качестве регионального рута, значит у него рутовый спорт смотрит наружу. И моя БПДушка хуже, чем его. Поэтому я себя, соответственно, перестаю считать региональным рутом. Я считаю региональным рутом его. И я его дальше передаю в своих БПДушках.

То есть БПДушке, который после того, как пятый свитч пришлет седьмого свою БПДушку, сам седьмой свитч начнет пересылать информацию о региональном руте дальше. Поэтому в БПДушках седьмого свитча будет дальше указываться региональным рутом пятый. Ну и девятый свитч, он, соответственно, там безнадежно далеко от всех находится. Он не на границе региона. И ему, в общем-то, все равно, что дальше будет происходить. Девятый свитч просто говорит, окей, я буду считать рутом кого скажете. Ну пятый, значит пятый. Поэтому пятый свитч у нас выбирается рутом. Он ближе всего к центральному руту, к сиаэстишному руту. Седьмой свитч топологически так же далеко или так же близко от этого центрального рута. Но у него айдишник не вышел рожей. У него айдишника больше. Поэтому он не региональный рут. Он сдается. И, соответственно, у него рут-порт будет смотреть на пятый свитч. То есть внутрь региона. Ну и получается. Пятый свитч у нас выбирается рутом. Седьмой свитч выбирает рут-порт, смотрящий на пятый. Девятый свитч выбирает рут-порт, смотрящий на пятый. Девятый свитч, соответственно, имеет порт, формирующий петлю.

Он этот порт выключает, помечая его как alternate. Все остальные порты, которые у нас между регионами формируют петлю, свитчи должны будут заблокировать. Соответственно, у нас блокируются порты на восьмом свече, который смотрит в сторону первого региона, на седьмом свече и на пятом. Вот эти порты, они действительно формируют петлю, они тоже будут заблокированы. Что касается горизонтальных связей между вторым и третьим регионом, у нас будет работать следующее правило. Поскольку оба линка фактически формируют петлю, какой-то из свечей в каждом линке, что между пятым и шестым, что между седьмым и восьмым, должны будут заблокировать порты. И хотя бы один из свечей в каждом линке должен будет свой порт пометить как альтернет и заблокировать его. Если бы у нас работали нормальные правила выбора свеча, который будет блокировать порт, то у нас надо было сравнивать бы ID-шники, отправляющие хппдушки свечей.

Но в нашем случае у нас работает MST, и на месте Sender Bridge ID у нас отправляется ID-шник регионального рута. Что шестой, что восьмой свеч во втором регионе, на месте Sender Bridge ID, где нормальные бпдушки отправляют Sender Bridge ID, будут отправлять ID-шники своего регионального рута, то есть шестого свеча. Равным образом, что пятый, что седьмой свеч, когда будут отправлять свои бпдушки в линке, они будут отправлять ID-шники регионального рута, то есть пятого. И соответственно схлестнуться между собой не отправить либо подушек по факту, а региональные руты, у кого из них айдишник будет меньше. И соответственно пятый свитч имеет айдишник лучше, чем шестой. Поэтому оба свитча в третьем регионе порты свои будут помечать как диссигнейтед и пятый, и седьмой. А вот шестой и восьмой свитчи свои порты заблокируют. Потому что айдишник регионального рута в втором регионе хуже, чем айдишник регионального рута в третьем регионе. Неважно, какие ID-шники будут у самих свечей. В нашем случае они больше, но они могли бы быть, в принципе, меньше.

Вот в такой вот ситуации, как показано на рисунке, Spanning 3 сначала будет выбирать корневой рут, потом он будет выбирать регионального рута в каждом регионе. Дальше, после того, как региональный рут в каждом регионе выбран, он посмотрит, какие порты внутри региона надо заблокировать, какие оставить разблокированными. И дальше, между регионами, он заблокирует те петли, которые получаются как будто бы, если у нас наши регионы схлопнулись до отдельных свечей. Проверьте, пожалуйста, что у вас получилась самостоятельная работа точно так же, как она выглядит у меня. То есть у нас порты, которые не помечены, это будут достигнение порты, они останутся разблокированы. Порты, которые помечены кружочками, это рут порты, они, естественно, тоже останутся разблокированы. Все остальные порты будут заблокированы. Ну, более строго, конечно же, рут порты и диссигнэйтед порты разблокируются, а все остальные останутся заблокированы. Поскольку Spanning 3, как мы помним, сначала все блокирует, а потом потихоньку разблокирует.

Ну, как бы там ни было, кружочками показаны рут порты, крестиками показаны альтернейт порты. Если порт никак не помечен, это диссигнэйтед порт. Убедитесь, что у вас все точно так же. Если что-то не получилось, пишите в комментах и задавайте свои вопросы. Я надеюсь, что после этого вы научитесь работать с протоколом МСТ, будете понимать, как МСТ выбирает регионального рута, что МСТ блокирует и разблокирует в случае, когда у вас есть несколько регионов. Ну и спасибо за внимание. Спасибо за внимание.