MST

продолжаем рассказ про коммутируемой сети проговорили мы с вами про поведение обычного спальнянг 3 совершенно произвольного ванильного так называемого 802 1 дешного обсудили чем хорош этот протокол чем он был плох для чего придумали соответственно быстрый спальник 3 обсудили мы также поведение фирменного цисковского спальнинг 3 который по вест и и пришла пора обсудить стандартный протокол который называется мст его иногда называют мст иногда называют мстп иногда называют 802 1с это протокол который на самом деле стандартный который вошел в стандарт 802 1 киу 90 не зелёшь 2003 года и с тех пор там прекрасно живет то есть еще раз подчеркнул это протокол спальнинг 3 с поддержкой виланов он определен в том же самом стандарте в котором определены сами 802 один кишки виланы а этот протокол также как и pvst будет строить много разных деревьев только pvst строит отдельно

дерево за каждый отдельный вилан и он отправляет бы потому что говорит это был подушку указывает поведением моего дерева за определенный vlan а маст будет действовать еще хитрее он будет строить несколько деревьев но не за каждый вилана отдельное дерево а просто дерево в отрыве в абстракции от виланов а затем будет говорить, что в этом дереве у нас есть роли портов и состояние этих портов. И коммутация виланов определенных будет зависеть от конкретного дерева. То есть смысл заключается в том, что мы строим деревьев меньше, чем виланов. Мы говорим, строим дерево, допустим, номер один. Просто обычное абстрактное дерево. Говорим, что у нас в этом дереве есть разные коммутаторы. Кто-то из них выбирается рутом, кто-то, соответственно, не рутом, кто-то на рута смотрит рут-портами, кто-то на рута смотрит alternate-портами, кто-то designated-портами смотрит на всех остальных. И вот затем, соответственно, в дереве у нас выбираются роли. Дальше в дереве у нас порты переходят в forwarding или в blocking, в discarding.

И в зависимости от вот этого состояния forwarding или discarding конкретного дерева на конкретном порту мы включаем или выключаем коммутацию в определенных виланах. В чем фишка? Фишка как раз в том, что деревьев может быть сильно меньше, чем виланов. И, как правило, дерево у нас... нам нет смысла строить столько же деревьев, сколько виланов. Если у вас там 4096 виланов или даже 4094, ну или там 4000 виланов, все равно в любом случае этих виланов тупо много. И, соответственно, если у вас много виланов, много портов, в которых эти виланы принимают участие, особенно если много транков, вы рано или поздно столкнетесь с проблемой, что ваши свечи просто перегружены, они отправляют в хрен ву тучу этих самых БПДУшек за разные виланы, если мы говорим про ПВСТ. И в каждом вилане они по-честному все вычисляют. Хотя, на самом деле, им достаточно было бы сказать, у нас есть вариант пойти, как бы заблокировать вот такой порт, или есть вариант заблокировать другой порт. Ну, соответственно, нам нет смысла вычислять по-честному. Давайте посчитаем, какой из этих двух портов мы блокируем в первом вилане,

в втором вилане, в третьем вилане, в 4094 вилане. Мы говорим, давайте мы построим два дерева. В одном из них мы заблокируем один порт, в другом из них мы заблокируем другой порт, и дальше все наши там 4000 виланов привяжем к одному из этих двух деревьев. у мст будет поддержка от 0 до 64 деревьев таких пользовательских кастомерских они будут называться специальным словом instance мст и это мст instance это вот то самое дерево которое мы можем строить в нормальной ситуации вам нужно будет строить либо одно дерево либо два дерева ну очень редко бывает нужно больше если говорить процессе например то циски поддерживает до 16 пользовательских деревьев но по стандарту эти деревья нумеруются и номер от нумерации у них идет от 0 до 64 дальше есть дерево соответственно стандартное который называется а ст это дерево используется для симуляции обычного протокола спаринг 3 потому что мст совместим обратно с классическим ванильным

спаринг 3 также как в циске когда придумывали pvst догадались придумать какой-то механизм совместимости с обычным ванильным спаринг 3 там если вы помните заимствуются для обычного ванильного спаринг 3 дерево вилана номер один вот здесь для взаимодействия с классическим ванильным спаринг 3 используется дерево номер 0 или у него есть специальное название мст instance 0 либо и у него есть еще более специальное название и интернет спаринг 3 это одно и то же по сути вот интернет спаринг 3 это некое дерево внутри мст одну из деревьев в котором бегает информация как этот самый мст будет сосуществовать со внешним миром то есть вся информация которая от внешнего мира будет приходить от того что есть это рут издалека нам известен вот она будет складываться в ст для того чтобы все это дело нормально работал нам нужно будет привязывать виланы к этим самым деревьям то есть мы создаем деревья говорим что вот дерево номер один дерево номер два и виланы там с 1 по тысячные

привязываются к дереву номер один авир виланы с 1001 по 2000 привязывается к дереву номер два проблема некоторая заключается в том что на всех коммутаторах которые у вас работают по протоколу мст привязки вилана в к деревьям должны будут быть одинаковые иначе может быть некрасивая ситуация да вы на одном на одном коммутаторе сказали что у вас привязка вилановых деревьям выполнен одним образом и соответственно виланы посмотрели на то что конкретный порт на конкретном дереве у нас соответственно выглядит как 10 may этот фарвардинг и соответственно они включили farwind на этом порту в определенных вилана но те же самые виланы если они будут в другом дереве на другом коммутаторе они тоже могут в одном и том же линке перейти в фарвардинг потому что в другом дереве другой коммутатор себя тоже считал 10 гнин фарвардинг у нас нет проблем с тем что два коммутатора в одном и том же линке будут друг на друга смотреть интерфейсом в котором они себя считают десигнаетами просто в разных деревьях но если у нас виланы будут привязаны к двум

разным деревьям то возможно ситуация при которой у нас фарвардинг трафика в определенном вилане будет выполняться в том порту где он выполняться не должен поэтому спаринг 3 мст будет предпринимать специальные усилия для того чтобы проверить действительно ли у нас все виланы привязаны к разным деревьями одинаково так дальше еще один новый термин который у нас будет это я уже говорил про термин и ст интернет спаринг 3 или а есть и есть термин си а есть и common and internal спаринг 3 это дерево которое будет строиться за вообще всю пологию спаринг 3 включая соседи которые спаринг 3 м стэшной не поддерживают который работает с ванильным спаринг 3 или его в режиме совместимости или по-честному ванильный спаринг 3 запускают это значит что в этом дереве будут вообще все свечи даже те которые не мастер шны а просто какие-то пришлые вот си а есть это common and internal спаринг

3 internal это внутренняя спаринг 3шная часть публичного скажем дерево а common часть это вот те которые все остальные поэтому common and internal спаринг 3 си а исти это вот то что вообще все дерево спаринг 3 который взаимодействует с окружающими коммутаторами если говорить про циски то в цисках стоимости для мст у портов будут по умолчанию длинные если вы помните там у нас были 119 42 которые за говорил вам запомнить стоимости портов вот и они включаются по умолчанию для pv ст что медленного что быстрого pv rst но все равно это как по умолчанию короткие стоимости а вот мы с вами также говорили что в 2004 году стандарт 802 1d поменял стоимости на другие на рекомендованные стоимости поменял на 20 терабит деленное на скорость интерфейса и поэтому циска для мст используют как раз по умолчанию эти самые

быстрые стоимости связано это с тем что если вы запускаете на цисках спаринг 3 то если вы запускаете pv ст эту ничего кроме цисок в этом pv ст скорее всего не будет до существуют другие вендоры которые пв ст поддерживают но тем не менее как бы с точки зрения циски какие-то заблудшие души которые можно в расчет не принять не принимать поэтому если мы используем pv ст эту или pv rst то используются короткие метрики именно в расчете на то что все свечи в себя будут вести одинаково в то же время если вы используете mst multiple сварнинг 3 100 в сети вместе с вами могут быть коммутаторы совершенно разных вендоров которые по умолчанию будут следовать инструкциям стандартов и стандарт и говорит однозначно что рекомендованные стоимости это вот как раз те самые 20 терабит делена скорость интерфейса поэтому циска в этой ситуации ведет себя тоже по стандарту ну вот если вы включаете pv ст у вас стоимости короткий если вы включаете мст у вас стоимости длинный один тот же порт получает разные стоимости

мст-шные бы пдушки будут похожи на стандартные на ванильные то есть там будет отправляться только одна бы подушка у которой заголовок будет такой же как у бп дужки стандартный медленного или быстрого спальнинг 3 то есть там заголовок в общем точно такой же идет но в заголовке обычного спальнинг 3 идет только один правильный вектор за одно единственное дерево которое строится в ванильном классическом спальнинг 3 а вам остается нас этих деревьев много но есть одно дерево специальное которое называется сия с тиком он интернет спальник 3 есть деревья те самые пользовательские которые мы можем создавать а можем и не создавать но в любом случае в абсолютно любой ситуации сия с ти дерево есть и поэтому тот правильный вектор который передается в бп дужке вот на месте обычного правильный вектора классической ванильной бп дужки будет передаваться именно правильный вектор дерево сия с ти поэтому если мы отправляем бп дужку мы страшно из соседний свитч не понимает что такое мст он говорит я знаю только

то что такое ванильный обычный спальнинг 3 то соответственно вот он увидит бп дужку который он поймет что имеется ввиду потому что именно дерево сия с ти ему будет интересно и важно так дальше у бп дужки мст не будет идти помимо стандартных заголовка 5 байт стандартного правильный вектор 22 байта стандартные таймеры 8 байт дальше идет расширение то есть у мст-ш на бп дужек просто есть хвост который находится там где у нормальных бп дужек ничего нет нормальный бп дужек заголовок править и вектор таймеры и все и дальше конец а вы мст-ш на его подушек заголовок правильный вектор дерево сия с ти который интересен всем окружающим таймеры и затем идет хвост вот этого хвоста раньше не было сейчас он появился в этом хвосте передаются как раз все остальные проверить вектора за те деревья которые в мст будут созданы если вдруг вы видите что у вас есть некий сосед который присылает вам бп дужку и

вы не знаете что такое мастету вы этот хвост просто не читаете если вы видите что сосед присылает вам бп дужку и это бабушка мст-шная и вы видите что это мст-шная бп дужка вы умеете читать этот хвост но вы первым делом проверяете корректно ли настроен сосед потому что если сосед настроен некорректно не сосед настроен противоречиво с вами то вы такую бы подушку не должны будете читать как настоящий мастер что вы скажете что я вижу что да да подушка мст-шная но сосед настроен некорректно сосед настроен противоречиво с нами поэтому мы будем часть только стандартный вот этот самый заголовок бп дужки читать мы не будем читать расширение мст-экстеншен в тех бы подушках которые отправлены соседями настроенными некорректно вот это вот механизм который позволяет не использовать какую-то штуку типа вот того что и которая циска придумал давайте вместе с бп дужками фирменными права авто отправлять рядышком по подушку стандартную вы

отправляете одну бп дужку и в ней сразу все проверить вектор а за все деревья расположены просто одно дерево которое должны прочитать все но идет самом начале а потом идет рассказ соответственно про то что остальное передается ну и вам не надо отправлять много разных бп дужек за много разных деревьев вы отправляете одну бы подушку за все деревья одновременно так дальше как будет выглядеть формат мастерной бп дужки вот заголовок бы подушки 5 байт ничего нового root bridge идти root path cost center bridge айди центр портойди и таймеры то есть это все вот обычные ванильные бп дужки заимствована если вдруг мы отправляем бп дужкам и стешно то сосед получает эту баба дужку вот как минимум то что сереньким здесь выделено он прочитать всегда сможет а дальше идет расширением и стешно который сосед будет читать только при условии что если вдруг ему будет это интересно так начинается это самое расширение с указания того что есть некое поле

спанинг 3 версия 1 если вы помните у спаринг 3 есть в заголовке указание на то что это за протокол то есть протокол вершин там для спаринг 3 всегда нули есть протокол вершин версия протокола да это как раз 1 байтовое поле в котором указывается что за спаринг 3 конкретно используется есть спаринг 3 медленный там указывается нули есть по нег 3 быстрый это соответственно двоечка вот соответственно есть как помимо нолика и двоечки еще остальные не используем значение в том числе и версия номер один который никогда не было который мы в курсе с вами проходили но это первая попытка сделать какое-то расширение для мст для спаринг 3 который на самом деле не прошло и вот для того чтобы показать чтобы подушку который мы отправляем будет иметь расширение но это расширение используется не

1 персия от рейс то самое первое поле которое есть это 1-байтовое поле длина последующего расширение первой версии вот она выставляется всегда в ноль 1-байтовое поле в котором указывается сколько полезных данных ваш бэп 2 бездв и передается с расширением первой версии но поскольку у нас У нас расширения первой версии нет, там всегда нули, это вполне естественно. И дальше передается расширение третьей версии. Вот это вот как раз указывает на то, что есть MST. У MST в Protocol Version Identifier 0x03, то есть троечка записывается. И в троечку мы говорим, что Version 3 Length, это расширение версии 3, указывается как раз MST Extension. Двухбайтовое значение указывает на размер вложения MST. И дальше идет собственно само вложение. Оно может быть переменной длины, учитывая, что деревьев этих самых вы наплодить можете сколько угодно. Что есть пристандарт и постстандарт? Ну постстандарт не знаю, что такое.

Есть стандартные MST, есть пристандартные механизмы. Заключаются разницы в вычислении чек-суммы. Там у нас будет про это, по-моему, слайд. То есть если вдруг вы отправляете BPD-ушку, вы указываете, как вы настроены. И вы это указываете в виде хэша. Вот этот вот хэш можно посчитать по-разному. Изначально предполагала CISCO, что считать этот хэш будет в итоговой версии стандарта одним образом. И она на рынок выпустила свечи, которые уже умели работать с MST, но так как CISCO предполагала, будет считаться хэш, по факту в протокол не вошло. И, соответственно, те свечи, которые CISCO выпускала до того, как финальная версия стандарта вышла, они, получается, считали хэш того, как настроен MST, некорректным образом. Так называемым престандартным. Ну и в итоге, да, когда стандарт вышел, просто в IOS появился флажок.

Как вы хотите отправлять ваш хэш? Стандартным образом или нестандартным? Престандартным. Так, до этого дойдем обязательно. Ну, соответственно, здесь я хотел бы обратить ваше внимание на то, что MST-шные BPD-ушки очень похожи на обычный быстрый Spalding 3. MAC-адрес тоже точно такой же, тип вложения в Ethernet точно такой же, тип BPD-ушки 0x02 точно такой же. То есть это не BPD-ушка Topology Change Notification, это не BPD-ушка Configuration, это единственная неповторимая BPD-ушка, которая есть в быстром Spalding 3. То есть по сути своей MST-шная BPD-ушка, это RSTP-шная BPD-ушка с хвостом. В хвосте написано всякое разное. Так, теперь нам понадобится новый термин. Этот термин будет называться регион. Регионом в MST будет называться совокупность свечей, которые настроены одинаковым образом, ну, непротиворечивым, скажем так. То есть если у вас есть несколько свечей MST-шных, вы можете отправлять BPD-ушки друг к другу.

И вы будете указывать, соответственно, как вы настроены. Вы будете отправлять вот эти вот самые BPD-ушки. У них будет передаваться в обязательном порядке priority vector, самый начальный, который есть. А затем будет передаваться расширение MST-экстеншн. Любой свеч может послать MST-экстеншн, но не любой свеч будет читать чужую MST-экстеншн. Вот два свеча будут настроены непротиворечиво, если они согласятся, что MST-экстеншн читать нужно. В противном случае они говорят, я вижу BPD-ушку с хвостом, но хвост мне неинтересен, я читаю от нее только наружную часть. Если у нас есть несколько свечей, которые настроены непротиворечиво друг с другом, которые читают MST-экстеншн, то вот эти свечи формируют регион. Регион по определению область неразрывная. То есть вот на картинке четыре свеча у нас в облачке зелененьким соединены. Это вот четыре свеча, которые настроены непротиворечиво друг с другом. Они понимают, что такое MST, они считают, что MST-шные BPD-ушки, которые они отправляют и принимают, это действительно правильные BPD-ушки.

Поэтому они полноценно участвуют в MST. Дальше есть свечи, которые настроены противоречиво. Либо они не понимают, что такое MST вообще, они посылают BPD-ушки обычные стандартные 802.1D-шные. Либо медленные, либо быстрые, не суть важна. Либо может быть такое, что сосед настроен в режиме MST, но настроен противоречиво. И он отправляет BPD-ушку, и по ней видно, что она настроена противоречиво. И в этом случае, что сосед не поддерживает MST, что сосед поддерживает MST, но он настроен противоречиво с нами, мы будем работать только с наружной частью BPD-ушки без MST-экстеншена. И получается, что у нас есть регион. Это совокупность свечей, которые настроены непротиворечиво друг с другом. У нас есть внешние какие-то свечи, которые тоже участвуют в MST, но только в одном единственном дереве, которое называется Common and Internal Spanning 3, или просто CST Common Spanning 3.

И, соответственно, что у нас здесь получается? У нас есть свечи, которые внутри MST-шного региона реплицируют все деревья. Это дерево AST в первую очередь. И плюс это деревья, все которые кастомные созданы, MST-A0, MST-A1 и так далее. То есть те свечи, которые настроены одинаково, вот они формируют регион, они синхронизируют между собой все деревья, включая дерево EST, Internal Spanning 3. Со внешними свечами идет разговор только по обычному Spanning 3 фактически. То есть мы отправляем или принимаем BPD-ушку, у которой читаем только стандартное начало BPD-ушки, начало заголовка. И поэтому мы говорим, что со внешними свечами мы взаимодействуем. И внешние свечи работают с так называемым классическим Spanning 3, Common Spanning 3. Ну, давайте можно назвать его ванильный Spanning 3. Ну и, соответственно, ванильный Spanning 3 снаружи, плюс наш Internal Spanning 3 внутри, вместе формируют дерево CIST.

Так, так, так, так. Каким образом свечи будут определять, находятся ли они в одном регионе или нет? У них будет в заголовке MST передаваться самое первое поле MST Configuration Identifier. Оно кривой длины всегда 51 байт. Запоминать это не надо, но просто так любопытно, да, что 51 байт заголовок, а не поле в заголовке будет передаваться. Эти 51 байт формируются за счет немножко хитрой структуры. Вот Configuration Identifier здесь отдельно расписано. Давайте попробую порисовать. Да, это вот это вот поле, оно вот таким вот образом выглядит. Первый байт, он всегда 0, указывает на выбор формата этого самого Configuration Identifier. Там ничего кроме 0 не предусмотрено, поэтому, в принципе, можно этим полем пренебречь.

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

которые могут заявить, что они принадлежат к одному региону по имени, то есть один говорит другому, я Network Education, МСТшный свеч, и другой говорит, я МСТшный свеч, Network Education. Может быть такое, что у них различается конфигурация, что администратор один свеч уже, допустим, как-то проконфигурировал более новым образом, а второй еще нет. И в этой ситуации они не должны будут использовать МСТшные взаимодействия между собой. Они должны будут считать, что они находятся в разных регионах, потому что настроены они все-таки противоречиво. И поэтому есть еще одно поле, которое называется Revision Level. Это указание на то, какая версия у вас конфигурации используется. То есть каждый раз, когда вы админиете ваш свеч, вы должны этот Revision Level каким-то образом изменить. У вас была, допустим, версия конфигурации номер 17, вы говорите, окей, мы проадминили, добавили новый VLAN на наш свеч. Соответственно, мы изменяем привязки VLAN к деревьям, и мы ручками или не ручками, но каким-то образом увеличиваем Revision Level

на примерно единичку. И у нас получается, что все свечи вокруг считают, что у нас Revision Level 17, а вот на одном свече, на котором новый VLAN добавился, уже номер Revision Level 18. И, соответственно, он выпадает из общего региона, потому что действительно он настроен противоречиво с ними. Но потом вы на втором свече говорите, окей, давай на втором свече тоже добавим этот же VLAN, давай на втором свече тоже сделаем такие же привязки к VLAN, как и на вот этом новом 18 свече. И у нас вот этот вот свеч, который мы проконфигурировали, перейдет из одного региона, где все 17 свечи живут, в другой регион, где живут все 18 свечи. То есть если вы настраиваете MST, то у вас должны совпадать на всех свечах Configuration Name и Revision Level, ну, номер ревизии. И еще один момент, который должен будет проверять свеч при попытке взаимодействия с соседом по MST, это совпадение привязок VLAN. И передавать какую-то структуру вида,

у нас такой VLAN привязан к такому-то дереву, было бы абсолютно нецелесообразно, учитывая, что деревьев может быть до 64 штук. То есть как минимум 6 бит надо на номер дерева использовать, а лучше 7, потому что на самом деле есть еще дерево CIST, которое нулевое, то есть получается всего 65 деревьев. И поэтому нам 6T бит не хватит никак. То есть надо 7 бит как минимум на каждое дерево, просто на номер дерева выделить. И номер VLAN у нас еще отдельный есть, 4096 VLAN, то есть 12 бит под номер VLAN. И получается, что этих VLAN может быть 4096 штук, и каждый VLAN у нас требует, ну, как минимум указания номера дерева. То есть сколько получается? 12 бит и 7. 12 плюс 7, 19. Вот 2 в 19 степени различных вариантов мы можем предложить привязок VLAN к деревьям. Ну и такую достаточно масштабную структуру передавать, конечно,

было бы нецелесообразно в каждом сообщении, которое мы бы отправляли. Вместо того, чтобы отправлять отдельное указание, VLAN такой-то в таком дереве, VLAN другой в другом дереве, VLAN третий в третьем дереве, MST будет отправлять хэш от структуры, в которой у нас привязаны к деревьям отдельные VLAN. То есть мы отдельно на каждом свече локально формируем табличку, в которой говорим, VLAN такой-то в таком дереве, VLAN сякой в другом дереве, VLAN третий в пятом дереве. А потом мы читаем от нее хэш. И прикладываем вот этот вот самый Configuration Digest, хэш от таблички привязок VLAN к деревьям, в каждом сообщении. Если у нас привязки такие же, как у соседа, то у нас хэши эти будут совпадать. Если сосед посылает нам MST-пдушку, и у него хэш не совпадает с нашим хэшем, то мы говорим, сосед настроен с нами противоречиво. Вот как раз возникал вопрос, что такое престандарт MST и другой. Вот престандартный MST – это то, как считался этот Configuration Digest.

Да. Cisco до того, как была опубликована финальная версия стандарта, выпустила на рынок свечи, и формулу подсчета хэша предложила на тех свечах использовать одну, а в стандарт в итоге вошла другая. Поэтому те свечи, которые были сделаны по стандарту, не могли подружиться с MST-шными свечами, выпущенными Cisco до публикации, собственно, стандарта. Поэтому пришлось делать переключатель, как мы хотим на Cisco-свечах работать. По стандарту или так, чтобы оно было совместимо с теми свечами, которые старые. Дальше, соответственно, у нас есть много других полей в MST-экстеншене, и про них мы поговорим отдельно. Но в любом случае два свеча не будут читать все остальные поля заголовка MST-экстеншен, если не совпадает вот этот вот самый Configuration Identifier. Просто все 51 байты должны совпадать по битово. Ну, с одним байтом все легко, потому что он всегда 0, а вот остальные 50 могут различаться. Если на двух свечах MST Configuration Identifier

не совпадает хотя бы в одном бите, то весь MST-экстеншен не читается. Так, дальше. Если у нас есть два свеча, которые настроены между собой с точки зрения MST-противоречиво, то есть это либо сосед, который не поддерживает MST вообще, пришел к нам и посылает нам свою бпдушку, либо сосед, который поддерживает MST, но настроен с нами противоречиво, у него Configuration Identifier не совпадает с нашим, то в этом случае мы считаем, что наш свеч и сосед не принадлежат к одному региону. То есть они принадлежат типа к разным регионам. В этом случае взаимодействие с ними будет осуществляться только с помощью дерева CIST, то есть с помощью классического ванильного Spanning 3. Мы будем отправлять бпдушку, мы можем в ней указывать MST Extension или не указывать, это на самом деле на что не повлияет, потому что все равно этот Extension читать никто не будет. Если мы будем отправлять MST-шную бпдушку без экстеншена,

то в этом случае это превратится бпдушку в обычную Rapid Spanning 3. Ну и получается, да, что если у нас есть два свеча, которые находятся в разных регионах, то мы отправляем друг другу бпдушку без экстеншена, и это фактически обычная Spanning 3. Rapid Spanning 3. И по факту, если сосед настроен не так, как мы, то мы в этом случае работаем с ним в режиме симуляции Rapid Spanning 3. MST начинает прикидываться просто обычным Rapid Spanning 3. И для того, чтобы все свечи работали в пределах региона правильно, то вся информация, которую MST-шные свечи получают от внешних свечей, она складывается в дерево, которое называется AST, Internal Spanning 3. Если у нас есть сосед, и мы с этим соседом работаем в режиме Rapid Spanning 3, в режиме симуляции, то такой порт, которым мы на соседа смотрим, называется пограничным или Boundary Port.

Как мы определяем, что сосед настроен с нами не так? Либо приходит к нам бпдушка от соседа MST-шного, но он находится в другом регионе с нами, то есть мы видим, Configuration Identifier различается, либо к нам приходит бпдушка классического Spanning 3, то есть мы просто сидим, никого не трогаем, посылаем MST-шные бпдушки, а в ответ приходят RST-пшные бпдушки. Сосед не понимает, что такое бпдушка с протоколом version Identifier 0x3. Он говорит, что я знаю, что такое Rapid Spanning 3 0x2, я знаю, что такое 0x0, а что такое 0x3, я не знаю. В этом случае мы говорим, окей, мы порт объявляем пограничным, и мы начинаем с ним работать в режиме отправки бпдушек. И мы искусственно даже можем выставить тип этой самой бпдушки 0x2 или 0x0, чтобы сосед думал, что он действительно работает с обычным Rapid Spanning 3-шным соседом. Вот, дальше.

Нам нужно будет отправить свою бпдушку и получить в ответ бпдушку какую-то еще. Если мы работаем с соседом в Rapid Spanning 3 или мы работаем с соседом в MST, то мы отправляем либо agreement, либо proposal. И в этом случае мы понимаем, кто наш сосед. Либо может быть такое, что мы отправляем какую-то бпдушку свою и получаем в ответ бпдушку совсем медленного Spanning 3, то есть 802.1d 90-го года с полем версии 0.0. Ну, в этом случае мы, опять же, можем искусственно переключиться в режим совсем медленного Spanning 3, в режим совместимости. Дальше. Если у нас есть бпдушки, которые приходят на наш порт, и эти бпдушки будут разные, то есть как минимум у них будут разные порты ID, в этом случае мы тоже такой порт можем объявить как пограничный. Так. Что здесь нам будет нужно?

Нам нужно будет понять, что все свечи, которые видят наш регион, они на самом деле думают, что весь регион — это один большой свеч. Давайте попробую проиллюстрировать эту картинку. Так. То есть вот этот вот момент, да, что если у нас есть один свеч, который находится на границе с нашим регионом MST, вот регион, облачко, в нем раз свеч, два свеч, три свеч. Вот это все свечи MST-шные. MST. Они находятся в одном регионе, они знают, кто такой MST, как с ним работать, они реплицируют между собой все деревья, и есть сосед, который вот как раз boundary port, он либо Rapid Spanning 3-шный сосед, либо MST в другом регионе, это не суть важно, он присылает какие-то BPD-ушки, и в них содержится информация про какого-то внешнего рута. Возможно. Или, соответственно, он не присылает никакие BPD-ушки, но он согласен с тем, что рут где-то в другом месте. Вот мы должны будем про внешнего какого-то рута рассказывать,

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

для MST, в общем-то, не суть важно. Но получается, что у нас есть отдельная стоимость, как можно внутри вот этого самого ИСТ добраться до рута. То есть если у нас есть наши свечи, так, где у меня рисовал-ка, если у нас есть наши MST-шные свечи, вот у них есть какое-то внутреннее взаимодействие внутри дерева ИСТ, Internal Spanning 3. То есть они говорят, до рута мы можем добраться вот здесь вот, и здесь это сколько-то все-таки стоит. Раз, два, три, три линка пусть по 10 копеек, пусть по 20, пусть по 20 тысяч копеек. В общем, какая-то стоимость внутри MST-шного региона до рута определенная есть. Есть стоимость, которую мы показываем всем остальным, чтобы прикинуться, что у нас все наши MST-шные свечи, это на самом деле один большой свеч. И у нас получается два разных дерева, которые участвуют во внешнем взаимодействии с MST. Есть дерево, которое называется Common Spanning 3 или Common Internal Spanning 3.

Есть внутренняя стоимость ИСТ-шного, внутренняя ИСТ-шная стоимость, как можно добраться до рута. Поэтому у нас в наших БПДУшках, которые в MST будут отправляться, будет много разных стоимостей. То есть даже если мы говорим только про дерево, вот это вот ванильное дерево, то сейчас будет много разных вариантов, как можно добраться до рута с разными стоимостями. Не пугайтесь этого. На самом деле ничего сложного нет. Я думаю, что вы сейчас начали переживать, что я говорю много непонятных слов. Это не пугайтесь, это не непонятно. Это просто действительно много разных терминов. Начинается все с того, что у нас есть БПДУшка. То есть в этой БПДУшке вот у нас начало. Это такое классическое ванильное начало. Какой-то заголовок, в котором указывается версия, в котором указывается тип протокола, флаги и прочее. 5 байт нас сейчас не интересует. Дальше. Кто рут за вообще всю топологию Spanning 3, включая внешние свечи? CIST-рут. Это один свеч, который может находиться внутри нашего региона

или вне нашего региона. Это просто Bridge ID действительно настоящего рута. Если вы берете много-много свечей, часть из которых MST, часть из которых не MST, то каждый свеч, когда будет передавать БПДУшку, он будет говорить, я знаю, кто рут за вообще всю-всю-всю-всю-всю топологию. И вот это вот CIST-рут-аденцифайр, это как раз его Bridge ID. Этот root Bridge ID не обязан быть частью региона MST. Это может быть какой-то внешний свеч. Когда этот внешний свеч или все другие внешние свечи будут смотреть на наш регион, они вместо всего большого региона будут видеть один такой виртуальный мега-свеч. Этот виртуальный мега-свеч принимает БПДУшки с одной стороны и выплевывает их с другой стороны. Соответственно, у нас есть стоимость, как мы знаем, как добраться до рута. И эта стоимость должна быть одинаковая на вообще всех свечах внутри региона. Поле, там, где обычно у нас root-pass cost, указывает на то, сколько стоит добраться до рута за пределами региона.

То есть у нас есть, получается, стоимость внешняя, сколько стоит добраться до рута, и стоимость внутренняя, сколько стоит добраться до точки выхода, от которой можно добраться до рута. Вот External Root Path Cost – это сколько внешняя стоимость от нашего региона, от любого свеча нашего региона по внешним ванильным линкам, сколько там будет стоимость как добраться до рута. Это бывшая просто Root Path Cost. Но теперь оно превращается в External Root Path Cost, то есть по ванильным линкам, поскольку вот эта вот часть используется как раз для симуляции ванильного Spanning 3, сколько по ванильным линкам стоит добраться до рута. CIST, Regional Root ID, страшное ужасное поле – это бывший Bridge ID, Sender Bridge ID. Это кто послал эту БПДУшку? Учитывая, что вот эта вот часть, опять же, это все за ванильный Spanning 3 отвечает, то все-все-все наши свечи, которые находятся внутри региона, они должны будут делать вид, что это один большой свеч.

У них у всех должен быть одинаковый Sender Bridge ID. Но они не могут иметь одинаковый Sender Bridge ID. Поэтому они должны будут догадаться, кто из этих свечей будет иметь Bridge ID, кто из наших MST-шных свечей будет иметь такой Bridge ID, именем которого будут подписываться все остальные. Поэтому внутри региона все свечи выбирают одного, и именно его ID-шник указывается в качестве подписанта исходящих БПДУшек. Этот один будет называться словом Regional Root. Когда у нас есть много свечей внутри региона, они внутри себя, внутри МСТ выбирают одного и говорят, когда мы отправляем БПДУшки наружу, эти все БПДУшки уходят из-под одного и того же ID-шника. Это ID-шник вот этого самого оригинального Root. Ну и, наконец, CIST-порт ID. Это ничего нового, это просто каким портом мы это отправили. То есть это поле по сути своей осталось тем же самым. Еще раз, давайте пробежимся по тем полям, которые отвечают за синхронизацию ванильного Spanning 3.

Root Identifier. Это root identifier, ничего нового. Просто root за всю-всю-всю топологию Spanning 3. Это не МСТ-шный root, не региональный root, никакой другой. Это root за всю-всю-всю топологию. Дальше. Сколько стоит от МСТ-шного региона по внешним ванильным линкам добраться до этого рута? External root path cost. Ну вот, да. Все это про ванильный Spanning 3. Regional root ID. Единственный ID-шник, к которому подписываются все наши свечи. Они внутри своего региона выбирают одного и подписывают все сообщения им. И порт ID это просто каким портом этот коммутатор отправил. Может быть такое, что два свеча разных, которые в одном регионе будут сидеть, будут отправлять выпадушки из-под одного порта ID. На это автора протокола решили положить болт, потому что в итоге в priority векторе порт ID отправителя срабатывает крайне редко. Поэтому даже если вдруг в каких-то исходящих выпадушках на разных свечах этот самый порт ID будет совпадать, ничего страшного, как правило, в этом нет.

Ну и дальше уже получается, что если у нас есть вот такие вот боподушки, которые мы отправляем, то получается, что весь наш свеч, весь наш регион действительно можно от внешнего наблюдателя представить в виде одного такого большого виртуального свеча. Так. Внутри дерева сколько виланов может быть? Деревья не находятся внутри дерева, они не находятся отдельно. То есть мы создаем одно дерево и дальше сколько хотите виланов к нему, столько приделывайте. По умолчанию у вас вообще все виланы, все 4024 вилана привязаны к дереву номер 0, ну к инстанцию EST. Если вы хотите, вы можете все-все-все виланы привязать к другому дереву. Или вы можете взять и побить все виланы на четные, нечетные, привязать их к двум разным деревьям. Учитывая, что передается только хэш от этого, хэш всегда одинакового размера, и то, как вы будете привязывать виланы к деревьям, вообще никого не интересует.

Какой-то конкретный, конкретная реализация может иметь свои заморочки. Вот, например, те же самые циски, они в отличие от стандарта не допускают создания 64 разных пользовательских деревьев. Они говорят, вот 16 деревьев должно быть достаточно всем. И если вдруг вам нужно будет включить циску в МСТ-шный регион, в котором уже, допустим, 17 деревьев создано, все, вы попали, вы не можете этого сделать. Циска просто не поддерживает создание больше, чем 16 деревьев. Но в пределах какого-то разумного подхода, пожалуйста, сколько хотите виланов, столько привязывайте. Если в каком-то вилане будет петля, механизм будет тот же, что и у СТП. В вилане петля может быть сколько угодно. Главное, чтобы петли не было в дереве. Если петля в дереве есть, то МСТ внутри этого дерева посчитает, какие порты надо включить, какие выключить. Дальше все виланы, которые этот порт будут использовать, они будут себя вести в соответствии с ролью, назначенной этим деревом.

Вместо вилана ID будет использоваться хэш. Хэш, ну, не совсем так. Вместо вилана ID будет использоваться идентификатор дерева. А при репликации дерева с определенным идентификатором будет использоваться хэш. То есть, когда мы отправляем бпдушку, мы говорим, мы настроены вот так. Наши виланы вот такие, привязаны к деревьям, они вот так. Только мы это не передаем в виде указания. Вилан такой-то, привязан к дереву такому-то. А мы передаем хэш, где указываем цифровую подпись того, как у нас, собственно говоря, деревья созданы и какие виланы к ним привязаны. Если у соседа все так же, то хэш, посчитанный по тому же самому алгоритму, у него будет совпадать. Если у соседа настроено что-то не так, то у него хэш совпадать не будет. Мы посылаем бпдушку, и хэш не совпадает у приходящей к нам бпдушке или исходящей от нас бпдушке с тем хэшем, который должен получиться в итоге. И в этой ситуации просто весь вот этот МСТ-хвост читаться не будет.

Если он читается, значит по определению деревьев создан точно так же, и виланы к ним привязаны точно так же. Так, по поводу синхронизации вот этого самого ванильного блока. Если мы говорим про то, что у нас есть МСТ-шный регион, и в этом МСТ-шном регионе у нас все свечи знают, что они настроены непротиворечиво. У них совпал configuration identifier, совпал domain name, совпал номер ревизии, совпал тот самый хэш привязок деревьев к виланам. Дальше у нас начинается репликация дерева IST, Internal Sparning Tree. Это тот самый дерево, которое рассказывает про то, как мы знаем внешний мир, но ИСТ-это вот только часть этого дерева, которое внутри региона используется. Рутом в этом дереве будут являться внутренние свечи, тот самый, именем которого будут подписываться все исходящие бпдушки.

Соответственно, это будет использоваться уже не вот этот вот блок, не вот этот вот priority vector, который за дерево CIST, за дерево Common and Internal Sparning Tree будет передавать информацию. А вот этот вот блок. И в этом блоке у нас отдельные стоимости начинают считаться, как устроен дерево ИСТ внутри нашего региона. Потому что CIST это дерево, которое указывает, как мы ведем себя со внешними какими-то свечами. И в дереве CIST мы всеми свечами МСТшными прикидываемся одним таким мегавиртуальным свечом. А внутри между собой нам все-таки надо разобраться, как мы связываемся друг с другом, где у нас какие петли возможны в этом самом дереве CIST. И соответственно мы отдельного рута выбираем. У нас есть отдельный региональный рут, так называемый. Это вот тот самый, вот этот вот региональный рут. У нас есть отдельная стоимость, как добраться внутри нашего IST до регионального рута.

Internal root path cost. Это как внутри нашего региона добраться до рута. Сколько денег, копеек стоит. Кто мы? Bridge Identifier и Remaining Host. У обычного медленного или быстрого Sparring 3 не было концепции, что BPDU ограничены как-то в своей области распространения. То есть было указание на MaxH и было указание, что MessageH не должно превышать этот самый MaxH. Но в MST специально сделали дополнительные ограничения. Каждый раз, когда BPDU уходит от рута или, скажем, от свеча, который находится ближе к руту, в сторону свеча, который находится дальше от рута, в MST Extension мы указываем количество оставшихся прыжков. И отправитель, рут, может задавать, сколько именно прыжков эта BPDU может пройти до того, как она истечет. По умолчанию там 20 прыжков между свечами будет.

То есть если вы указываете на руте, что диаметр нашей сети никогда не превышает 20 свечей, то вы отправляете BPDU с рута на соседа, указываете там 20. Сосед пересылает эту BPDU дальше, указывает 19, потом дальше 18 и так далее. Если у вас в сети больше свечей, чем 20, ну не больше свечей, а диаметр сети больше, чем 20, то, соответственно, MST у вас может работать некорректно. Возможно, вам придется как раз отредактировать этот Remaining Cops, если у вас это поддерживается. Но мой совет, что если у вас используется больше 20 прыжков между свечами в каком-то месте сети, то имеет смысл пересмотреть какой-то дизайн сети. То есть либо MST оттуда убрать, либо как-то более правильным образом пересвязать между собой свечи. Вот. Когда мы отправляем MST-шную BPDU, сейчас сделаем чай. Когда мы отправляем MST-шную BPDU, если сосед понимает, что такое MST, ну это ладно, если сосед не понимает, что такое MST, он говорит, я вот это все не читаю.

И он использует только вот эту вот часть. И в этом случае с внешними соседями мы передаем только один priority vector, мы говорим, мы понимаем, что ты boundary port, мы тебе отправляем BPDU, мы указываем тебе, кто внешний root, сколько стоит добраться до root, кто мы, такой виртуальный наш ID-шник любого свеча на нашей топологии, и, соответственно, вот каким порт ID мы это послали, и таймеры. Если мы знаем, что сосед с нами настроен непротиворечиво, то он будет читать MST-экстеншн, и в этой ситуации мы говорим, да, мы реплицируем с соседом глобального root, никто не спорит, но нам внутри нашего дерева MST-шного глобальный root не сильно интересен. Да, мы реплицируем с соседом external root-path-cost, но, опять же, внутри дерева MST-экстеншн, это нам не сильно интересно, не поможет нам понять, как устроена наша внутренняя связь внутри региона. Поэтому то, что раньше у нас передавался в обычном классическом Spanning-3, priority vector, который я напомню, как он выглядел, сначала root-bridge-id, потом root-path-cost,

это классический priority vector, который передается в обычных самых обычных воподушках, потом sender-bridge-id и, соответственно, sender-port-id. Соответственно, priority vector внутри дерева IST немножко модифицируется. Он расположен не единым блоком в 22 байта, а он расположен вот как. Кто root внутри дерева? Root-bridge-id. Вот эта вот штука, это первая часть priority-вектора. Дальше. Root-path-cost. Вот эта вот штука. RPC. Вот эта вот штука. Bridge identifier. Когда мы посылаем боподушку, мы говорим, кто мы. И мы понимаем, что мы не можем уже отправлять такую боподушку, в которой кто мы будет написано вот здесь. Потому что кто мы, здесь уже зафиксировано поле вот это вот под другое. Это поле уже указывает на root-bridge-id внешних каких-то боподушек. И мы это, соответственно, реплицируем для того, чтобы выбрать, кто именно будет оригинальным рутом.

Поэтому у нас появляется отдельное поле. Bridge identifier. Это sender-bridge-id. И, соответственно, sender-port-id. Вот оно вот это вот. Sender-port-id. Получается, что в одной и той же боподушке у нас есть два разных priority-вектора. Один priority-вектор за дерево CIST, которое вообще про всех. И другое дерево IST, в котором у нас bridge-id другой, и в котором у нас root тоже другой. И root-pass-cost тоже другой. Поэтому, да, получается, что у нас вот эта вот часть для всех, а вот эта часть только для тех, кто понимает. Так, давайте посмотрим теперь, как все это дело немножко визуализируется. Резюмирую. То, что у нас получилось на предыдущих слайдах. У нас есть дерево IST, Internal Spanning Tree, где свечи обмениваются между собой. Информация про то, как устроено внутри легиона вот это вот общее дерево, которое заведомо всегда есть. У нас есть дерево CIST, Common and Internal Spanning Tree.

Это дерево, включающее в себя ванильных соседей. Ну и, соответственно, есть отдельное дерево CIST, которое исключает IST. Ну, да, по буквам прямо видно, да, что здесь у нас CIST, здесь нет Internal Spanning Tree. Поэтому свечи, которые работают по CIST, они не видят, что происходит внутри дерева IST. Это то, что происходит снаружи. Мы, когда отправляем какие-то БПДушки на МСТ на свечах наружу, мы не показываем, что происходит внутри нашего региона. Поэтому дерево CIST – это вот все, что видят окружающие соседи. И соседи видят вместо одного большого региона просто один виртуальный свеч. То есть мы можем сказать, что у нас весь регион IST, весь регион Spanning Tree, МСТ-шный, схлопывается в один вот такой вот свеч. Вот так выглядит дерево IST. Вот оно. То есть у нас четыре свеча. Понимают, как они связаны друг с другом. Они видят, что они настроены неопротиворечиво. Они запускают вот здесь вот репликацию МСТ-шных деревьев.

И среди прочих они реплицируют дерево IST – Internal Spanning Tree. Дальше они говорят, что у нас есть CST-шные соседи, с которыми мы работаем через ванильный Spanning Tree. Соответственно, вот здесь у нас бегает ванильный Spanning Tree. Здесь тоже бегает ванильный Spanning Tree. И для того, чтобы все вот эти вот четыре свеча схлопнулись в один виртуальный свеч для всех остальных, нам нужно, чтобы информация из CST передавалась в IST. Поэтому если мы говорим, что у нас есть дерево и вот это вот, и вот это вот, и вот это вот, соответственно, это все будет называться дерево CIST. То есть и Common Spanning Tree, и ванильный Spanning Tree, и Internal Spanning Tree – это информация о том, как мы участвуем во внешней топологии с точки зрения МСТ. Зачем это нужно? А затем, чтобы у нас правильно выбирались руты. Соответственно, если у нас в дерево CIST есть где-то рут, ну, например, он может быть снаружи региона, вот этот вот свеч будет рутом,

то нам нужно, чтобы все свечи понимали, как до этого рута можно будет добраться. Соответственно, у нас весь наш регион МСТ схлопывается в один большой мега-свеч. Это у нас правильный рут. И BPD-ушки, которые от рута приходят на наши МСТ-шные свечи, они, соответственно, должны передаваться дальше, как будто бы они прошли всего лишь один прыжок. То есть мы должны МСТ-шную единичку увеличить, мы должны дальше что там сделать? Мы должны root path cost увеличить вот ровно на стоимость интерфейса, которого мы на соседа смотрим. Ну и в такой ситуации получается, что, да, что если у нас вот этот вот линк стоил 10 копеек, то мы дальше передаем указание, сколько стоит добраться до рута, и мы отправляем BPD-ушку, в которой указываем, что до рута стоит добраться 10 копеек. Ну и дальше все остальные свечи должны думать, что это просто обычный свеч. Все BPD-ушки, которые будут отправляться нашими свечами, они будут отправляться из-под одного и того же ID-шника, который будет выбираться на наших свечах.

Это будет ID-шник так называемого регионального рута. То есть мы говорим, что вот этот вот свеч может быть региональным рутом, и как следствие он, этот самый региональный рут, будет его именно ID-шник стоять в качестве Sender Bridge ID во всех исходящих ванильных сообщениях. Ну и у нас получается отдельно внутри вот этого дерева надо реплицировать этого рута и сколько стоит до него добраться. Это у нас будет CIST-root и External-Root Path Cost. External-Root Path Cost. И отдельно мы реплицируем состояние, кто у нас региональный рут и Internal-Root Path Cost, сколько стоит добраться до регионального рута. Так, дальше. Как у нас будет выбираться рут глобальный? По обычным правилам Spanning 3. То есть передается по подушке. Мы говорим, что мы знаем рута такого-то. Если мы получаем BPD-ушку, в которой root bridge ID,

вот глобальный рут, указан с ID-шником меньшим, чем знали мы, то, соответственно, мы немедленно перековываемся и начинаем считать новым глобал рутом другого кого-то. Ну и получается, что за все-все-все свечи, которые у нас есть в топологии, так или иначе глобальный рут будет выбираться предсказуемым образом. Тот свеч, у которого будет самый маленький приоритет, самый маленький MAC-адрес, в итоге станет глобальным рутом. Он может быть внутри региона или вне региона, это на самом деле неважно. Но внутри региона МСТ-шного у нас дополнительно выбирается тот самый региональный рут, и он выбирается по следующему правилу. Если у нас какой-то самый-самый-самый вкусный свеч, у которого самый маленький приоритет, самый маленький bridge ID, то есть тот, кто станет глобальным рутом, CIS-т root, если он находится внутри нашего региона, допустим, вот этот вот свеч станет глобальным рутом, то он же станет и региональным рутом. Ну, чтобы не получилось так, чтобы у нас внутри региона, да, получился один свеч root такой, другой свеч root другой.

Вот у нас просто кто внутри региона самый крутой, тот и будет региональным рутом, если рут, глобальный рут, находится внутри региона. а если у нас есть внешний root например вот этот вот труд то региональным рутом будет тот кто ближе всего круту то есть это будет тот самый коммутатор внутри нашего региона у которого root порт будет boundary порт то есть на вот этом вот свече мы получаем по подушке напрямую от рута и соответственно мы говорим самый выгодный способ добраться дурта это вот этот вот порт который мы смотрим на рута это boundary порт соответственно root порт вот мы говорим вот этот вот будет региональный рут почему не получится так чтобы подушки пройдут через от первого свеча до 2 оттуда дальше на 7 почему 7 не получит роль регионального рута потому что на самом деле несмотря на то что приходить то бы подушки будут на этом порту на 7 свеч но здесь надо будет вспомнить что наши все свечи в топологии мастер

не они должны прикидываться одним мега свечом поэтому у этого мега свеча вот этот порт будет рутовым а у вот этот вот порт у него должен быть alternate порт то есть он должен быть заблокирован потому что весь региональный весь регион мастер что у нас превращается в один виртуальный свеч поэтому в итоге когда свечи действительно будут между собой реплицировать свое состояние они должны будут сказать что вот здесь вот мы находимся ближе всего круту поэтому этот порт будет рутовый а вот этот вот порт должен стать alternate порт потому что вот так вот выглядит наш мега виртуальный свеч за весь регион до расчет стоимости в этом случае будет идти по обычным правилам которые у нас есть то есть если мы говорим про вот это вот самый root порт который у нас есть ту самый-самый выгодный способ добраться до рута за пределами нашего амст то есть по обычным ванильным правилам мы здесь будем рассчитывать стоимость будет здесь будет приходить стоимость не знаю 10 копеек ну здесь

0 потому что мы напрямую oder рта 100 смотрим здесь будет приходить стоимость там 10 копеек ну и мы говорим здесь было подушка приходит за 0 копеек плюс допустим там двадцать тысяч стоимость стоимость вот этого линка здесь бы подушка приходит 10 копеек плюс стоимость 20000 вот этого линка то есть здесь у нас получается за 20 тысяч мы знаем как добраться рута здесь за 20 тысяч 10 копеек можно добраться рута то есть самый выгодный способ добраться до рута через вот этот вот линк вот мы соответственно объявляем этот порт рутовым этот порт говорим alternate порт даже несмотря на то что рус порт и alternate порт будут находиться физически на разных железках но на самом деле здесь они символизируют собой одну виртуальную железку которая схлопывается до вы которую схлопывается весь регион мст и после того как мы определили что у нас есть способ добраться дурота получше способ добраться дурота похоже вот мы самые самые самые вкусный способ добраться до рута внешнего объявляем

root портом root портом это как точка выхода из нашего региона мст до рута и там тот коммутатор у которого будет такая самая вкусная точка выхода мы объявляем региональным рутом то есть региональный рут он по определению ближе всего круту вот когда у нас идет репликация репликация свечей мст шных они будут между собой обмениваться бпдушками и они указывают соответственно кто глобальный рут это внешний сия стишный рут сколько стоит до него добраться external root паскост кто региональный рут внутри нашего региона internal root паскост сколько стоит добраться до регионального рута внутри региона sender bridge один на самом деле десернете брича иди десернете портой дей или 7 портой эти вот так вот выглядит проверить и вектор по которым ибо подушке будут сравниваться между собой помните у нас в

классическом спамик 3 был коротенький коротенький вектор root bridge иди рут паскост sender bridge иди sender портой дей и наконец у нас ресивен портой дей было то есть всего пять элементов было по которым бы подушки сравнивались между собой возле семь у нас добавляется еще один рут и добавляется еще одна стоимость до него и вот этот вот вектор вы конечно можете не запоминать но когда у вас будут в реальной жизни например возникает вопроса почему один свитч там выбрал роль порта вот такую то почему другой свитч выбрал там региональным рутом вот того то вы как раз можете сравнить бпдушки которые эти свечи отправляют и принимают друг другу по вот этому вот проверить и вектор этот механизм такое серебряное поле как можно быстро понять при репликации дерева сея ст и кто будет не сигнал этот портом в каждом конкретном дереве кто будет рут партом кто будет каким-то альтертейт портом репликация рута происходит по

общим правилам рута иди репликация регионального рута тоже происходит по общим правилам если у нас есть какой-то свитч который находится внутри нашего региона и у него самый маленький бритш иди за всю всю всю всю всю всю топология включая внешние свечи то он станет соответственно рассылать себя сначала в качестве рута он каждый свитч начинается того что он тебя рассылает качестве рута глобального и про себя же говорит я мст-шный свитч я нахожусь в одном регионе с собой и я указываю себя же в качестве регионального рута и вот эта информация будет разбегаться по всем у нас страшным свитч ам и рано или поздно все свечи внутри региона будут видеть что у нас есть мстш на региональный рут и у нас есть какой-то вот это вот внешний рута иди и они совпадают и как следствие они понимают что если у нас рута иди региональный рута иди совпадают значит нам не надо выбирать рут порты которые смотрят наружу мы просто говорим что вот мы сами мега мега рут мега рутовый виртуальная свечу если же к нам приходят какие-то боподушки от соседей давайте сотру со слайда стирая все слайда например

у нас вот этот вот товарищ рут он посылает в подушку ведь я знаю когда братцы доруда за 0 копеек здесь он горит я знаю когда братцы сварку то за 10-ка за лекон за 0 копеек 2 свечи говорит я знаю как добраться до рута за 10 копеек что может отправить 8 свечи он может сказать я знаю когда братцы дорута 1111 это его проверить и bridge айди external root path cost сколько я знаю как можно добраться до рота ну допустим вот здесь вот нас 20000 этот линк стоит он говорит external root path cost эта стоимость внешняя до 20000 дальше региональный рут кто с точки зрения 8 свеча будет региональным рутом но раз он получает самый выгодный выпадушка оттуда он про себя и будет рассказывать что я буду региональным рутом 8 8 8 8 интернет паскос сколько стоит добраться до регионального рута нисколько не стоит добраться он сам региональный рут сендер бриджа и 8 8 8 8 сендер портой ди ну каким-то он портом это

там послал и receiving портой ди но у нас отправляются в подружке сейчас не сильно интересно почему например 7 свеч в этом случае не станет региональным рутом потому что он будет говорить я знаю кто у нас рут я вижу чтобы подушки приходит самые вкусные от соседа 2 в которой указывается что root айди оригинальный глобальный рут будет соответственно 1 но экстеллен экстернал root path cost получается 20 тысяч 10 копеек ибо подушка который будет приходить от 8 свеча она будет заруливать эту бы подушку вот то что 7 свеч будет говорить я знаю как добраться до рута за за 20 тысяч копеек через вот так вот и я знаю как добраться за 20 тысяч 10 копеек вот так вот соответственно вот этот вот способ добраться дарута становится невкусный вот обратите внимание что способ добраться до внешнего рута который находится за пределами местод jon а региона не включает в себя стоимость вот этого линка потому что этот

линк внутренней и он здесь не учитывается при репликации external root pass cost считается только внешняя стоимость сколько стоит добраться по внешним линкам и по внешним линкам 7 свит говорит я знаю как добраться до вот этого первого рота самым вкусным образом через восьмой визуально но может быть одинаково выглядит а по факту внешних линков здесь вот только один а здесь получается 2 и это получается будет влиять на правильный выбор рота так дальше ну региональный рут туда начинают все с того что считают себя региональным рутом и даже если 7 скажет я пытаюсь стать региональным рутом очень быстро его вот это вот бы подушка входящая переубедит и 7 свеч начнет рассказывать что я знаю кто рут это будет первый свеч я знаю сколько стоит добраться до экстерна до рута внешнего external root pass cost самое выгодное получается 20000 через восьмого я 7 свит не совпадаю с региональным рутом поэтому я говорю я знаю как добраться до внутреннего рота 8 8

8 8 8 интернет паскост я говорю сколько стоит добраться до внутреннего вот этого самого регионального рута за там 20 тысяч копеек могу добраться это вот этот вот внутренний и стэшный линк сендер брича идеи семерки каким портом это отправляется ну каким-то ресивен портой дик какой-то там тоже будет то есть вот эти бы подушки может отправить 8 свеч вот эти бы подушки может отправить 7 свеч 20 тысяч 7 смич свеч внешней стоимости берет от 8 свеча как он может добраться до внешнего рота и root портом соответственно будет порт смотрящий на 8 вот этот алгоритм он вам позволит легко определить ну как легко при наличии некоторой практике какой порт будет объявлен в каком дереве ну не в каком дереве в какой порт в дереве си ст будет объявлен с какой ролью так дальше так это чего нас мультик рисуется до мультик

то есть вот первый свеч выбирается ротом 8 свеч выбирается региональным ротом дальше если хотите можете шпаргалку сделать да то есть как высчитывается проверить и вектор все есть и сначала кто root если мы работаем с какими-то внешними свечами в классическом спаринг 3 то соответственно бот root bridge id вот здесь вот она была мы как раз и будем реплицировать сесть и root the fire поле в мст называется но это бывшая классическая поле root bridge id дальше external root path cost второй пункт как мы сравниваем бпдушки если опять же к нам приходит просто обычная спальнектричная бпдушка то то поле который там вот на втором месте стоит root path cost это тоже самое поле которое называется external root path cost в мст если мы получаем БПД у жку от ССЭСТ самого соседа то мы не

прибавляем ничего в external root path cost прибавляется стоимость интерфейса к нему только если мы получаем это бы подушка от внешнего соседа только на баундере порту баундере дальше кто региональный рут если мы получаем классическую подушку то это будет центр бритшазе но если мы отправляем по подушку то мы указываем соответственно что мы с точки зрения всего остального мира один мега свеч и айдишник этого мега свеча будет айдишник регионального рута дальше внутренняя стоимость сколько стоит добраться до регионального рута если мы отправляем бы подушку какую-то наружу то мы это вообще не указываем потому что интернет подкос раз используется в расширении маста extension обычные классические соседи они вот это вот все вообще не читают они его не умеют читать и даже если вдруг они смогут прочитать они читать не будут потому что это будет означать что это свечи другом регионе но если мы получаем баба дужки от внешнего какого-то

соседа то мы говорим что интерн larred pathcost в таких ба пушек будет нулем ну или если мы получаем по подушку от внутреннего соседа на не boundary порт у то соответственно мы к интерн pap Mask прибавляем стоимость интерфейса который мы такой вот подушку получили для того чтобы правильно посчитать стоимость сколько стоит добраться до внутреннего рута через внутреннего соседа к нам сосед приходит говорит я знаю как добраться за 10 копеек мы говорим окей ты наш внутренний сосед ты рассказываешь как добраться до внутреннего рота мы к тому что ты рассказываешь прибавляем стоимость интерфейса который мы это получили получаем стоимость что через тебя можно добраться до внутреннего рота за там 20 копеек дальше bridge identifier это то кто соответственно мы или то кто нам отправил бы подушку опять же вот этот вот про эти вектор он полезен ситуации когда мы сравниваем входящие по подушке и bridge identifier будет нужен если у нас сосед мст-шный сравнить кто это

отправил если у нас сосед классический тот который называется да и степишь не просто обычную подушку посылает то это sender bridge ади поле и если вдруг мы говорим что нам надо как-то сравнить для баба дужки которые к нам приходят вот мы их можем сравнить либо по плечи динсифир если они действительно мст-шные либо если они классические спаринг 3 что то по sender bridge адиных сравниваем повод вот этому вот полю вот она вот здесь вот было ну и дальше sender портой дейси вин портой дейм алгоритм состоит из семи пунктов и опять же да он дает нам гарантированную возможность определить какие бы подушки лучше какие хуже и на основании бы подушек лучше хуже мы можем принять решение что в дереве кто-то находится ближе круто кто-то находится дальше круто вот единственное что мы здесь будем выбирать двух ротов но опять же алгоритм устроен таким образом что это не влияет на скажем сложность его просто опять же

сравниваем просто по вот этим вот многим байтам вот такой вот большой большой поле сравниваемый у кого поле меньше числа вот он и прав вот вот это вот самый проверить их Tahir vector если вы берете сравнивать между собой 2 по по дужке то вы можете взять сравнить 2 по подушки рядышком просто приложите и по вот этим пунктом пройтись пункт номер один глобальный рут пункт номер два сколько стоит добраться до внешнего рута глобального пункт номер три региональный рут пункт номер четыре сколько стоит добраться до оригинального рута пункт номер пять кто отправил пункт номер пять чем отправил пункт номер 6 пункт номер семь чем получили все то есть также как мы раньше делали у нас было 4 пункта 5 пунктов root bridge id root path cost sender bridge id sender порт айди и соответственно receiving порт айди в классическом спарнинг 3 у нас было receiving порт айди в классическом спарнинг 3

у нас было пять пунктов 1 2 3 4 5 и когда мы должны были сравнить между собой две подружки мы говорили вот пробегаемся по этим пунктам в классическом спарнинг 3 пробегаем кто заявляет что знает лучшего рута если знают две одинаковые бодушки про одного и того же рута кто знает рута лучше вкуснее root паскост если два соседа заявляют друг другу что рута то они одного и того же знают ну тогда кто лучше отправляет бабушку за счет меньшего sender bridge id если это один и тот же свитч отправляет с одним там сендер брича иди то каким портом с каким меньшим и дешником порта он отправляет от бабушку и в экстремально редких ситуациях была нужна еще последняя пятая итерация это каким портом мы это получили если мы одну и ту же бабушку за двое ную получили на 2 разных портах своих то есть если одна и та же бабушка приходила на одном и там же нашем порту просто разнесенного времени мы говорили что это просто сосед отправил одну и ту же бабушка дважды и ну то есть это нормально что бабушка

отправляется периодическиDoSneva и снова до investigator у нас есть вал Merkel который говорит отправляем бы подушки часто если мы на 2 разных портах получили бы подушки то это могут быть разной бабушки И мы их можем сравнить между собой. Здесь то же самое. Если мы на разных портах принимаем БПДУшки, то мы сравниваем эти БПДУшки по вот этим вот семи признакам. Первое, кто рут внешний. Второе, сколько стоит добраться до внешнего рута. Третье, кто региональный рут. Четвертое, сколько стоит добраться до регионального рута. Пятое, кто отправил. Шестое, чем отправил. Седьмое, чем получили. И после того, как вы получаете эту серебряную пулю, вы всегда можете сказать, какая БПДУшка супер, какая инферер. И на основании этого супер и инферер вы можете сказать, вы ближе к руту или дальше. Если вы отправляете самую выгодную ППДУшку в сегменте, вы ближе к руту. Если вы ближе к руту, вы отправляете самую выгодную ППДУшку в сегменте. Все. Так.

Дальше. Про инстанции. У нас есть регион. В этом регионе свечи между собой реплицируют состояние разных деревьев. Мы говорили, что деревьев может быть несколько. Мы говорили, что деревьев по стандарту предусмотрено до 64 штук. Точнее, даже 65, если учитывать дефолтное дерево с инстансом номер 0. Но мы говорили про то, что для работы со внешним классическим Spaniac 3 используется инстанс номер 0. И по умолчанию все VLAN привязаны именно к инстансу номер 0. Однако вы можете сделать кастомные деревья. И, как правило, MST заводит именно ради этого. То есть не ради того, чтобы подолбаться с выборами нескольких разных региональных рутов. Его заводят для того, чтобы сделать разные деревья. И сказать, что в разных деревьях мы выбираем разные руты. И в этих деревьях блокируются разные порты. И у нас получается, что можно, допустим, в классической ситуации,

когда у нас есть два distribution switch'а и есть access switch'а. У нас есть два порта от access'а до distribution'а. С looped design'ом у нас здесь какой-нибудь, допустим, user channel' будет. Получается, что наш access switch говорит, часть трафика я хочу посылать направо, часть трафика налево. И для того, чтобы это было, мы говорим, что у нас есть дерево, в котором мы вот так вот посылаем трафик. И есть другое дерево, в котором мы вот так посылаем трафик. Для того, чтобы это сделать, нам нужно в одном дереве сделать рутом левый switch. И мы в этом случае трафик до него будем посылать, а второй заблокируем. А в другом дереве мы скажем, что рутом у нас будет другой switch, и трафик в другом дереве будет ходить через другой порт, а первый будет, соответственно, заблокирован. Так же, как и в PVST, мы делали разные деревья за разные виланы. Но только там приходилось делать вот столько же деревьев, сколько виланов, и это было дорого с точки зрения вычислительных ресурсов. Просто по накладным расходам получалось неразумно, если у вас много виланов. В MST вы можете ровно то же самое сделать, но сказать,

что у нас есть два разных линка, два разных варианта, куда можно посылать трафик. Нет смысла, по большому счету, городить огород и делать так, чтобы у нас трафик посылался прямо совсем независимо во всех разных виланах. Намного проще будет сделать так, что у нас будет просто два дерева. Одно говорит, посылаем направо, а другое говорит, посылаем налево в каждой петле. И вы отправляете трафик согласно тому, что в этом дереве у вас получается. Вот. Так что мы будем заводить MST-шные инстанции, мы будем привязывать к ним виланы, и у нас будет передаваться priority-вектор каждого отдельного инстанца. И там будет использоваться самая обычная логика, такая же, как в RSTP. То есть у нас будут выбираться root, будут сравниваться между собой priority-вектора в каждом отдельном дереве. То есть будут приходить BPD-ушки. Там в них, вот в этом последнем поле MST-конфигурейшн-месседжес, будет рассказываться про каждый конкретный инстанц,

информация, какой priority-вектор используется. В каждом инстанце мы передаем указания, кто у нас root. В этом инстанце региональный root – это про то, кто root в этом инстанце. Там используется 8 байт, и, соответственно, у нас эти 8 байт включают в себя, естественно, и MAC-адрес свеча, который у нас используется, и некий приоритет регионального root 4-битовый и инстанц, идентификатор МСТ-инстанца. Что это такое? Там используется та же самая схема Extended System ID, которая использовалась, например, в PVST, где у нас BridgeID получал 4 бита, соответственно, приоритета, дальше 12 бит номер инстанца и 48 бит MAC-адреса. И вот это вот все считалось одним большим монолитным BridgeID.

Соответственно, вот BridgeID у нас у каждого свеча будет, и про регионального root мы будем знать, какой у него BridgeID, какой у него вот original root ID. Дальше указывается, сколько до этого root стоит добраться в пределах инстанца. Обычный root-паскост. Ну, он называется internal root-паскост, но он по определению internal, потому что все кастомерские инстанцы мы наружу не показываем вообще никак. Внутри региона у нас свечи знают, что такое инстанцы. Снаружи региона у нас свечи не знают, что такое инстанцы, они работают в режиме построения одного единственного дерева Common Spanning Tree. Вот. Ну, internal root-паскост, да, оно же просто root-паскост. MSTI BridgeIdentifier Priority. Здесь тонкий нюанс. Заключается в том, что если мы получаем BPD-ушку, и в этой BPD-ушке у нас указано, кто ее послал. BridgeIdentifier. В этом BridgeIdentifier у нас есть приоритет в дереве CIST 4 бита.

У нас есть указание на 12 бит номер... Простите, номер инстанца в... Как называется-то? Нулевой номер инстанца. И у нас есть 48-битовый MAC-адрес. То есть вот в этом поле BridgeIdentifier, в заголовке MST Extension, у нас уже есть MAC. Поэтому, когда к нам приходит BPD-ушка, и в ней рассказывается про какие-то конкретные инстанцы, эта BPD-ушка, она приходит всего одна. Просто в ней много разных priority-векторов. Есть priority-вектор за дерево CIST, и есть priority-вектор за дерево MST. За каждое из деревьев MST. То есть если у нас там 10 деревьев есть, за каждое из 10 деревьев приходит один вектор. И BPD-ушка-то в любом случае приходит одна. Поэтому, когда BPD-ушка приходит, нам нет смысла рассказывать, что в одном дереве эту BPD-ушку послал Вася, в другом дереве эту BPD-ушку послал Вася, в третьем Вася... Ну, Вася, да.

Не тот Вася, который у нас. Какой-то другой Вася. То есть у нас одну и ту же BPD-ушку посылает один и тот же свитч, и нет смысла его ID-шник повторять много раз. От этого ID-шника есть смысл повторять приоритет. И поэтому посылается в MST Configuration сообщение Bridge Identifier Priority. Какой приоритет был у отправителя этой BPD-ушки в дереве? Потому что в ситуации, когда у нас есть два internal MST-шных свитча, которые рассказывают нам, как можно добраться до некоторого внутреннего свитча в некотором инстанте, мы должны будем сказать, что да, мы видим, что слева приходит BPD-ушка повкуснее, справа менее вкусная. И в ситуации, когда нам два соседа будут рассказывать про то, что они знают одинаково регионального рута за одинаковое количество копеечек, дальше нам надо будет сказать, кто-то из них отправляет BPD-ушку лучше, потому что у кого-то из них ID-шник меньше. Вот MAC-адрес мы в любом случае сможем восстановить из другого поля BPD-ушки, а вот приоритет мы берем как раз 1-байтовый,

точнее даже 4-битовый. Там поле-то 1-байтовое, но из 8-бит мы задействуем только 4. И мы берем эти самые 4 бита, которые приходят в Bridge Identifier Priority, складываем с номером инстанца, складываем с MAC-адресом, который мы берем из Bridge Identifier, и у нас получается Bridge ID отправителя в каждом конкретном дереве. Ну и, соответственно, Port Identifier Priority, опять же, та же самая история, у нас есть уже CIST-порт ID, который состоит из двух частей, из левой и правой части. Левая часть у нас указывает на Port Priority, правая часть указывает на номер порта. Вот номер порта, отправившего BPD-ушку, он в любом случае не изменится. То есть это одна и та же BPD-ушка, она всегда отправляется одним портом. Нельзя сказать, что мы в одном дереве отправили эту BPD-ушку одним портом, а в другом дереве другим портом. Поэтому номер порта в любом случае

заимствуется из второй части Port ID из дерева CIST. А вот левая часть, 4 бита, берется уже в каждом дереве своя. И отправитель, когда посылает BPD-ушку, он говорит, я в таком дереве имею такой приоритет, в таком порту, а в другом дереве я имею другой приоритет над каком-то другом порту. Ну или на том же самом. Ну и, наконец, MST-i remaining hops. Мы можем указать, сколько прыжков такая BPD-ушка имеет право пройти. Информация из этой BPD-ушки имеет право пройти от рута. Вот. Так что получается, что у нас есть деревья. Мы их можем создавать. И в каждом дереве у нас priority-вектор получается вот такой вот. Региональный рут, internal root path cost, sender bridge ID, состоящий из bridge identifier priority плюс кусочка bridge identifier вот здесь. И port identifier priority, состоящий из кусочка вот тут вот

и, соответственно, кусочка вот здесь вот. таймеры, маки, порты и все остальное наследуются, опять же, от оригинального дерева AST. То есть нет смысла говорить, что у нас в одном дереве используются одни таймеры, а в другом дереве используются другие таймеры. BPD-ушка в любом случае будет идти одна всегда. Поэтому, если в PVST, может быть, и имело смысл сказать, что в таком дереве мы используем такие таймеры, в другом дереве мы используем другие таймеры, хотя делать этого не надо, но это могло глобально иметь смысл, потому что мы за каждое дерево, за каждое VLAN отправляли отдельные BPD-ушки. Но в MST мы отправляем одну BPD-ушку за все деревья сразу. И она отправляется согласно одним и тем же таймерам. Поэтому таймеры мы проставляем один раз, и дальше BPD-ушка отправляется именно просто по обычным классическим таймерам, которые указываются в оригинальном начале BPD-ушки. Так, если мы говорим, что мы хотим настроить MST на циско-свечах,

то настраивается это немножко по-хитрому. Если PVST мы настраивали просто в глобальном конфиге, мы говорили, у нас есть настройки про вообще глобальное поведение свеча, немножко настроек по отношению к конкретному дереву, мы указывали там спанинг 3, VLAN, такое-то, чего-нибудь там, то MST настраивается в своем субконтексте. И команда, которая переводит вас в этот субконтекст, имеет свои некоторые особенности. Для того, чтобы перейти в субконтекст настройки MST, вы должны будете выполнить команду spaning3, MST, и дальше configuration. Когда вы это делаете, у вас спанинг 3, не спанинг 3, у вас свитч переходит в контекст конфигурации спанинг 3, и он показывает config.mst. Вот в этом конфиге MST вы можете настраивать поведение MST, и вы можете вводить в ваш свитч какие-то режимы конфигурации,

но они применяются не немедленно. То есть, так же, как в случае, например, с редактированием базы VLAN, они применяются только тогда, когда вы выходите из контекста редактирования MST. в отличие от базы VLAN, вы можете выйти из режима редактирования конфига MST, не сохранив изменения. То есть, вы их вводите, вводите, вводите, они накапливаются, и дальше вы говорите либо применяем, либо не применяем. Настраивать там можно, в общем, достаточно немного, но из того, что нужно настраивать, вы должны будете настроить название вашего домена MST, name, дальше какое-то название, network education. Ну, понятное дело, да, что свечи будут просто сравнивать текстовую строчку, и ограничение на длину этой строчки 32 символа, 31, если быть точным. Дальше, вы должны будете указать номер ревизии. Опять же, каждый раз, когда вы редактируете привязки VLAN к деревьям, или создаете новые деревья, или привязываете новые VLAN к ним, вы должны будете изменять номер ревизии,

ставить его, соответственно, ну, другим. Обычно ставят на единичку больше. То есть, вот, например, когда вы ничего не настраиваете, у вас есть номер ревизии 0. Когда вы говорите, что давайте создадим какие-нибудь привязки VLAN к деревьям, и создадим сами деревья, то есть смысл сначала начать нумерацию с единицы. Если потом захотим нести какие-то изменения, мы скажем, окей, заходим в режим конфиг MST, и номер ревизии увеличиваем на единичку. В принципе, это не необходимо. То есть, не обязательно номер ревизии всегда увеличивать. Работать MST будет и так. Просто траблшутить привязки VLAN к деревьям будет намного проще, если у вас каждый раз, когда вы что-то изменяете, вы добавляете в номер ревизии, будет намного проще. То есть, просто глазами будет видно, что на одном свече вы уже что-то поправили, а на другом нет. Если у вас какие-то сложные деревья с какими-то сложными привязками VLAN к ним, то разобраться легко, что на одном свече вы уже что-то отредактировали, а на другом нет, будет довольно тяжело. А так, глазками видите, что на одном свече номер ревизии 19, на другом 20.

Ну, очевидно, почему они не дружат. Потому что на одном свече уже что-то исправили, а на другом нет. Дальше. Нужно будет создать сами инстансы и нужно будет привязать к ним виланы. Команда instance, дальше номер инстанса и указываете в вилан. И дальше обычные номера виланов через запятую, через диапазон, через минусик. Вы указываете, какие виланы к этому инстансу будут привязаны. У вас в любом случае есть инстанс номер 0, к которому по умолчанию привязаны вообще все виланы. То есть с нулевого по 4094. С первого по 4094. Если вы указываете, что у вас есть инстанс номер 1, и вы указываете, что виланы к нему привязаны там 111, 120, 121, 122 и так далее, 130 и 140, то из нулевого инстанса вы эти виланы выкусываете. Вот. То есть вот это вот 111, вот это со 120 по 130, и вот это 140. Если вы дальше сделаете там второй инстанс с виланами 222,

из 220 по 230, то вы выкусываете 222 вилан из нулевого инстанса, и где там, ну да, 220, 230 включает в себя 222, здесь 20 по 230. ну и, соответственно, создается инстанс первый, инстанс второй. Дальше от всего этого дела считается хэш. Вы вот это вот берете, засовываете в хэш и получаете нечто. Этот хэш можно будет посмотреть, прям посчитать, что Cisco насчитала, какой хэш у вас должен будет получиться. там будет show, spanning3, mst, забыл, какая команда, по-моему, дальше на слайде будет. Ну и после того, как вы все это отредактировали, вы можете посмотреть команды show, что именно вы собираетесь сделать. Там можно посмотреть текущую конфигурацию, которая сейчас по факту работает, и та, которая будет работать, если вы ее примените. Вот show просто без параметров показывает,

что будет работать после того, как вы там все наконфигурируете. Exit применяет изменения, и когда вы указываете, что изменения применились, show spanning3 mst configuration как раз покажет, какие инстансы есть, какие виланы к ним привязаны. Если на свечах инстансы созданы разные, или виланы к ним привязаны по-разному, то эти свечи по mst дружить не будут. Они будут дружить по симуляции ванильного spanning3. То есть они будут работать в режиме как будто бы реплицируется только одно дерево за глобальную, за все виланы сразу. То есть еще раз подчеркну, ванильный spanning3 ничего не знает про виланы. Он будет выключать все порты целиком. То есть он будет говорить, что вот этот вот порт, boundary port, у нас смотрит на соседа, который находится либо в другом регионе mst, либо просто обычный классический ванильный spanning3 сосед. И соответственно мы этот порт либо гасим целиком, либо включаем целиком. Если этот порт транковый,

то вы сами себе злобный буратино, потому что у вас там будут гаситься или не гаситься все виланы одновременно. Дальше. Что еще будет нужно сделать? Можно будет указать, кто должен стать рутом в каждом дереве. Используется точно тот же самый механизм, что и в pvst, только когда мы с pvst работали, у нас была команда spanning3, vlan1 priority чего-то, или vlan2 priority чего-то. И вот здесь вот мы указывали идентификатор дерева. То есть я специально там писал такое вот, чтобы помнить, что это дерево. Здесь то же самое. Spanning3, дальше вы указываете идентификатор дерева, instance mst, mst1, и priority какой-то там. Можно указать spanning3 mst1 root primary. То есть в instance первом вы становитесь рутом. Можно указать отдельно порт priority. Если вдруг вы это захотите, это можно сделать. Можно указать spanning3 mst1 cost. Для конкретного порта вы указываете его стоимость.

По умолчанию используются long, длинные стоимости портов, которые 20 терабит, деленные на скорость интерфейса. Но если вы хотите сказать, что Cisco неправильно посчитала эти стоимости, вы можете их ручками переопределить. То есть spanning3, дальше указываете дерево, в котором надо поменять стоимость, и указываете стоимость. Так, как видите, конфигурация именно дерева самого в mst1 не отличается от конфигурации дерева в pvst. То есть механизм используется одни и те же, команда используется одни и те же, просто вместо идентификатора дерева pvst, которая привязывается к виланам, здесь мы указываем номер инстанса. Так, вот, кстати, да, команда по хэшам. Какие проблемы в mst могут быть? Если не брать в расчет проблемы, связанные с поведением между pvst и mst свечом,

а там проблем много, то чаще всего проблемы будут связаны с тем, что у вас свечи не относятся к одному региону. То есть вы пытаетесь создать mst-шные настройки, а у вас свечи почему-то ведут себя, как они вели бы в случае с boundary портами. То есть один свеч на другой смотрит и говорит, я не знаю, кто это такой, это не mst-шный сосед, я буду с ним работать в режиме совместимости. Фактически, либо у вас mst-шные свечи работают в полноценном mst-шном режиме, и они реплицируют между собой все инстансы, либо они говорят, я буду прикидываться одним классическим Spanning 3-шным ванильным свечом и буду работать в режиме симуляции ванильного Spanning 3. То есть вы фактически, если вы говорите, что мы со своей стороны настроили там виланы, настроили инстансы, настроили деревья на двух свечах, но свечи у вас почему-то не считают, что они относятся к одному региону, они у вас будут дружить не по mst, они у вас будут дружить по ванильному Spanning 3, и они будут блокировать или разблокировать все порты просто, без привязок к виланам.

Соответственно, у вас либо все виланы работают, либо вообще порт целиком не работает. Вот. Как можно проверить, получилось ли у разных коммутаторов подружиться или нет? Есть, соответственно, штука, которая называется хэш вот этой конфигурации, посмотреть ее можно командой showspanning3mst configuration digest. Если на двух свечах configuration identifier совпадает, то вот здесь вы увидите одни и те же хэши. Вы увидите название имени, название региона, вы увидите номер ревизии, вы увидите количество инстансов и вы увидите хэш. Ну, на самом деле, количество инстансов может быть разным, оно по сети не передается. Мы с вами смотрели содержимое БПДушки, там нету поля с указанием количества инстансов. Но то, что там есть, это вот хэш. 16-байтовый хэш от указания, какие деревья у вас созданы, какие виланы к ним привязаны. И Cisco показывает два разных хэша.

По умолчанию используется первый, тот, который просто digest. Второй, pre-standard digest, указывается в ситуации, когда у вас есть старые, древние Cisco, которые были выпущены до внедрения стандарта 802.1Q с 802.1 MST-шным стандартом, протоколом. И, соответственно, если у вас есть старая, старая, старая Cisco, то вы должны будете на интерфейсе сказать, отправляем хэш, не тот, который стандартный, а тот, который другой. Spanning3.mst.prestandard. На уровне интерфейса вы делаете, и тогда БПДушки, которые вы будете отправлять, будут отправляться с кривым хэшем. Ну, кривым с точки зрения нормального стандарта и правильным с точки зрения древних Cisco, которые Cisco поторопилась выпустить на рынок до появления оригинальной формулы. Но если вы работаете с нормальным оборудованием, то вы должны будете использовать только и исключительно нормальные стандартные хэши. Берете, выполняете эту команду на одном свече, на другом свече и смотрите, совпадает или нет. Если не совпадает, значит у вас инстансы созданы

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

Ну и кроме того, там еще будет наш собственный bridge ID. И вот здесь у нас показывается, что bridge ID это кто мы, вот это кто мы, наш приоритет, и откуда он взялся. Показывается, кто рут, вот, показывается его приоритет, и здесь уже показывается, да, откуда он взялся. в какой-то момент мы перестали прикидываться, что мы не знаем, откуда пришло, пришла бы подушка, в которой написано 32769 в поле priority. Ну и, соответственно, да, региональный рут показывается, что вы, это региональный рут, или может быть даже, что вы и глобальный рут. Региональный рут это рут в кусочке МСТшного дерева номер 0. Вот это вот первый рут, который вот этот вот, это рут CIST рут. То есть за всю, всю, всю, всю топологию. Таймеры, которые у нас настроены, вот такие. Таймеры, которые мы забрали от глобального рута, вот такие. То есть таймеры у всех будут одинаковые. Ну и показываются,

опять же, какие порты вошли в это дерево. Гигабит 0.1, 2, 3, 4 порта у нас в этом дереве. И показывается, что есть у нас порт гигабит 0.0 и гигабит 0.2. Мы на обоих портах получаем BPD-ушки. Соответственно, это у нас boundary порты. То есть мы получаем BPD-ушки от соседа, который либо не MST-шный, либо MST-шный, но в другом регионе. Поэтому мы говорим, это boundary порт, и мы на нем себя ведем, как будто мы один большой свитч на всех-всех-всех свитчах. Ну, в нашем случае здесь все проще, здесь всего один свитч. Вот он смотрит двумя портами на рута, он получает на обоих портах BPD-ушки от внешнего рута, и, соответственно, мы получаем BPD-ушку на одном порту вкусную, а на другом порту невкусную. Вот здесь получаем вкусную BPD-ушку, этот порт объявляем рутовым, здесь получаем невкусную BPD-ушку, этот порт объявляем alternate и блокируем его. В обоих случаях у нас идет взаимодействие с помощью симуляции RSTP.

То есть, когда мы не можем вести с соседом полноценный диалог по МСТ, мы говорим, окей, мы будем прикидываться просто классическим RSTP-шным свитчом. Мы будем блокировать и разблокировать порты, невзирая на VLAN-ы, мы будем смотреть только за физическую топологию. Есть визуальная петля или нет? Прямо визуально-визуально. На Gigabit-03 порту у нас тоже alternate порт, соответственно, мы тоже оттуда получаем BPD-ушки, и тип порта показывает, что это у нас престандартный порт, что у нас там действительно используются соседства с помощью хэшей, которые не классические, которые престандартные, и мы получаем BPD-ушки, то есть, престандарт RX говорит, что мы получаем BPD-ушки с кривыми хэшами, но мы такие BPD-ушки согласны принимать. Естественно, что мы принимаем BPD-ушки от RUT-а, и, соответственно, этот порт тоже будет alternate портом. На Gigabit-01 порту у нас получается role-designated, мы в этот порт просто отправляем BPD-ушки, point-to-point у нас

просто отправляется, и все. Здесь чего-то такого хитрого у нас нет. Дальше. В каждом инстансе, который мы сделали custom, показывается номер инстанса, показывается, какие VLAN-ы к нему привязаны. здесь вот один VLAN привязан, почему-то всего один, ну, допустим. Показывается, кто bridge, в смысле, кто мы, показывается, кто root, в нашем случае, это мы и есть. Но если бы это было не мы, покажется MAC-адрес рута, покажется приоритет, и откуда он взялся. То есть, 4 бита приоритета, и 12 бит номера инстанса. И, опять же, в каждом, в каждом инстансе у нас показывается, какие порты к нему привязаны. Здесь вы можете встретить интересное обозначение. То есть, понятно, что есть root-порт, понятно, что есть там designated, alternate, backup, это все как бы ясно. Но есть еще порт, который называется master. Мастер. Вот. Это порт,

который будет аплинком в дереве common and internal sparing 3. Это, фактически, в ситуации, когда у вас есть EST-шное дерево, этот порт указывает на рута. Не то, чтобы этот порт имел какую-то специальную особенную роль, но это примерно как root в обычном дереве. Вот. Да. Если у вас есть соседство в некотором инстансе, то есть, у нас вот есть, например, здесь вот gigabit.02, gigabit.03, эти порты, которые мы говорим, мы получаем BPD-ушки от нашего соседа в определенном инстансе. Показывается, что вот эти вот порты, которые мы отправляем BPD-ушки, соответственно, у нас вот здесь вот этот порт будет заблокирован целиком, потому что этот порт

смотрит на глобального рута во внешнем мире. это boundary-порт, и в нем, соответственно, этого дерева просто нету, поэтому там мы блокируем передачу, мы говорим, что, в общем, gigabit.03 здесь взялся просто ниоткуда. Gigabit.02, мы говорим, что это тоже boundary-порт, тоже порт, который смотрит на какого-то внешнего соседа, но, соответственно, этот порт, который мы разблокируем, и мы разблокируем коммутацию во всех деревьях на нем, если вдруг это будет такая необходимость. Поэтому мастер-порт, да, он берет роль рута, глобального внешнего рута и смотрит, за каким портом он находится. И, соответственно, этот порт всегда будет находиться в forwarding. слайд, который, на самом деле, самый, наверное, интересный про взаимодействие цисковского МСТ и цисковского

ПВСТ. По поводу того, что МСТ прикидывается на интерфейсах, которыми он смотрит на соседей классическим Spanning 3, я уже говорил. То есть, когда у нас есть МСТ-шный свеч, и у этого МСТ-шного свеча есть какие-то другие соседи, которые не находятся с ним в одном регионе, он прикидывается классическим Spanning 3. Если мы вспомним, как работают ПВСТ-шные свечи, то ПВСТ-шный свеч отправляет рядом с ПВСТ-шными БПДУшками классические ЦСТ-шные БПДУшки, классические быстрые Rapid Spanning 3-шные стандартные БПДУшки. Настраивать их поведение нельзя, но priority vector там берется из дерева Вилана 1. Так вот, выясняется, что если у вас есть рядышком транк, в котором бегают и ПВСТ-шные БПДУшки, и МСТ-шные БПДУшки, то есть с одной стороны вы настраиваете ЦИСКу ПВСТ-шную, а с другой стороны транка вы настраиваете ЦИСКу МСТ-шную,

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

включен МСТ, на этом порту есть несколько ВИЛАНов, которые относятся к тем или иным инстансам. и, соответственно, у вас приходят на этом порту БПДушки, то все БПДушки должны быть одинаково направлены, одинаково настроены по отношению к БПДушке классической ванильной. То есть, не может быть такого, что ваша ЦИСКа ПВСТ-шная рассказывает, что она рут в одном, другом, третьем, четвертом дереве или она ближе к руту, чем наш МСТ-шный свитч в одном, другом, другом, третьем, четвертом дереве и при этом дальше от рута в дереве CIST. То есть, кто посылает ванильную БПДушку, тот имеет право посылать ПВСТ-шную БПДушку. Если у вас есть ЦИСКа ПВСТ-шная, которая говорит, что я ближе к руту в ванильном дереве, она может посылать БПДушки и в своем фирменном ЦИСКовском дереве.

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

на бы подушку либо пвс тешная циска отправляет свою цистешную бы подушку и мы говорим у нас внешний свитч образовался который находится ближе круто чем мы и она же отправляет свои пвс тешные какие-то бы подушки и в этой ситуации мы говорим окей мы смотрим то что там передается в этих пвс тешными подушках и он должен заявлять соответственно что вот во всех всех всех виланах которые у нас есть он должен прислать нам свою подушку если получится так что он присылает только пвс тешные бабушки но не посылает сестра бы подушку значит получается что у нас не согласование в этой ситуации цисковская мст может заблокировать порт и в этой ситуации у нас будет объявлено на порту состояние которое называется пвс т симулейшен инконсистенсе вот картинка которая показывает что у нас на порту произошло как раз такое событие на порту fast zone от 01 была получена бы подушка

пвс тешная она была получена инфириор по отношению к той бы подушки который мы могли отправить сами то есть сосед заявил что он будет находиться ближе круту в каком-то вилане мы сравнили с тем что мы знаем за за дерево си асти мы посмотрели что не может быть такого что мы находимся ближе круту во всем дереве а он ближе к рту в каком-то своем пвс тешном дереве и заключили что у нас есть не несогласованность когда сосед говорит что он будет рутом или ближе крутую чем мы в этом дереве мы такой порт просто тупо гасим можно заказать шоу споник 3 интерфейс detail на интерфейсе и посмотреть соответственно что вот порт 3 у нас пвс т симуляшен консистент и соответственно что на этом порту у нас коммутация выключается либо сосед присылает бы подушки за и классический и пвс т деревья либо сосед не присылает

ничего нельзя сделать так чтобы сосед присылал пвс тешные бы подушки и не присылал бы подушку c стешную то есть либо мы находимся дальше от рута везде либо мы находимся ближе к рту везде вот фактически можно будет сказать что у нас взаимодействием ст и пвс т будет заключаться в том что циска мастер шнэ будет смотреть на то что в режиме симуляции классического спарнинг 3 что соседняя циска не пытается сделать так чтобы поведение и в каком-то конкретном вилане отличалась от поведения в оригинальном дереве так давайте соответственно мы на сегодня на этом закончим сделаем завтра лабу я продемонстрирую все это на практике это намного лучше посмотреть чем объяснять