Протокол STP - принцип работы

В предыдущем разделе мы поговорили про то, как устроен протокол Spanning Tree, зачем он нужен и примерно как он работает. Давайте немножко углубимся в детали, посмотрим на принцип его работы, на то, какими механизмами Spanning Tree блокирует коммутацию в петле. Самое первое, что нам понадобится, это концепция Designated Bridge. Designated Bridge будет выбираться в каждом сегменте, и он всегда будет находиться ближе всех к корневому коммутатору. То есть он по определению в каждом сегменте только один. Сегмент с точки зрения Spanning Tree — это область, в пределах которой у вас не получится ничего заблокировать. То есть, условно говоря, вы можете представить себе, что это домен коллизий. Что вот если у вас есть некий провод между двумя коммутаторами, это домен коллизий, и это, соответственно, сегмент с точки зрения Spanning Tree. Если вы возьмете, соедините 3, 4, 5 коммутаторов одним проводом, например, коаксиальным, или построите сеть на хабах между 5 коммутаторами с поддержкой Spanning Tree, то, соответственно, у вас получится вот этот вот один большой домен коллизий и один сегмент на всех общий.

В реальном мире вы, конечно же, с такими ситуациями не встретитесь, поэтому в реальном мире в 2017 году вы увидите всегда point-to-point соединение, и всегда в point-to-point соединении у вас будет ровно два участника. Ну, соответственно, будет сегмент из двух узлов. Здесь на картинке у нас нарисована сеть из четырех коммутаторов, в которых подключены пользователи, и которые соединены между собой некоторыми сегментами. И эти сегменты образуют петлю. Наша задача сделать так, чтобы Spanning Tree заблокировал коммутацию в некоторых из этих сегментов. Что будет происходить? Прежде всего, Spanning Tree выбирает сегменты, в которых каждый коммутатор участвует, и смотрит, кто будет Designated Bridge в каждом из этих сегментов. Для того, чтобы выделить Designated Bridge, нужно будет понять, где находится корневой коммутатор, потому что Designated Bridge в каждом сегменте должен быть по определению самым-самым близким коммутатором к корневому. Ну, соответственно, вы должны будете каким-то образом выделить этот самый корневой коммутатор. Давайте представим себе, что корневой коммутатор у нас каким-то магическим образом, мы сейчас не будем специфицировать, каким, выбран верхний левый коммутатор.

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

Вот, как-то вот так вот этот человечек будет выглядеть. Он, двигаясь по стрелочкам, может прийти только к корневому коммутатору. Он не может уйти куда-то в другую сторону. Более того, он никогда, ни при каких обстоятельствах не получит маршрут с петлей. Он всегда пройдет корневому коммутатора без петли. Он может пойти разными путями. То есть в нашем случае он может пойти вот таким вот путем, или вот таким вот путем, но он в любом случае пойдет путем без петель. После того, как мы определили, какой коммутатор в сети в каждом сегменте будет ближайшим к корневому, мы можем сделать вывод. Вот. Если вдруг мы сможем определить, что какой-то коммутатор может добраться до корневого одним самым выгодным образом, вот, например, вот здесь вот, то мы сможем указать, что до корневого коммутатора есть только один способ добраться. То есть вот здесь вот у нас верхний правый коммутатор может добраться до корневого по стрелочкам только одним образом. В то же время некоторые другие коммутаторы, возможно, смогут добраться до корневого коммутатора разными способами, как, например, вот этот коммутатор.

Он может пойти наверх, а может пойти вбок. У него оба варианта будут доступны. Но у него есть один вариант, возможно, побыстрее, второй вариант, возможно, помедленнее. Например, мы можем по каким-то критериям определить, что верхний путь будет быстрее, а нижний путь будет медленнее. Ну, например, потому что вот этот вот путь может быть через 10-гигабитный интерфейс, а вот этот вот через гигабитный. И здесь тоже гигабит, и здесь будет гигабит. Получается, в таком раскладе через верх немножко быстрее добраться до корневого коммутатора. И тогда наш коммутатор сможет определить, каким образом ему выгоднее всего добраться до корневого коммутатора. Выгоднее всего добраться через верхний путь, А через левый путь уже не так выводили. Вся эта штука была придумана на самом деле достаточно давно. То есть протокол Spanning 3 был разработан в 1985 году, тогда когда между коммутаторами связи были еще не point-to-point линки. Вот здесь на картинке у нас везде между коммутаторами point-to-point линки. То есть мы взяли, провод соединяли левый конец провода в один коммутатор, правый конец провода в другой коммутатор. У нас каждый провод соединяет ровно двух абонентов.

На самом деле все это придумывалось не для того, чтобы у нас было два абонента в сегменте. Это все будет хорошо работать даже тогда, когда абонентов в каждом сегменте будет больше, чем 2. Например, вы можете взять и в сегмент между двумя коммутаторами запихать пользователей. Тогда пользовательский трафик точно так же будет добираться до корневого коммутатора без петель. Обратите внимание, все та же самая логика начинает работать. Чтобы добраться до корневого коммутатора без петель, достаточно идти просто по стрелочкам. Не важно кто вы, коммутатор или конечный пользователь, компьютер конечного пользователя, вы можете добраться до корневого коммутатора, просто двигаясь по стрелочкам, просто направляя трафик в сторону D$ или нет D$2aaelt. Если у вас есть вариант направить трафик в сторону D$ или нет D$, надо направить его в сторону D$. Аналогичная ситуация может быть если у вас в сегменте между коммутаторами будет больше, чем 2 коммутатора. То есть, может быть у вас будет какой-то экзотический сценарий, например, вот такой, где в одном сегменте находит сразу целая пачка коммутаторов. Вот, например, у нас есть сегмент в котором 4 коммутатора,

Вот один коммутатор, второй, третий и четвертый. Все они сидят вот в этом вот сегменте. Что у нас в такой ситуации получается? Абсолютно все то же самое. Мы в этом сегменте выбираем один лучший коммутатор, тот, кто находится ближе всех к корневому. В нашем случае он будет выбран вот таким вот образом, потому что он сможет добраться до корневого коммутатора лучше, чем любой другой. Вот в этом сегменте мы выбрали лучший коммутатор, designated bridge. В нижнем сегменте мы точно так же выбрали лучший коммутатор, точно так же designated bridge. Мы определили, какой из коммутаторов будет лучше смотреть в сторону рота, в сторону корневого коммутатора. И по каким-то причинам мы выбрали вот этот вот коммутатор, что он будет designated bridge. Мы могли бы, в принципе, вот этого товарища тоже выбрать designated bridge. Ну, то есть не тоже, а мы могли бы при выборах выбрать его, а не левый. Но выбрали почему-то левый. После того, как мы выбрали в каждом сегменте один designated bridge, у нас получается, что трафик в сторону корневого коммутатора будет направляться всегда по одному и тому же маршруту. Не по петле. В такой ситуации очевидно, что вот этот вот коммутатор фактически исключен из процесса коммутации.

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

ему нужно будет понять, во-первых, какие сегменты здесь есть. Вот он берет для себя, определяет, какие сегменты есть. И в каждом из этих сегментов он определяет, где находится root. Мы здесь на рисунке root не видим, но мы можем предположить, что он находится, например, где-нибудь вот здесь вот. Это вот будет root. Тогда в такой ситуации коммутатор скажет, что вот скорее всего у него как-то вот так вот располагаются стрелочки, которые указывают на designated bridge. В верхнем и левом сегменте designated bridge это будет кто-то еще. То есть вот здесь вот будет designated bridge. И здесь тоже designated bridge. А в нижних двух сегментах наш коммутатор явно находится ближе к root, и поэтому designated bridge будет он сам. Как проходят выборы root bridge и designated bridge? Как происходит пересчет топологии? Все коммутаторы начинают пересчет топологии с того, что считают себя root bridge и designated bridge во всех сегментах, в которых они участвуют. Естественно, что в этом случае у нас все коммутаторы могут одновременно считать себя root, и одновременно некоторые коммутаторы в сегменте могут считать себя designated bridge за этот сегмент.

Поэтому в этот момент, когда у нас еще несогласованная топология, все коммутаторы на самом деле считают себя королями горы, и все коммутаторы на самом деле ведут себя несогласованно. Поэтому коммутация в этот момент должна быть заблокирована. Вы будете по каким-то критериям определять, что все уже срослось, что у вас состояние всех коммутаторов стало согласовано, и после этого коммутацию разблокируете. Ну вот по умолчанию, если говорить про медленный spandering 3, коммутация блокируется на определенное время. То есть вы просто говорите, вот всем коммутаторам на то, чтобы прийти в согласованное состояние, отводится некоторое время, по умолчанию 15 секунд. За эти 15 секунд вы должны будете определить, кто у вас root и кто у вас designated bridge за каждый из сегментов. Все коммутаторы начинают с того, что считают rootами себя, как следствие на всех сегментах, которые они смотрят. Они считают самих себя ближе всего к rootу располагающимися. Дальше каждый коммутатор, который считает себя designated bridge on the segment, начинает в этот сегмент отсылать специальные пакетики. Эти пакетики будут называться bridge protocol data unit или BPDU. В этих пакетиках designated bridge указывает свое расстояние до рута.

Расстояние это будет некая метрика безразмерная. Естественно, если вы сами считаете себя рутом, то эта метрика будет нулевая. Если вдруг вы понимаете почему-то, что вы не root, тогда вы говорите, сколько стоит от вас добраться до рута. Ну, расстояние, ту самую метрику, если хотите. В терминах стандарта эта самая метрика будет называться цена, cost, ну или стоимость. Кроме того, что в BPDU вы отправляете указания, сколько стоит добраться до рута, вы также указываете некий идентификатор того, кого вы считаете рутом. В момент начала пересчета топологии все отправляют сообщение о том, что они считают рутом самих себя. Указывают свой собственный идентификатор. Магия заключается в том, что если кто-то получит BPDU с указанием идентификатора корневого коммутатора, который будет числовом меньше по сравнению с тем идентификатором, который вы сейчас считаете рутом, то тогда вы немедленно перековываетесь и начинаете рутом считать того, кого вам прислали в BPDU. То есть если вдруг два коммутатора, Вася и Петя, находятся в одном сегменте, начинают они оба пересчета топологии с того, что каждый считает рутом себя, Вася отсылает BPDU, в который говорит «я считаю рутом Васю», Петя отправляет BPDU, в который говорит «я считаю рутом Петю».

И естественно у обоих из них стоимость, как добраться до рута, будет нулевая. Но затем происходит следующее. У одного из этих коммутаторов идентификатор будет меньше, чем у другого. Но у одного меньше, у другого больше, логично. Одинаковыми они быть не должны. То есть эти идентификаторы устроены таким образом, чтобы они точно были разными у разных коммутаторов. Поэтому, когда вы отправляете BPDU от Васи, соответственно вы указываете «я считаю рутом Васю». Ну вот допустим у Васи идентификатора будет меньше. Петя при получении Васиной BPDU, он видит, что текущий рут Васин лучше, чем текущий рут самого Пети. Поэтому Петя немедленно своего рута забывает и дальше начинает говорить «я считаю рутом уже Васю». А Вася, когда получает BPDU, Петину, там видит идентификатор числа больше. Поэтому он игнорирует такую BPDU, он говорит «там ничего интересного для меня нету, я не буду забывать себя самому в качестве рута». Таким образом ведут себя все коммутаторы. При получении BPDU с указанием самого маленького идентификатора в сети, все коммутаторы постепенно начинают узнавать, кто конкретно является рутом в сети.

И рассылая вот эти BPDU периодически, все-все-все коммутаторы рано или поздно начинают получать информацию про то, кто будет являться рутом. Медленный Spanning 3 работает следующим образом. Он начинает распространять информацию о том, кого каждый коммутатор в настоящий момент считает рутом, просто по расписанию. Раз в две секунды. Эти таймеры можно будет поменять, но вот по умолчанию они именно такие. Раз в две секунды вы отправляете BPDU, то есть первый коммутатор второму отправил BPDU, я считаю себя рутом. Второй третьим отправил, я считаю рутом первого. Это произошло уже не через две, а через четыре секунды. Еще через две секунды, через шесть секунд в итоге. Второй третьим отправил, через восемь секунд третьей четвертому. И вот таким вот образом за некоторое время, в зависимости от того, какой у вас будет размер сети, медленный Spanning 3 рассылает информацию про то, кто будет рутом. Забегая немножко вперед, есть еще такой быстрый Spanning 3. Там событие вида разослать BPDU с указанием текущего рута возникает также и тогда, когда вы узнаете про нового рута, то есть если вдруг вы считали рутом себя, а потом пришел Вася и сказал, что я буду рутом,

тогда вы тоже немедленно рассылаете всем своим соседям сообщение «Вася, рут». Еще один момент. Если вы получаете в сегменте BPDU с указанием расстояния до рута, и в этой BPDU написано расстояние меньше, чем ваше текущее расстояние до корневого коммутатора, вы потеряете роль десекдейтенбриджа в этом сегменте. То есть если кто-то присылает BPDU, которая выгоднее, чем та, которую вы могли бы отправить в этот сегмент, вы перестаете быть десекдейтенбриджем. Тот, кто прислал вам такую BPDU, он будет продолжать себя считать десекдейтенбриджем, а вы перестанете себя считать десекдейтенбриджем. Именно по этой причине тот, кто отправляет самую-самую-самую выгодную б概inedушку в сегмент, он один останется десекдейтенбриджем, а все остальные просто перестанут себя десекдейтенбриджами считать. Начинается все с того, что все коммутаторы в сегменте отправляют такие BPDU, но через некоторое время все коммутаторы получат BPDU от текущего диссигнатор-бриджа и перестанут себя диссигнатор-бриджами считать. Давайте посмотрим на то, как будет происходить пересчет топологии. В самом начале все коммутаторы в нашем образцово-показательном примере считают себя рутами.

Вот зелененьким выделен, кто считает себя рутом, темно-зеленым цветом. У каждого из этих коммутаторов есть некоторое количество портов, которыми эти коммутаторы смотрят в сегменты, и, соответственно, каждый из коммутаторов считает себя диссигнатор-бриджами. В этот момент, естественно, у нас в сети находится хаос. Все коммутаторы считают себя диссигнатор-бриджами, все коммутаторы считают себя рутами, поэтому на этом основании они ничего не могут сделать толком. Но они говорят, вот мы сейчас понимаем, что, наверное, раз у нас возник пересчет топологии, мы хотим сделать так, чтобы эта топология в итоге пришла к какому-то согласованному состоянию. И что у нас происходит? Мы начинаем пересчитывать топологию, и мы начинаем рассылать BPDU-шки на всех портах, которые смотрят в сегменты, где мы сейчас себя считаем designated bridge. У нас таких портов на каждом коммутаторе три. Ну, на картинке нарисован, так по крайней мере. Первый шаг. Мы начинаем посылать BPD-ушки на каждом из designated портов. На каждом порту, где мы считаем себя designated bridge за сегмент. Вот так вот отправились эти BPD-ушки. И смотрите, что происходит.

Некоторые из этих BPD-ушек, которые были отправлены, они оказались лучше, чем другие, которые пошли им навстречу. И, соответственно, в этих BPD-ушках был указан root bridge, который лучше, чем тот, который был отправлен. Я еще раз повторяю процесс, который происходил. Вот так вот у нас начиналось все. И что происходило в момент отправки BPD-ушек? Все коммутаторы считают себя root-ом. Все коммутаторы считают себя designated bridge-ом. Каждый из них отправился по BPD-ушке. И дальше в BPD-ушках, которые были отправлены первым коммутатором, было указано, я считаю root-ом первого соседа. То есть вот сюда вот была отправлена BPD-ушка с указанием, я считаю root-ом первый коммутатор. Навстречу пошла BPD-ушка с указанием, я считаю root-ом третий коммутатор. Вот у нас здесь указаны идентификаторы. Первый, второй, третий, четвертый. Что происходит, когда первый в сторону третьего отправляет BPD-ушку я root, а третий ему навстречу говорит, нет, я root. Происходит следующее, что первый, получив BPD-ушку третьего, ее игнорирует, а третий, получив BPD-ушку первого, говорит, ага, я раньше считал себя root-ом,

оказывается, я не root. И, соответственно, он перестает себя считать root-ом. И заодно он понимает, что сейчас была получена BPD-ушка от root-а в сегменте между первым и третьим коммутатором. Поэтому третий перестает себя считать designated bridge-ом в этом сегменте. Равным образом абсолютно аналогичная картинка происходит между первым и четвертым коммутаторами. Четвертый коммутатор получает BPD-ушку от root-а, говорит, я больше не root, и говорит, я больше не designated bridge в этом самом сегменте. Дальше у нас есть сегменты пользовательские. В пользовательских сегментах, в общем, каждый коммутатор отправляет какие-то BPD-ушки, их никто не смотрит, потому что обычные абоненты BPD-ушки Spanning-3, ну, они не ловят, им неинтересно это. Поэтому сегмент с пользователями, он, как правило, как был designated bridge-ом, так и остается. Вот здесь вот у нас на вот эти вот, вот эти вот, вот эти вот, и вот эти вот порты никто не покушается, никто не может нам использовать и отправить BPD-ушку с указанием я ближе к root-у, чем ты коммутатор, потому что все пользователи, они по определению от root-а находятся дальше, и более того, они BPD-ушки в норме не отправляют.

Поэтому designated порты пользовательские, они так и останутся designated. А вот, соответственно, коммутаторы, смотрящие на второй свитч, здесь начинается интересное. Каждый из них, когда отправлял свои BPD-ушки, он себя считал root-ом, и он себя считал designated bridge-ом. Но через некоторое время от третьего в сторону второго пошла BPD-ушку с указанием я root, третий root. Второй в сторону третьего отправлял BPD-ушку с указанием я второй root. Когда третий прислал второму свою BPD-ушку, второй ее проигнорировал, потому что, ну а что, тут ничего интересного нету для него, потому что второй считает root-ом самого себя. Идентификатор второго свитча меньше, чем идентификатор третьего свитча, поэтому второй игнорирует такую BPD-ушку. Третий, когда получает BPD-ушку от второго, он ее на самом деле тоже игнорирует, потому что он сейчас считает root-ом первый коммутатор. И получается, что в таком случае третий продолжает себя считать коммутатором, который находится ближе к корневому. И поэтому он у себя оставит designated port. Он перестанет себя считать root-ом, но он оставит designated port,

как то, что он находится ближе к корневому. А второй у себя тоже оставит designated port, потому что он себя считает корневым. Абсолютно аналогичная история будет между четвертым и вторым. Оба они друг друга отправят в BPD-ушке. Четвертый расскажет, что я четвертый, второй расскажет, что я второй. Второй, получив BPDU, выкинет ее, потому что там неинтересный root. Четвертый, получив BPDU, выкинет ее, потому что скажет, что я root считаю первой коммутатором. Когда он ее получит, он же root будет считать первой коммутатором. Поэтому оба сегмента, и между третьим, и вторым, и между четвертым, и вторым, у нас продолжат иметь по два коммутатора, которые считают себя десигнатором. Поэтому одного этапа рассылки BPDU мало. Нам нужно дальше продолжать эти самые BPDU рассылать. Информация о том, что root — это первый коммутатор, добежала до третьего, четвертого, но еще не добежала до второго. Стираю все рисунки со слайда и повторяю анимацию. Вот у нас разослались все BPDU, и после этого четвертый и третий перестали себя считать rootами, перестали себя считать десигн over Nathan на портах, которыми они смотрят на root А,

но продолжают себя считать десигнер back в сегментах, которые смотрят на второй. А сам второй продолжает себя считать десигнер back во всех сегментах, в которые он смотрит. Второй этап рассылки BPD-ушек. BPD-ушки рассылаются только на designated портах. Нет смысла отправлять BPD-ушки на том порту, в котором вы находитесь дальше от ROOTA. Все равно эта BPD-ушка не будет воспринята никем всерьез. На designated портах вы отправляете BPD-ушки, они приходят на получатели, и у нас второй коммутатор тоже получает информацию о том, что первый является ROOTA. И получается, что сейчас у нас вся сеть согласована, что все свечи знают, кто ROOTA, все свечи знают, как до ROOTA можно добраться в нашем случае. Второй коммутатор знает, что designated bridge не он в обоих сегментах, в которые он смотрит. И в каких-то пользовательских сегментах у нас правильно выбраны designated bridge. И в сегментах между коммутаторами designated bridge тоже выбраны правильно. И сейчас у нас получается, что действительно все коммутаторы designated bridge в сегментах своих расставили правильно.

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

То есть на него будут приходить BPD-ушки из-под двух портов сразу. Поэтому он понимает, до RUT-а можно добраться сюда или вот сюда. Зачем нам это будет нужно? А именно за тем, что если вдруг мы запускаем пересчет топологии Spanning 3, то все начинается с того, что у нас все коммутаторы действуют раз согласованно. Но они при этом блокируют коммутацию и все порты они по факту выключают. То есть при пересчете топологии у вас порты по факту не коммутируют пользовательский трафик. Они отправляют BPD-ушки, они принимают BPD-ушки, но пользовательский трафик там не коммутируется. И после окончания пересчета топологии вы эти порты начинаете потихонечку включать. Те порты, на которых вы уверены, что коммутацию включить можно. Собственно говоря, разблокировка портов происходит тогда, когда все коммутаторы точно убеждены, что действительно все порты, которые не формируют петлю, можно будет разблокировать. И разблокировать вы будете те порты, которые, во-первых, designated порты, то есть те порты, которые смотрят в сегменты, где вы этим портом, выбраны designated bridge. А во-вторых, вы разблокируете один единственный порт, который смотрит выгоднее всего на корневой коммутатор.

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

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

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

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