Протокол Spanning Tree - несколько деревьев в единой топологии

Привет, коллеги! С вами онлайн-академия Network Education. Меня зовут Накенти Солнцев, и как всегда мы продолжаем разговор про Spanning 3. Сегодня разберем ситуацию, при которой Spanning 3 у нас будет строить за физическую топологию не одно дерево, а несколько. И, соответственно, это будут протоколы либо стандартной МСТ, либо фирменной цисковской ПВСТ и его наследники. Давайте разбираться. Зачем вообще нужно строить несколько деревьев? Спаннинг 3 классический, такой ванильный, будет строить одно дерево за всю физическую топологию без учета информации о широковещательных доменах, которые, возможно, будут виртуализированы. Если у вас есть одна большая плоская сеть, то есть как физические свечи между собой соединяются, так вот и трафик может ходить, то одного дерева для такой сети будет вполне достаточно. Вы строите указания, какими портами свечи друг на друга смотрят, вы смотрите, какие из связей между свечами лишние и формируют петли и блокируете эти связи. А все остальные, соответственно, линки остаются живыми и трафик

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

аксессовом режиме вилан 10, другой провод в аксессовом режиме вилан 20. То есть это обычные порты, обычные абонентские порты, за которыми сидят два свеча, и они передают друг другу обычные кадры Ethernet. Но эти кадры относятся к двум разным широкопощательным доменам. На самом деле можно себе представить, что у вас есть один маленький виртуальный коммутатор за вилан 10 на одном свече, и другой маленький виртуальный коммутатор за вилан 20 на этом же свече. То есть физически коробка одна, в ней две виртуальные машины. У вас, получается, один порт подключается к одному виртуальному коммутатору, другой к другому. И то же самое на втором свече, то есть у вас на самом деле, вместо одного физического коммутатора, два логических виртуальныхpri breath, И тоже каждый физический порт подключается к отдельному логическому коммутаторы. У нас получается отдельный широкопощательный домен вилан 10 и отдельный широкопощательный домен вилан 20 . В каждом из них петли нет. Тем не менее, если мы будем поверх такой топологии запускать классические

ванильный Spanning 3, он нам что-нибудь здесь заблокирует. Давайте посмотрим, что именно. Для начала у нас свечи между собой подерутся за право стать корневым коммутатором, и какой-нибудь один из них станет рутом, ну, допустим, левый. Дальше. На рутовом коммутаторе все порты у нас будут designated. Они будут отправлять бп-дружки с криками «Я ближе всего к руту». У нас два порта, обозначены будут designated порт. Классический ванильный Spanning 3 не делает различий между портами, которые относятся к разным виланам. Он относит все к одному и тому же дереву. У него designated порт будет этот, designated порт будет вот этот. Второй свитч попробует стать рутом, у него этот не получится, то есть он потеряет роль рута через некоторое время, и он скажет «Я вижу бп-дружки, приходящие от настоящего рута через два порта». На одном порту бп-дружки приходят получше, это будет рут-порт, на другом порту бп-дружки будут похуже, это будет альтернейт-порт. Ну и, соответственно, альтернейт-порт заблокируется. Физически у нас действительно есть петля, два порта параллельно смотрят на рута, а логически петли нет, потому что один из этих портов на самом

деле получает кадры 10-го вилана, второй 20-го, там петли нет. Но классический ванильный Spanning 3 про это ничего не знает. Аналогичная проблема будет с транками. Если у вас есть транковые порты, в них могут бегать разные виланы. И проблема будет проиллюстрирована справа. Опять же, у нас один патлеток будет выбран рутом второй, соответственно, выбран не будет. На одном порту у нас порт помечается как designated-порт на руте. На другом порту тоже distributed-порт. А второй свитч, видит просто бп-дружки, которые приходят, обычные ванильные бп-дружки. Он говорит, вот здесь приходит бп-душка вкусный. Это будет рут-порт, вот здесь приходит бп-душка невкусный. Это будет alternate-порт. И точно так же порт блокирует. То есть у вас блокируется целиком порт, вне зависимости от того, к какому широкопрещательному домену относятся кадры, которые приходят на этом порту или выходят с этого порта. Таким образом, ванильный Spanning 3 блокирует коммутацию на порту целиком, в зависимости от того, какую роль получает этот порт в единственном дереве.

Иногда это неудобно, иногда хочется сделать несколько различных деревьев, которые будут отвечать за различные виланы, и в каждом дереве у вас каждый порт получит разные роли, может быть одинаковые, то есть они будут получаться независимо друг от друга. Вы можете сказать, что в сценарии, когда у вас есть два свеча, соединенных между собой вот такими абонентскими портами, два свеча будут между собой синхронизировать топологии двух различных деревьев. Допустим, красное дерево и синее дерево. Красное дерево будет приводить роль порта в одно из четырех состояний. RootPort, AlternatePort, DesignatedPort, BackupPort. И, соответственно, трафик 10-го виланы будет коммутироваться в зависимости от этой роли красного дерева. То же самое будет в 20-м вилане. Мы скажем, что у нас есть синее дерево, то есть синее дерево, у него будут свои отдельные синие бпдушки, и в этих синих бпдушках будет передаваться информация про синее дерево. Соответственно, каждый коммутатор на каждом порту в синем дереве будет отдельно выбирать роли RootPort, AlternatePort, DesignatedPort, DiscardingPort.

И в зависимости от того, какую роль получит порт в синем дереве, трафик 20-го вилана будет блокироваться или разблокироваться. Соответственно, в ситуации, когда мы будем запускать Sparling 3 с несколькими деревьями, у нас будет фактически два виртуальных коммутатора. Один виртуальный коммутатор за 10-й вилан будет посылать свои бпдушки. Другой виртуальный коммутатор за 20-й вилан будет посылать свои бпдушки. Ну и, соответственно, здесь у нас будет DesignatedPort, здесь у нас тоже будет DesignatedPort, здесь у нас будет RootPort в синем дереве, и здесь у нас будет RootPort. Здесь наверху у нас будет RootPort в красном дереве, здесь будет RootPort в синем дереве. У нас будет два RootPorta в двух разных деревьях. В одно дерево красное у него RootPort будет тот, который 10-й вилана, в другое синее дерево у него RootPort будет 20-й вилан. Так, дальше. Что еще у нас тут будет из интересного?

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

который будет отправлять разными портами разные BPDU-шки, соответственно, нам придется каким-то образом указывать, что вот эта BPDU-шка отправлена в одном дереве, а вот эта BPDU-шка отправлена в другом дереве. И нам потребуется для того, чтобы это все хорошо работало, различные Bridge ID для каждого физического коммутатора в каждом отдельном дереве, в котором он будет использоваться. То есть если у нас есть физический коммутатор, у которого там два VLAN, нам нужно будет два разных Bridge ID на этом свече, которым мы будем отправлять BPDU-шки в разных VLAN. Вы должны будете каким-то образом придумать механизм, как сделать на одном физическом коммутаторе разные Bridge ID. Будет несколько разных протоколов, которые будут по-разному это придумывать, но у них, в принципе, будет примерно одна и та же схема так или иначе использоваться. Либо вы будете использовать протокол MSTP, Multiple Sparling Tree протокол. Вообще в оригинале его разрабатывала рабочая группа 802.1s, маленькая, но потом он вошел в 802.1Q стандарт, то есть так, как мы транки делаем,

вот так же предполагается, что будет там же в этом стандарте описан и MST. В MST предполагается, что вы сделаете некоторое количество деревьев, и эти деревья будут прописывать, какие VLAN к какому дереву будут относиться. Для MST требуется довольно много ручной настройки, поэтому он, ну, скажем, не очень популярен, просто потому что его действительно настраивать несколько сложнее, чем другой протокол, чем другое семейство протоколов. Это протоколы семейства PVST, первый LAN Sparling Tree. В оригинале придуманы фирмы Cisco, но затем заимствованы, поскольку они довольно удачные получились, удобные, заимствованы многими другими вендорами. То есть практически все крупные игроки телекомовского рынка так или иначе PVST поддерживают. Это Cisco, Hewlett Packard, Extreme, Juniper и Bracad. Все эти компании производят коммутаторы, которые поддерживают протокол PVST. И, соответственно, PVST будет предполагать, что у вас отдельное дерево строится за каждый VLAN.

Само название, первый VLAN Sparling Tree, будет намекать на то, что у вас в каждом VLAN будет бегать отдельное дерево. И, соответственно, много VLAN, много деревьев. Как можно будет на одном физическом коммутаторе придумать много различных обридж-идей по одному на каждой дерево? У вас есть два варианта, как это можно сделать. Первый вариант – это на коммутаторе иметь пачку MAC-адресов. То есть у вас есть тысяча VLAN-ов, вам потребуется тысяча MAC-ов. На старых свитчах можно было такую ситуацию вполне встретить. То есть вы покупали свитч, и у него на борту прописан не один MAC-адрес, а там 1024. И вот вы могли, пользуясь только MAC-адресами, использовать много различных бридж-идей на одном и том же свитче. У вас приоритеты назначались 16-бит ручками, как и в классическом Sparling Tree. А MAC-адреса вы говорили. Соответственно, берем первый MAC-адрес для первого дерева, второй MAC-адрес для второго дерева, третий для третьего. И вот вы могли 1024 дерева соорудить. В схеме с современными свитчами такой подход работать не будет,

потому что у вас на современных свитчах только один MAC-адрес, и вы не можете взять и с одним MAC-адресом сделать много разных бридж-идей. Поэтому схема, как можно будет расширить диапазон доступных бридж-идей, заимствует некоторое количество бит-приоритета. Если вы не можете играть MAC-адресом, то есть у вас вот эти вот 48 бит, они фактически вам недоступны для того, чтобы вы туда могли что-то свое написать. MAC-адрес у железки 1 он прошит на заводе. Соответственно, остается только вот левая часть 16-бит приоритета. 16-бит дает вам возможность записать туда 65 536 различных вариантов. В то же время в реальной сети столько бит-приоритета по факту не нужно. Не нужно 65 тысяч различных вариантов приоритета. Более того, даже тысячу не нужно. Даже, что же там говорить, 100 не нужно. Если даже предположить, что у вас в сети тысяча коммутаторов, эти коммутаторы будут строиться, выстраиваться в иерархическую топологию. У вас где-то будет центральное ядро сети,

там 2, 3, 4, 5, не знаю, 10 коммутаторов. Они более-менее все одинаково расположены, никто из них не будет лучше или хуже, чем другой. Ну то есть вам нужно немножко приоритетов туда отдать. Если вдруг связи с этими коммутаторами пропадают, ну, соответственно, все остальные коммутаторы к ним подключались, но они могут там как-то в кольцо связываться между собой. Ну то есть это выглядит вот так будет. У вас есть ядро сети, есть коммутаторы, которые подключаются к ядру, и они между собой могут, допустим, в кольцо соединяться. Вот. И к этому уровню уже подключаются обычные абонентские коммутаторы, но они обычно подключаются не к ядру, а к коммутаторам распределения. Вот как здесь показано, что у нас есть один уровень ядра, потом уровень распределения и уровень доступа. Так, вот как-то так это будет выглядеть. И в предположении, что у вас обычно root должен находиться где-то в ядре, ну, соответственно, вам нужно там 2-3 различных варианта приоритета на ядро.

Если вдруг root в ядре почему-то перестал быть доступен, то есть фактически все ядро развалилось, ну, вам нужно немножко вариантов, как можно выбрать лучший коммутатор в кольце distribution уровня. То есть вам нужно будет еще сюда, допустим, парочку вариантов приоритета выдать. В случае, если у вас сдохло ядро, в случае, если у вас сдох весь уровень распределения, у вас все абонентские коммутаторы фактически отвалились друг от друга, они между собой уже не связываются. И предполагается, что в такой ситуации вы должны будете, ну, меньше всего заботиться о том, что у вас root в том будет выбран кто-то не тот. Поэтому вам на самом деле в большинстве ситуаций, там, 4-го значения приоритета, в принципе, хватило бы. Но схема с Extended System ID, про которую здесь идет речь, она предполагает, что, ну, вдруг вы сойдете с ума, вдруг вам потребуется много различных вариантов приоритета. Поэтому она дает вам 16 различных вариантов приоритета. Для 16 приоритетов достаточно 4 бита. И вот самые старшие биты приоритет остаются под действительно приоритет.

А все оставшиеся биты, вот которые здесь вот, 12 бит, вот эти вот схемы, она будет откусываться от поля приоритета, и туда будет записываться фактически номер дерева. Если вы будете под приоритет отдавать самые старшие биты, если вдруг у двух узлов, которые между собой пытаются подраться за право, у кого Extended System ID будет меньше, в смысле Extended Breach ID, вот, меньше будет тот, у кого вот самые старшие биты будут меньше. То есть если вы выставляете приоритет, фактически вы выставляете наиболее значимые биты. А в вот эти вот чуть менее значимые биты приоритета вы записываете номер дерева. И когда вы отправляете BPDU-шку в дереве номер 1, вы уставляете Extended System ID 1. Когда вы отправляете BPDU-шку в дереве номер 2, вы записываете туда двоечку. То есть вы отправляете BPDU-шку, указывая свой Bridge ID, и в этом своем Bridge ID вы указываете, что это на самом деле BPDU-шка моя,

вот мой MAC-адрес, вот в таком-то дереве, вот мой Extended System ID, и вот у меня вот такой вот приоритет Ruta. Это монолитное 8-байтовое поле, но оно монолитное только снаружи. А так на самом деле внутри вот у него появляется дополнительное поле за счет поля приоритета. Эта схема совместима со схемой, когда вы манипулируете MAC-адресами. То есть если у вас есть старые свечи, у которых было много различных MAC-адресов, вы можете на этих старых свечах все равно подружиться с свечами, которые используют схему Extended System ID. То есть вот это вот поле приоритет, которое 16-битное было, оно как бы так бы и осталось. Единственное, что поменялось, это то, как мы воспринимаем это поле. А так оно, когда было 16-битное, так и осталось. Как у нас отправляли коммутаторы много различных BPDU-шек с различными Bridge ID, ну так они будут отправляться. Если вдруг у вас почему-то пересекутся два дерева, то есть вы возьмете, допустим, коммутатор, и на двух его портах, относящихся к двум разным деревьям, замкнете патч-кордом порты,

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

Вот у нас есть дерево номер один голубенькое, дерево номер два рыженькое. И, соответственно, мы указываем, что у нас в дереве номер один в синем рутом должен стать левый коммутатор, а в дереве номер два в оранжевом рутом должен стать правый коммутатор. MAC-адреса мы не можем менять, поэтому MAC-адрес у нас прошит на заводе, он всегда только один. И мы указываем, что у нас есть в дереве номер один приоритет. Вот эта вот шестерка, это шестерка шестнадцатеричная. Мы записали 4 бита. 0, 1, 0, 0. И дальше, соответственно, вот эти вот 0, 0, 0, это просто такой способ записи для того, чтобы приоритет был формально 16-битный. На самом деле от этих 16 бит мы записали только 4 бита. Вот эту вот шестерку. Ну и, соответственно, дерево номер два. То же самое. Записали в восьмерку. Когда мы говорим, что у нас коммутатор получил отдельно 16-бит приоритета в дереве номер один, отдельно 16-бит приоритета в дереве номер два, на самом деле мы говорим, что у нас BridgeID в первом дереве получился вот какой.

Шестерка от приоритета. Дальше 0, 0, 1, это идентификатор дерева номер один. И дальше MAC-адрес. DeadBeef1, 1, 1, 1. В дереве номер два приоритет восьмерка. Дальше 0, 0, 2, идентификатор дерева. И DeadBeef1, 1, 1, 1. Это MAC-адрес. У нас один и тот же на два разных дерева. Получается, в одном и том же физическом коммутаторе у нас два разных Bridge ID. Один за виртуальный коммутатор, за дерево первое, другой за дерево второе. Вот мы можем указывать, что у нас Bridge ID в одном дереве будет получше, в другом дереве будет похуже. Аналогичная ситуация с другим свечом, но с точностью до наоборот. В дереве номер один выставляем приоритет восьмерку, в дереве номер два выставляем приоритет шестерку. И MAC-адрес у него тоже какой-то есть. И получается, в дереве номер один полный Bridge ID будет восемь, дальше идентификатор дерева 001 и MAC-адрес. В дереве номер два — шесть, дальше 002 идентификатор дерева и MAC-адрес. И когда подерутся между собой бпдушки в дереве номер один, между двумя свечами,

соответственно, выяснится, что в дереве номер один самый маленький Bridge ID, тот, кто станет рутом в итоге, будет вот это вот самое — 6001 deadbif1.1. И этот коммутатор будет объявлен рутом в дереве номер один. В три номер один — рут. Дальше. В другом дереве точно так же подерутся между собой две бпдушки, но выяснится, что Bridge ID меньше у второго коммутатора. Поэтому в дереве номер два у нас 32.root. Выяснится, что правый коммутатор стал рутом. В синим дереве номер один у нас рут коммутатор левый. Соответственно, порт будет диссигнейтед порт на руте, а на втором коммутаторе это будет рут порт. С другой стороны, этот же физический порт будет диссигнейтед порт, но в другом дереве. То есть вот это вот у нас физически один провод, который соединяет два свеча.

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

ВИЛАН хорош тем, что все кадры, отправляемые в определенном ВИЛАНе, вы можете промаркировать 802.1-кьюшным заголовком, но не во всех ВИЛАНах 802.1-кьюшные заголовки могут быть. Может быть такое, что вы отправите кадр, не маркированный в нейте в ВИЛАНе, и, соответственно, он у вас придет без 802.1-кьюшного заголовка. На XTENDED SYSTEM ID тоже ориентироваться не приходится, потому что на старых свитчах у вас схема с XTENDED SYSTEM ID могла не применяться. Для того, чтобы понять, в каком ВИЛАНе у вас была отправлена определенная БПДушка, по сравнению с форматом стандартной БПДушки в 802.1-д, в PVST БПДушка используется немножко расширенная. То есть вы используете дополнительную тройку TLV, Type Length, Value, и вы добавляете к каждой БПДушке указание, в каком ВИЛАНе она была отправлена. Прямо в явном виде ВИЛАН пишите. Вы будете использовать немножко другие БПДушки по сравнению с классическим ванильным Spanning 3. БПДушки такие с классическим Spanning 3 несовместимы. То есть если вы будете отправлять БПДушки вот такие хитрые, и с другой стороны будут находиться обычные коммутаторы 802.1-д, он их не поймет.

Он просто увидит, что кадры, которые бегут на другой MAC-адрес, с другим типом вложения, он просто не поймет, что там на такой лежит. Поэтому если у вас с одной стороны используются коммутаторы CISCовские, ну или какие-то, которые поддерживают PVST, а с другой стороны используются коммутаторы, которые PVST не поддерживают, то вам нужен будет механизм, который поймут они оба. И для таких ситуаций у вас параллельно с фирменным CISCовским Spanning 3 будет бегать еще классический ванильный Common Spanning 3, но это обычный 802.1-д фактически. CST это Common Spanning 3, он может быть медленный, может быть быстрый, но смысл его именно в том, что это просто обычный, самый простой Spanning 3, который только есть. Если вы используете оборудование CISC, классический Spanning 3 работает автоматически, вы не можете его выключить, то есть он всегда есть, он отправляется, соответственно, с priority-вектором первого VLAN. PVST предполагает, что у вас в каждом отдельном VLAN бегает отдельное дерево.

Ну вот, соответственно, для того, чтобы классический Spanning 3 мог с каким-то деревом работать, он всегда работает с деревом первого VLAN. Поэтому на CISCовских свечах первого VLAN, он особенный, его нельзя выключить, его нельзя переименовать, с ним ничего нельзя сделать, именно потому что через него работает, ну, например, дерево CST. Вы можете запретить коммутацию первого VLAN, но сам VLAN у вас останется. Некоторые другие вендоры, которые могут работать с PVST, ну, например, Extreme или Juniper, они будут требовать отдельной настройки CST, то есть вы должны будете сказать, что у вас, да, PVST используется, но и классический CST тоже используется. То есть вы должны будете включать два разных варианта Spanning 3 одновременно. Если у вас две CISC, ну, или два свеча, которые поддерживают PVST, видят бы подушки PVST на порту, то CST-шные бы подушки они в этом случае будут игнорировать. Они будут использовать именно PVST. Давайте себе представим следующую штуку. Что у нас есть? Четыре свеча, собранных в кольцо. И у нас есть PVST, есть четыре VLAN, которые строят отдельно четыре дерева.

Соответственно, VLAN 11, 12, 21, 22, они строят четыре дерева. Для простоты назовем их дерево 11, 12, 21, 22. Давайте предположим, что в дереве, ну, допустим, в дереве 11, в дереве 11 у нас будет рутом правый коммутатор. И, соответственно, здесь мы скажем, что у нас стоимость вот этого вот порта в 11 дереве будет, ну, допустим, одна копеечка. 11 дерево, COST, одна копеечка. А здесь у нас в 11 дереве, 11 дерево, COST будет 100 копеечек. А в остальном все прекрасно, все одинаково. То есть вот именно для дерева 11 у нас вот такая вот особенность. Ну, и давайте для простоты для 12 дерева то же самое. 12 дерево тоже COST 1. И здесь 12 дерево COST 1.

Рут у нас отсылает боподушки. Эти боподушки приходят на самый левый свитч. И у нас приходит одна боподушка, соответственно, с указанием стоимости единичка. И другая боподушка с указанием стоимости 100. Мы говорим сейчас только за 11 дерево. В 12 дереве все то же самое, как вы понимаете. И, соответственно, в таких боподушках мы прибавляем стоимость интерфейсов. Ну, допустим, вот здесь интерфейс, там, не знаю, стоит по одной копеечке. И первый, второй за дерево 11. У нас в дереве в каждом конкретном стоимость интерфейса можно назначать отдельно. И получается, что стоимость до рута, как можно пройти через верхний интерфейс, root path cost в 11 дереве, получается двоечка. А здесь получается root path cost в 11 вилане 101. Вот 101 это больше, чем 2. Поэтому мы говорим, что у нас рутовый порт будет верхний в 11 дереве,

а нижний порт будет alternate порт. Мы коммутацию в 11-12 дереве блокируем на нижнем интерфейсе, а на верхнем разрешаем. У нас, соответственно, интерфейс первый переходит в диссигмент фарвардинг для деревьев 11 и 12. А интерфейс второй блокируется, потому что это alternate порт. Там бпдушки 11 и 12 дерева приходят менее выгодные. В то же время можно себе представить, что у нас есть еще параллельно другие деревья. То есть, например, виланы 21 и 22, у них ситуация может быть другая. Там root может быть тоже тот же самый switch, но в 21 дереве верхний коммутатор, вот это вот все относится к верхнему коммутатору. В 21 дереве у нас cost будет 100, и в 22 дереве тоже cost будет 100. А нижний, соответственно, вот этот вот товарищ, у него в 21 дереве cost будет 1, и 22 тоже будет 1. И абсолютно таким же образом получается, что в двух других деревьях левый switch получает бпдушки более выгодные на нижнем интерфейсе.

То есть, в 21 дереве приходит более вкусная бпдушка на интерфейсе номер 2, а на интерфейсе номер 1 невкусно. Поэтому мы на зеленом дереве за 21 вилан говорим, что первый интерфейс невкусный, второй вкусный. Ну и аналогично, 22 дерево на первом интерфейсе приходит невкусный, на втором вкусный. И получается в такой ситуации, что у вас есть два физических интерфейса, интерфейс 1 и интерфейс 2. На двух физических интерфейсах приходят по 4 бпдушки в каждом. И, соответственно, из этих бпдушек мы делаем вывод о том, как блокировать или разблокировать коммутацию в 4 разных виланах. Мы приходим к выводу, что трафик деревьев 11 и 12, то есть виланы 11 и 12, они будут ходить через рутовый порт, соответственно, через интерфейс 1. А виланы 21 и 22 будут ходить через низ. Получается, мы нигде не заблокировали целиком порт. Мы заблокировали коммутацию в отдельных виланах в отдельных портах,

но за счет того, что у нас можно выбирать отдельно рутов в каждом конкретном дереве, мы смогли сделать такой своего рода трафик инженерик. Мы смогли направить трафик одних виланов в один транк, трафик других виланов в другой транк. И мы не заблокировали коммутацию целиком. Это, конечно же, удобно и хорошо. Если вы отправляете БПДушки ПВСТшные, то по сравнению с классическими БПДушками ванильными, они будут немножко отличаться. Во-первых, у них будет другой MAC-адрес. БПДушки классического Spalding 3, как вы помните, отправлялись на хитрый MAC-адрес 0.1.8.0.0.5.0.0.0.0.0.0.0.0.0.0. Соответственно, БПДушки ПВСТшные отправляются на MAC-адрес мультикастовый 0.1.0.0.0.0.0.0.0. С.C.C.C.T. Зоркий глаз уже, вероятно, заметил, что вот эта вот единичка — это признак мультикаста. Дальше там OUX 0.0.0.0.0.0.0.0. Это хорошо заметная OUX-CIS-C.

Organization Unique Identifier. И дальше вот это вот cccccd – это просто красивый MAC-адрес, заканчивающийся на cccccd. После указания MAC-адресов источника получателя у вас дальше идет 2 байта. В нормальных кадрах Ethernet там мог лежать поле EtherType, но, соответственно, если вы используете BPD-ушки pvst, они могут оказаться достаточно небольшими по размеру. Поэтому они теоретически могли бы оказаться меньше, чем минимально разрешенный размер кадра. Вот классические BPD-ушки, они такими и получаются. У pvst с этим все немножко лучше, но, тем не менее, они для совместимости, ну как для похожести на обычные классические BPD-ушки тоже используют схему с вложением LLC. Но им уже не досталось прям отдельного указания Service Access Point, поэтому там, где у классических BPD-ушек используется только LLC-шный заголовок с указанием Service Access Point, 42-42.

Соответственно, BPD-ушки pvst-шный будет использовать схему с инкапсуляцией LLC-SNAP. То есть у вас заголовок LLC будет вместо Source Service Access Point Destination Service Service Access Point 42-42, это классические CST, они будут использовать схему pvst, они будут использовать aa, aa. Ну и дальше там контрольное слово 03. Вот эта вот штука означает, что у вас используется Spanning Tree, именно стандартный. Вот эта вот штука означает, что у вас используется snap-вложение. И snap-вложение дальше указывает содержимое, что у вас 3 байта Organizational Code 00000C. Вот оно на самом деле 00000C. И идентификатор протокола 010B. Ну, это уже внутренний цисковский код протокола pvst. Дальше.

Если вы отправляете кадры pvst-шные, вы их отправляете с указанием фактически, что эта BPD-ушка отправляется в дереве определенного вилана, и вы на транках, если вы отправляете BPD-ушку в транке, маркируете такие кадры метками 802.1 Q-шного вилана. Это не означает на самом деле, что этот кадр будет дальше коммутироваться. Это означает, что фактически он относится к определенному вилану. Если вы заблокируете определенный вилан в транке, то тогда кадры BPD-ушек этого вилана отправляться в этот транк не будут. Ну, в этом смысле это немножко отличается от классических BPD-ушек, которые мы на транках использовали. Там отправлялась просто BPD-ушка, но она просто отправлялась и все, без учета виланов. Так, дальше. Если вы используете 802.1 Q, да, как я уже сказал, pvst-шные бPD-ушки будут метиться, за исключением того, что pvst-шные бPD-ушки не размечаются на native вилан.

Native вилан в терминологии Cisco, untarget вилан в терминологии всех остальных вендоров. То есть, если у вас есть транк 802.1 Q, там есть пачка виланов, которые отправляются кадры помеченными 802.1 Q заголовком, и не более одного вилана, которые отправляются не помеченным. Так вот, pvst-шные бPD-ушки в native вилане не размечаются. Вот тот, который untarget вилан, там бPD-ушки будут идти без 802.1 Q заголовка. Так же, как обычные кадры, относящиеся к этому вилану. Если у вас первый вилан native, ну, значит, вы будете по пдушке pvst-шные первого вилана отправлять без метки. Если вы native поставили там 666 вилан, значит, вы будете по пдушке 666 отправлять без метки. Если вы помечаете 802.1 Q-шными метками какие-то кадры, у вас там есть 2 байта указания 8100, есть указание 12 бит номер вилана, и есть еще 4 бита. И эти 4 бита делятся на 2 части. 3 бита указания кода приоритета 800.2.1 P,

и, соответственно, у 800.2.1 Q, у pvst-шных бPD-ушек, там будет использоваться наивысший приоритет, network control, это семерка. Ну и в остальном бPD-ушки такие же, как классические, то есть само мясо бPD-ушек, с заключением самого заголовка кадра, они почти такие же. То есть точно так же используется заголовок бPD-ушки, 5 байт, мы разбирали в предыдущем видео, как он выглядит. Точно так же используется priority vector, вот он, 22 байта root bridge ID, root path cost, center bridge ID, center port ID. Точно так же используются таймеры 8 байт, 4 таймера по 2 байта. И добавляется еще вот эта вот TLV-шка, originating VLAN, которая указывает, собственно говоря, в каком VLAN-е оно было отправлено. Тип такой бPD-ушки будет 0,0,0,0. Дальше. Двубайтовое поле длина содержимого, двоечка там указывается, и 2 байта самого мяса, это, ну, какой VLAN у вас есть.

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

И можно сказать, вот бывает синий трафик, бывает красный трафик. Синий трафик ходит вот так, красный трафик ходит вот эдак. И дальше привяжем виланы к этим двум деревьям, или к трем деревьям, или к четырем. То есть сколько деревьев вы захотите, столько сделайте. Главное, что они больше не привязаны к виланам по схеме один к одному. Если у вас много виланов, вы можете сделать два дерева и сказать, допустим, четные виланы привязываем к левому дереву, нечетные виланы к правому дереву. Вы можете сделать до 64 деревьев пользовательских. Плюс у вас есть одно служебное дерево, которое называется CIST, Common and Internal Spanning Tree. Оно всегда есть, вы не можете от него никак избавиться. По умолчанию привязаны все виланы к нему, и плюс там же передается некий служебный трафик, необходимый для работы МСТ. Но если вы заморачиваетесь с включением МСТ, предполагается, что как минимум два дерева вы захотите сделать. Потому что если вы хотите использовать одно дерево, вам достаточно будет классического Spanning Tree. Поэтому если вам классического Spanning Tree недостаточно, если вы уж решили заморочиться сделать МСТ,

то вам как минимум два дерева придется сделать. И вот в этом случае вы пользовательские деревья будете создавать, и эти пользовательские деревья будут называться MSTi. Multiple Spanning Tree Instance. То есть фактически вот эти вот самые пользовательские деревья — это инстанцы. Дальше вы должны будете привязать эти виланы к инстанцам. И если у вас где-то виланы будут привязаны не одинаково, то есть у вас, допустим, вы говорите, на одном свече привязываем четные виланы к синему вилану, нечетные к красному, а на другом говорите, что давайте привяжем первую тысячу виланов к синему, а вторую тысячу к красному, то у вас, возможно, петля. Потому что у вас по-разному будет трафик коммутироваться между этими портами в разной логике. И, соответственно, это, возможно, приведет к проблемам. Поэтому Spanning Tree MST будет проверять, действительно ли вы привязали виланы одинаково. И если в случае, если у вас будет несовпадение какое-то, если вы виланы привяжете не одинаково, на одном свече скажете, что так, виланы привязываются,

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

Соседние свечи при этом могут быть и MST-шными, то есть если у вас MST-шные свечи дружат с PVST-шным или с другим MST-шным, они все равно могут дружить через вот это самое ванильное Spanning Tree, через единственное дерево с использованием классического 802.1D протокола. Давайте посмотрим, как это все может выглядеть на примере. Опять же, та же самая ситуация. У нас 4 свеча, связанных к кольцу. У нас правый коммутатор, известно, что он будет рутом во всех деревьях. И мы делаем два деревья, синий и красный. В синем дереве указываем, что в дереве синем у нас будет cost 1. В красном дереве у нас будет cost 100. Ну и наоборот, в нижнем свече, то есть говорим, в синем дереве cost 100, в красном дереве cost 1. Когда будут приходить бпдушки первого дерева на интерфейс 1,

соответственно, root path cost у нас будет 1 в дереве t1. В дереве t2 root path cost 100. Ну и, соответственно, снизу будет все с точностью до наоборот. И мы в этом случае можем сказать, что вот у нас коммутатор, у него есть два интерфейса, на обоих приходят бпдушки. В дереве номер 1 приходит вкусный root path cost, в дереве номер 2 приходит невкусный root path cost на интерфейсе первом. Ну и наоборот, снизу, что там приходит невкусное дерево 1, вкусное дерево 2. И мы говорим, вот в дереве номер 1 на интерфейсе мы переходим в designated forwarding, в дереве номер 2 на интерфейсе 1 мы блокируем коммутацию. На втором интерфейсе напротив синее дерево приходит невкусное, правое дерево приходит вкусное. И после чего мы говорим, у нас привязаны к дереву номер 1 Виланы 11 и 12. Соответственно, на интерфейсе у нас будет трафик 11 и 12 Виланы входить нормально,

а 21-22 будет, соответственно, заблокирован. На интерфейсе втором все сочности до наоборот. Трафик 11 и 12 Виланы будет заблокирован, трафик 21-22 Вилана будет разблокирован. То есть мы добились того же самого эффекта, что и с ПВСТ, но используя меньшее количество деревьев. МСТ будет использовать BPD-ушки, опять же, немножко похожие на классические, но у них будет содержимое уже сильно отличаться по сравнению с ПВСТ. Для начала, заголовок самих кадров будет примерно такой же. То есть так же, как и в случае с классическим Spanning 3, у нас есть MAC-адрес получателя, вот такой вот. Дальше, так же, как и в случае с классическим Spanning 3, мы используем инкапсуляцию LLC, Destination Service Access Point, и Source Service Access Point будет 0.42. Дальше, код вложения, протокол version identifier. Это уже будет заголовок Spanning 3. То есть вот здесь вот у нас 5 байт.

И в этом заголовке, как вы помните, у нас самое первое поле, это будет 2-байтовое поле, что за протокол. И там будет точно так же, как и для всех остальных версий протокола, всегда лежать число 0.0.0.0.2-байтовое. А после чего есть 1-байтовое поле протокол version identifier. Что конкретно за Spanning 3 используется? И вот этот вот протокол version identifier у медленного классического Spanning 3 был 0, у быстрого классического Spanning 3 была 2, а вот у MST там 3.0. Поэтому классические свечи не перепутают MST-шные BPD-ушки с BPD-ушками медленными или быстрыми. Дальше. Тип BPD-у у MST всегда одинаковый 0.2. Ну то есть он на самом деле внутри себя бегает всегда в том же самом режиме, что и бегает быстрый Spanning 3. Там уже не будет никогда уведомления рута сначала о том, что у нас случилось перестроение топологии, топологии, change notification, acknowledge, все вот это вот не нужно. Внутри каждого инстанта MST бегают просто обычные BPD-ушки

по той же логике, что и в Rapid Spanning 3. Дальше. После чего, после заголовка у нас идет priority vector. Наш любимый. RootBridgeID, RootPathCode, CenterBridgeID, CenterPortID. Здесь никаких изменений нету, за одним небольшим исключением. Вот эта вот вся штука, это за весь, ну так называемый регион Spanning 3, то есть за дерево фактически CST. Так, дальше. Таймеры. Ну с таймерами все та же самая история, что и в любом другом протоколе, ничего нового. После чего добавляются дополнительные два поля, которые относятся к MST, и они указывают на то, что внутри лежит. И там идет указание, что внутри лежит протокол MST вложения, version true length. Это указывает, что дальше идет какое-то мясо. Мясо MST-шное. Фишка в том, что MST-шное мясо может быть разного размера. Если говорить про обычные BPD-ушки, медленные или быстрые,

они всегда были одинаковые. Если говорить про PVST-шные BPD-ушки, они тоже более-менее одинаковые. И там только одно поле могло фактически меняться. Это 802.1-кьюшный заголовок. То ли есть, то ли его нет. В остальном они всегда одинакового размера были. И то видно хорошо по BPD-ушке, есть у нее заголовок 802.1-кьюшный или нет, по наличию заголовка Ethertype. А вот у MST все плохо, потому что у него BPD-ушки разного размера. Там вот дальше идет поле MST-экстеншн. И это поле, оно может быть непредсказуемого размера. И вот для того, чтобы указать, какого размера оно, на случай, если вдруг вы передаете кадр, и дальше какое-то содержимое к нему еще приклеится, вот указывается, сколько этого самого содержимого передается, 2-байтовое поле. И затем передается само вот это вот самое содержимое MST-экстеншн. Там указывается MST-конфигурэйшн-эдентифайр. Так, здесь у меня опечатка на слайде не 2 байта, а здесь сильно больше на самом деле. Вот это вот поле MST-конфигурэйшн-эдентифайр.

Оно будет аж 51 байт. То есть не совсем понимаю, откуда взялось 2 байта здесь. Это поле будет композитное. Там будет передаваться содержимое, указывающее на имя региона, на номер ревизии. И дальше будет передаваться 16-байтовое значение хэша от базы привязок виланов к инстанциям. Поэтому именно вот здесь, вот в MST-конфигурэйшн-эдентифайр, будет осуществляться магия проверки правильности настройки соседних свечей. Если два свеча не могут подружиться между собой, это, возможно, происходит потому, что у них неправильно привязаны виланы к базе, виланы к инстанциям. И чтобы не передавать указания, что вот первый вилан привязан к такому дереву, второй вилан к такому дереву и так далее, используется схема просто с хэшем. Все свечи будут одновременно снимать хэш со своей базы и сравнивать хэш. Если одинаково, значит, одинаково настроено. Окей. Если не одинаково, значит, не надо знать, что у соседа вот такой вилан, не такой, как у нас. Просто не одинаково и все. Значит, не сможет MST дружить в любом случае.

Поэтому хэши не совпадают, значит, дружба не получится. 51 байт, там сложное содержимое. Там используется текстовая метка названия региона, там используется номер ревизии, там используется вот этот вот самый хэш, и там еще кое-что есть другое. Но нам это сейчас будет не сильно интересно. Дальше указывается вот это вот значение root path cost. Как можно добраться до свеча внутри дерева, внутри инстанса специального служебного CIST, до рута именно по MST-шным свечам? Это отдельная часть от вот этого самого root path cost. То есть вот это вот root path cost, это сколько стоит добраться до рута вообще общего, за всю-всю-всю-всю топологию, включающую не Spanning 3 MST-шные свечи. А CIST, Internal Root Path Cost, это указание на то, сколько стоит добраться до свеча ближе всего к руту в пределах MST-шной топологии.

Дальше. CIST Bridge Identifier. Это как наш коммутатор, какой Bridge ID будет иметь в дереве CIST. То есть у нас в каждом дереве будет свой отдельный Bridge ID. И вот это вот CIST Bridge Identifier, это фактически указание на то, что у нас есть какой-то приоритет, то, что у нас есть какой-то MAC-адрес, и у нас есть дерево номер 0. CIST-шное дерево — это дерево номер 0. Remaining Hoops — это указание на то, сколько прыжков между свечами BPD-ушка прошла от рута. Если вы помните, у нас было поле Message Edge в предыдущих версиях протокола Spanning 3. Ну, соответственно, в MST есть в явном виде ограничения на то, сколько прыжков между свечами допустимо пройти BPD-ушки. И вот там по умолчанию число 20, соответственно, вы отправляете первую BPD-ушку, у вас Remaining Hoops получается 19. Потом следующий свитч получает BPD-ушку, получает 18. Тот, кто получает BPD-ушку с Remaining Hoops

меньше, чем... меньше, чем единичка, то есть 0, он получает уже ее как бы невалидно, он ее всерьез не воспринимает. Так, далее. MSTi Configuration Messages. Это поле переменной длины, и оно будет состоять из 16-байтовых блоков. И в каждом блоке у вас будет указание на то, какой у вас BridgeID будет в каждом конкретном инстансе, который вы придумаете, и какой у вас будет, соответственно, root-pass-кост до этого дерева. Сендер BridgeID у вас более-менее везде предсказуем и одинаковый. Ну и SenderPortID тоже предсказуем и одинаковый. Поэтому там 16-байт будет вполне достаточно. Так. Ну, в общем, все. То есть вот это вот довольно сложная структура. У вас BPD-ушка будет передаваться одна за все деревья, но в этой BPD-ушке будут передаваться указания на priority-вектор каждого конкретного дерева

в виде вот этого самого экстеншена. Я надеюсь, что это видео рассказало про то, как работают протоколы Spanning 3, поддерживающие несколько деревьев за физическую топологию. Хотел бы поблагодарить вас за внимание и надеюсь встретиться с вами на курсах, где мы рассматриваем работу не только протокола Spanning 3, но и многих других протоколов на оборудование конкретных производителей. А на сегодня все. Спасибо за внимание. И пока-пока.