Протокол STP - введение

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

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

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

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

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

загрузку и коммутаторы которые формируют соответственно сеть тоже Louis xbox bars какой-то процентного загрузка по центрального процессора это одна из проблем вторая проблема то что у вас Если связи между коммутаторами могут забиться, если у вас вдругigmat butter, но используется настолько высокая, что увеличивается производительность линков. Может, то есть линок коммутаторы соединены с 10Гбитным collected by Leap Courtney, а полезность коммутаторов достаточно для того, jakby double dry plutonage using connectionology times to be 100Гбит без особых проблем. В случае у вас производительность коммутатора сам settled by Dima Да, она будет достаточная, но каналы между коммутаторами забьются достаточно быстро. Вам достаточно всего несколько браткастов отправить, на самом деле, чтобы каналы вот этим широким вещам мусором забились. И у вас никакой трафик через эти каналы не дойдет до коммутатора-получателя. Поэтому вы, даже если будете пытаться отправить какой-то полезный трафик в сеть, он у вас не дойдет до получателя.

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

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

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

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

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

Это не один какой-то протокол, то есть это несколько разных протоколов. В самом первом своем варианте он был разработан в 1985 году и включен в стандарт 802.1d в 90-м году. Этот стандарт 802.1d рассказывает про то, как нужно коммутировать трафик в Азернете. То есть он на самом деле рассказывает про то, как должна происходить коммутация. Если у вас есть коммутатор, если у вас есть что-то напоминающее коммутатор, то вот оно должно действовать определенным образом. На самом деле, если посмотреть стандарт 802.1d, текст его, он публичный, доступный, вы не увидите там нигде слово коммутатор или слово switch. 802.1d оперирует словом bridge. С точки зрения полезного действия, на самом деле, bridge и switch это примерно одно и то же. Разница только в том, как с физической точки зрения это происходит. Но смысл у них в любом случае одинаковый. Что bridge, что switch, что мост, что коммутатор. Это все устройства, которые с одной стороны берут кадр, а дальше пытаются понять, в какой конкретно порт этот кадр надо направить.

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

поэтому на самом деле в 1998 году был разработан более быстрый вариант, так называемый Rapid Spanning 3, который потом вошел в стандарт 802.1d. И вот он с 802.1d 1998 года в Spanning 3 предусматривается в двух вариантах, либо в медленном, либо в быстром. И с 2004 года в 802.1d редакция 2004 года допускает существование только быстрого Spanning 3. То есть если вы сегодня покупаете какой-то коммутатор, он по-хорошему, по идее, Spanning 3 быстрый поддерживать обязан. Ну и быстрый Spanning 3 от медленного отличается на самом деле достаточно незначительно. Не в том смысле, что у него какое-то принципиально другое поведение. Нет, у него немножечко изменена логика. Классический Spanning 3, который 90-го года, он ориентирован на то, что у вас где-то могут быть среды с общими шинами. Если у вас есть среда с общей шиной, это значит, что у вас есть некий провод, в котором могут одновременно сидеть и абоненты, и другие коммутаторы. Причем неизвестно, сколько этих абонентов, других коммутаторов может быть.

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

Классический спанинг-3, тот, который 90-го года, он ориентировался на то, что у вас есть провод, в котором некоторое заранее неизвестное количество участников, поэтому договориться никто ни с кем как бы не может. Может быть такое, что вы отправите предложение, кто-то с кем-то будет договариваться, а не все его получат. Поэтому там ориентировка была на то, что мы будем действовать определенным образом, мы будем отправлять предложение, то, как мы хотим работать, несколько раз, и вот в течение некоторого времени гарантированно все узлы получат хотя бы один раз такое предложение. Таймеры, которые там были, они говорили, что мы в течение 15 секунд будем раз в 2 секунды отправлять сообщение. Ну, если кто-то вдруг не получит одно сообщение, значит, получит другое, потому что мы за 15 секунд 7 раз отправим какие-то пакетики, в которых рассказываем, как мы настроены. Если вдруг кто-то за 15 секунд не получил ни одного такого сообщения, значит, такого узла просто нет. В быстром спанинг-3 вы просто отправляете сообщение. Если вам ответили с согласием, что вот мы действительно будем работать так, вы не ждете никакие больше таймеры.

И вы сразу переходите в какое-то состояние, ну, фактически состояние реплицированное соседом. Поэтому нету больше таймеров, точнее, они есть в режиме совместимости, но если у вас везде коммутаторы правильно настроены, поддерживает быстрый спанинг-3, то тогда у вас везде взаимодействие будет идти попарно. Между двумя коммутаторами будет сразу идти договоренность о том, как они будут работать, и попарно все коммутаторы будут договариваться между собой за единицы миллисекунд. Если медленный спанинг-3 работал, выключая сеть на срок до 30 секунд, то быстрый спанинг-3, он работает, соответственно, намного быстрее. Но работает быстрее не потому, что там что-то принципиально совсем другое. Работает быстрее за счет того, что от некоторых механизмов было решено отказаться в быстром спанинг-3. Есть и другие варианты, как можно в спанинг-3 работать. В частности, есть такая штука, как Multiple Spanning-3 с протоколом МСТ. МСТ его иногда называют 802.1.s, хотя на самом деле это протокол, который включен в стандарты 802.1.q, который вы, вероятно, знаете как протокол транкинга.

Как отправить кадр с указанием метки, в каком вилане он находится. Ну вот этот самый МСТ, он как раз предназначен для того, чтобы поверх транков спанинг-3 у вас работал. Классический спанинг-3 не умеет работать поверх транков. Он работает за физическую топологию. Смотрит, кто на кого как соединен. И если вдруг видит петлю именно с физической точки зрения, он ее выключает. Есть и другие реализации. Мы с вами в курсе разберем стандартное поведение. Ну и посмотрим на то, какие другие варианты там тоже могут быть. Как будет работать спанинг-3? Абсолютно любой протокол, который будет относиться к смейству спанинг-3, будет работать определенным образом. Вы будете находить центральную точку сети с помощью некоторого алгоритма. И затем на каждом коммутаторе, который у вас смотрят в сеть, у вас начинают отправляться некие специальные кадрики BPDU. Bridge Protocol Data Unit. И вы определяете по этим приходящим на вас BPDU, кто именно будет такой центральной точкой сети. Как будет работать любой протокол спанинг-3?

Ну, мы сейчас говорим про медленный спанинг-3. Вы блокируете все порты. Любой спанинг-3 начинает с того, что все порты, которые входят в коммутируемую сеть, он блокирует. И блокируются порты, смотрящие на пользователей, и блокируются порты, смотрящие на соседние коммутаторы. Так что, если вдруг у вас была где-то петля, в которую входили вы, вы, соответственно, такую петлю блокируете. Ну, вы блокируете равным образом и всю остальную коммутацию. Затем вы берете и начинаете определять топологию сети. Коммутаторы будут между собой обмениваться специальными кадриками. Они будут называться Bridge Protocol Data Unit. И в этих кадриках у вас будет содержаться некая информация, которая нужна для синхронизации определенного состояния коммутаторов. После того, как все коммутаторы между собой синхронизируют свое состояние, они определяют центральную точку сети. Некий свитч, который будет самый-самый-самый, ну, условно, главный. Дальше они будут смотреть, как они до этого центрального свитча, самого главного, могут добраться с помощью каких портов. Они будут оставлять только один порт, которым они могут добраться до центрального коммутатора.

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

Нижний левый свеч, у него будет один порт, который смотрит на центральный коммутатор напрямую, и другой порт, который смотрит, ну, как бы в обход. Ну, в этом случае он принимает решение, что нужно будет разблокировать тот порт, который смотрит на коммутатор напрямую. Равным образом нужно будет принять такое же решение на верхнем правом свече и на нижнем правом свече. Каждый из них будет определять, каким образом выгоднее всего можно добраться до центрального коммутатора, и этот порт они оставят у себя разблокированным. Дальше, следующий шаг, нужно будет принять решение, какие порты нужно будет оставить разблокированными, кроме порта, который смотрит на корневой коммутатор самым выгодным образом. Правило будет следующее. Если кто-то на вас может смотреть корневым портом, то вы такой порт должны будете оставить включенным, которым вы будете смотреть на того, кто на вас смотрит корневым портом. Если вы входите в цепочку коммутаторов, через которые будет проходить маршрут до центрального коммутатора хотя бы для кого-то, это будет означать, что вы находитесь ближе к центральному коммутатору, чем кто-то еще.

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

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

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

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

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