Протокол STP - выбор Root Bridge и Designated Bridge

Итак, давайте подытожим то, что мы знаем про Spanning Tree на текущий момент. Мы знаем, что коммутаторы могут самоорганизовываться, могут выбирать себе корневой коммутатор, могут каким-то образом выбрать среди всех коммутаторов в сегменте один, который находится ближе всего к корневому, и на основании принятия решения о том, кто будет в Designated Bridge, могут принять решение о разблокировке или, наоборот, продолжении блокировки коммутации на каждом из портов. Давайте поговорим про то, как происходит выбор корневого коммутатора и как происходит выбор Designated Bridge. Это, в общем, ключевой момент в работе Spanning Tree. Мы знаем, что коммутаторы во время своей работы рассылают так называемый BPDU, Bridge Protocol Data Unit. Эти BPDU, они рассылаются по таймеру, по умолчанию раз в две секунды, либо тогда, когда коммутатор считает нужным разослать такие BPDU вне планово. Но в любом случае, в этих BPDU написана некоторая информация. В частности, мы говорили, что в этих BPDU написано, кого коммутатор считает корневым,

и то, какое текущее расстояние до этого самого корневого коммутатора, наш коммутатор-отправитель знает. По факту, в этих BPDU на самом деле передается несколько больше информации, и мы сейчас разберем, что конкретно там внутри будет передаваться. Самое первое, что нам понадобится для того, чтобы посмотреть внутрь BPDU, это понятие Bridge ID. У каждого коммутатора, который работает в Spanning 3, есть уникальный идентификатор. Уникальный он потому, что он сделан таким образом, чтобы он действительно был уникальным. Он состоит из 64 бит и разделяется на две части, левую и правую. Левая часть 16 бит, будет называться Bridge Priority, и правая часть это 48 бит, по умолчанию туда записывается MAC адрес коммутатора. Не у любого коммутатора есть MAC адрес, но у тех, которые работают со Spanning 3, MAC адрес должен быть, потому что эти коммутаторы будут порождать какие-то кадры изернета, и будут принимать на себя какие-то кадры изернета. Следовательно, им потребуется адресация в пределах канальной среды, следовательно, у них должны быть MAC адреса. Что касается поля MAC адреса, в общем, тут с ним все предсказуемо,

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

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

В это поле по умолчанию вкладываются 1 единичка и 15 нулей битовых. То есть получается число 32768-десятичное, или 0800-16-ричное, то есть посерединке между двумя терминальными значениями. Самое маленькое число, которое можно вписать 0-0-0-0-0-0-0-0-0, так вот, 16 нулей, это будет просто число 0. Самое большое число, которое можно вписать в 16-битное поле, это 16 единицы двоичные, или 65535-десятичные. Вот по умолчанию то число, которое вписывается, 32768, оно ровно посерединке. Если вы захотите, вы можете это поле бридж-прайвлити поменять. И тогда, если вдруг два коммутатора будут иметь бридж-прайвлити по умолчанию, они будут сравниваться по MAC-адресу. У одного MAC-адрес будет поменьше, у другого побольше. Если два коммутатора будут сравнивать между собой бридж-айди свои, и у них приоритеты будут различаться, то есть они будут в состоянии не по умолчанию,

тогда сравниваться будут на самом деле в основном эти бридж-прайвлити биты, потому что MAC-адресы справа 48 бит, они на самом деле уже ни на что не влияют, если различаются левые, более старшие биты, бридж-прайвлити. На картинке показан пример, где два коммутатора с одинаковыми приоритетами, но с разными MAC-адресами соединены в сеть. Левый коммутатор имеет приоритет 8.0.0.0, то есть по умолчанию, и MAC-адрес у него, ну вот такой вот красивый, записан в ЦИС-коннотации D-E-A-D-B-E-E-F-1-1-1-1-1. У правого коммутатора приоритет такой же, то есть по умолчанию, и MAC-адрес уже немножко другой, D-E-A-D-B-E-E-F-2-2-2-2. Бридж-айди у них получается с клеиванием priority битов и MAC-адреса. И получается бридж-айди левого коммутатора 8.0.0.0, D-E-A-D-B-E-E-F-1-1-1-1-1. У правого 8.0.0.0, D-E-A-D-B-E-F-2-2-2-2-2. То есть 64-битные значения, которые различаются у двух коммутаторов. Гарантированно различаются, потому что как минимум различаются в части правых 48 бит.

Левые 16 бит по умолчанию у всех одинаковые, но их можно поменять. И тогда у кого левые 16 бит будут меньше, тот и будет лучше идентификатор иметь. А тот, у кого будет бита левые, соответственно, больше, тот будет вроде как хуже при выборах корневого коммутатора. Коммутаторы будут рассылать друг другу BPD-ушки, Bridge Protocol Data Unit. У них будет достаточно сложный формат, который нас сейчас не сильно интересует. Там будет сначала 5 байт некоторого заголовка BPD-ушки, в которых будут некоторые флаги, в которых будут признаки определенно указываться. Нас сейчас не интересует, что там в этом заголовке будет указываться. Но нас интересует то, что будет указываться дальше, после заголовка. И там будет 4 параметра. Первый. Root Bridge ID. 8-байтовый. Это указание на то, кого наш коммутатор считает корневым. Каждый коммутатор, который отправляет BPD-ушку, он указывает текущего рута, который он верит, что является рутом в данный момент. После чего 4-байтовое поле Root Path Cost. Это стоимость маршрута до корневого коммутатора.

4 байта дают нам возможность писать достаточно большой диапазон значения туда от 0 до 4 миллиарда с копейками. Дальше. Sender Bridge ID. Кто послал эту BPD-ушку? 8 байт. И последнее 2-байтовое значение Sender Port ID. Всего получается 22 байта. BPD-ушки можно сравнивать между собой. То есть, когда у вас есть одна BPD-ушка, полученная от одного соседа, и другая BPD-ушка, полученная от другого соседа, вы можете эти BPD-ушки сравнить. BPD-у, который вот эти 22 байта будут числово меньше, будет называться superior или лучше. А та BPD-у, которой проверите вектор или вот эти 22 байта, будет числово больше, оно будет называться inferior, то есть хуже. Если вдруг вам два соседа присылают BPD-ушки, один коммутатор присылает BPD-ушку, в которой говорит, я знаю, допустим, рута, вот, и указывает рут ID, допустим, не знаю, единичку, то есть число 1. А второй коммутатор вам присылает BPD-ушку, и в ней указывает, что у него рут будет иметь идентификатор какой-то больше, ну, например, двоечку.

Я сейчас просто для красоты указываю маленькие числа 1 и 2. Но на самом деле никто не мешает нам считать, что эти числа 1 и 2, они достаточно длинные, они 64-битные или 8-байтовые. Вот когда вы принимаете две такие BPD-ушки, вы, как коммутатор, получивший такие BPD-ушки, думаете, какая из этих BPD-ушек лучше. И вы говорите, вот здесь вот у одного коммутатора вписывается 0, 0, 0, 0, 0, 1, а у этого коммутатора будет вписываться 0, 0, 0, 0, 0, 0, 1, 0. И вы говорите, у кого рут бридж ID меньше? Рут бридж ID меньше вот у этого вот. И, соответственно, эта BPD-ушка лучше, не важно, что написано в остальных полях. Если вдруг получается так, что вам два соседа присылают одинаковые root бридж ID в своих BPD-ушках, но тогда они будут различаться какими-то другими показателями. Либо root path cost, либо sender bridge ID, либо sender port ID. Не бывает такого, чтобы два разных коммутатора прислали вам одинаковые BPD-ушки. Как минимум, у них будет различаться sender bridge ID.

Или если это один и тот же коммутатор посылает вам на двух разных портах две разные BPD-ушки, у него будет различаться sender port ID. Тот номер порта, которым он это послал. Если вдруг вы получаете BPD-ушки абсолютно одинаковые, с одинаковыми root bridge ID, с одинаковыми root path cost, одинаковыми sender bridge ID, с одинаковыми sender port ID, и на самом деле все это пришло на одном и том же порту, то вы просто воспринимаете эти BPD-ушки как отправленные одним и тем же коммутатором. Следовательно, просто, ну, взял и отправил две подряд BPD-ушки. Ничего такого. Вот эти вот 22 байта, они будут называться priority vector. Здесь показана звездочка, потому что на самом деле priority vector будет складываться из этих 22 байт плюс еще 2 байт, которые здесь на рисунке не показаны, потому что они в BPD-ушке не передаются. Но каждый раз, когда BPD-ушка приходит к вам, вы к этой BPD-ушке, к вот этим 22 байтам, прибавляете еще прозрачно 2 байта того порта, который вы получили, эту BPD-ушку. И вы указываете receiving port ID.

Receiving port ID. Тоже 2 байта. И вот эти вот 24 байта уже будут priority vector безо всяких звездочек. Когда мы знаем, как устроены BPD-ушки, давайте посмотрим на процесс выбора корневого коммутатора, designated портов и всего остального. В самом начале процесса каждый коммутатор считает себя RUT-ом и считает, что у него все порты будут designated. Поэтому он во все свои порты рассылает BPD-ушки с указанием себя в качестве RUT-а, с указанием себя в качестве sender bridge ID, с указанием нуля в RUT-path-cost, ну и только пронумеровывает порты, которым он это отправил. У нас на картинке изображены 4 коммутатора в петле. Один из этих коммутаторов, зеленый, должен стать RUT-ом, потому что у него bridge ID самый маленький, по сравнению со всеми остальными. Все остальные коммутаторы, они, соответственно, будут не RUT-ами. Ну, очевидно, что RUT должен быть только один. Причем у нас такая ситуация, что на двух коммутаторах приоритет оставлен в значении по умолчанию 8000,

это верхний и нижний. И на двух коммутаторах приоритет занизили и поставили 7000. То есть вот такой вот приоритет здесь и приоритет здесь. Все коммутаторы будут рассылать BPD-ушки с указанием себя в качестве RUT-а. Зеленый пошлет BPD-ушку фиолетовому и синему соседу, фиолетовый пошлет BPD-ушку зеленому и рыжему, рыжий пошлет BPD-ушку фиолетовому и синему, синий пошлет BPD-ушку зеленому и рыжему. Ну, то есть двум соседям пошлет BPD-ушку каждый из коммутаторов. Вот как этот процесс будет выглядеть. У нас отправляются BPD-ушки, после чего некоторые коммутаторы получают BPD-ушку от RUT-а. В нашем случае фиолетовый сосед получает BPD-ушку от зеленого и синий сосед получает BPD-ушку от зеленого. После первого шага они получают информацию о том, что root на самом деле зеленый, потому что они получили информацию в BPD-ушке о том, что сосед считает root-ом коммутатору, которого приоритет 7.0.0.0, deadbif2.2.2.2. И фиолетовый сосед получил две BPD-ушки с приоритетом 7000, но с разными MAC-адресами.

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

И его послал BPD-ушки с указанием того, что root это он. Но, тем не менее, после второй волны BPD-ушек информация о том, что root на самом деле зеленый дошла даже и до него. Давайте теперь усложним немножко конфигурацию и вспомним, что у нас есть не только root-bridge-1, но и root-подкост. Это указание того, насколько далеко root находится относительно нашего коммутатора. Каждый коммутатор рассылает BPD-ушки с указанием не только bridge-1, но и стоимости пути до root-а. Root-pass-кост. У самого root-а по определению root-пас-кост нулевая. Но если вдруг вы получаете какую-то BPD-ушку, в которую написано, что до root-а можно добраться, вы берете и к тому значению, которое написано в root-пас-кост, прибавляете дополнительно стоимость интерфейса, по которому вы получили эту BPD-ушку. Вы на каждом интерфейсе должны будете эту стоимость интерфейса каким-то образом знать. В нашем случае у нас размечены эти стоимости. Мы пока не говорим, как именно они разметились, но мы говорим, что вот этот верхний интерфейс у нас стоит 10 копеечек,

этот интерфейс стоит 10 копеечек, этот интерфейс стоит 50 копеечек, этот интерфейс стоит 10 копеечек. Вот у нас каким-то образом эти интерфейсы разметились. Стоимость интерфейса это безразмерная величина, я буду мерить ее в копейках, ну просто для удобства. Что происходит, когда у нас информация о root-е начинает разбегаться по всем портам? Я сейчас покажу, как это будет выглядеть. Все коммутаторы в начале процесса считают себя root-ом, все указывают, что они root, и что они знают, как добраться до root-а за 0 копеек. Первый этап. У нас рассылаются БПДУшки. Обратите внимание, я специально оставил БПДУшки не совсем полностью исчезнувшими, чтобы было видно, какая БПДУшка была получена каким коммутатором на каждом порту. Зеленый коммутатор получил БПДУшку от фиолетового. В этой БПДУшке было написано, что фиолетовый будет root-ом, и фиолетовый знает, как добраться до фиолетового за 0 копеек. Равным образом он получил БПДУшку от синего, в которой написано, что синий будет root-ом, и синий знает, как добраться до синего за 0 копеек.

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

я знаю, кто root, это зеленый, и я знаю, как добраться до рута за 10 копеек. Та же самая история и с нижним коммутатором с ниним. Он говорит, я знаю, как добраться до рута за 50 копеек. 0 копеек пришло в BPDU, плюс 50 копеек стоил интерфейс, по которому такая BPDU была получена. В это же самое время со стороны правого рыжего коммутатора пришла BPDU, в которой написано, рутом будет рыжий за 0 копеек, его рыжий сам знает. Ну, соответственно, при выборе двух BPDU, которые пришли на одном порту и на другом порту, фиолетовый коммутатор говорит, я предпочитаю ту BPDU, которая пришла от зеленого. У нее root-bridge ID меньше, следовательно, она супереж по отношению к конферверу BPDU, полученной от рыжего. Следовательно, рыжую BPDU мы просто игнорируем. Она была лучше, чем та BPDU, которую мы сами отправили, потому что мы сами отправили BPDU в сторону рыжего с указанием root-bridge ID с приоритетом 8.000, а он нам прислал с приоритетом 7.000. Ну, приоритеты на прошлом стаде были написаны.

Ну, соответственно, мы все равно эту BPDU проигнорируем, потому что слева пришла BPDU круче. Абсолютно аналогичная история произошла с парой синий и рыжий. Синий отправил BPDU в сторону рыжего соседа с указанием стоимости 0, рыжий прислал BPDU с указанием стоимости 0. Но, соответственно, рыжая BPDU была синим проигнорирована. И на самом деле сейчас пришла пора перейти к рыжему. Рыжий тоже эту BPDU проигнорировал. Он ее проигнорировал, потому что у него приоритет, если вы помните, 7.000, а приоритет у синего был 8.000. Поэтому для правого коммутатора, для рыжего, пришедшая BPDU была inferior. Равно таковой была BPDU, пришедшая от фиолетового. Поэтому правый коммутатор, рыжий, продолжает себя считать рутом. Сам зеленый знает, что он рут. Верхний, фиолетовый, и нижний, синий, знают, что рут зеленый. А вот информация о том, что рут зеленый, до правого, до рыжего коммутатора еще пока не дошла. Посмотрим, что будет дальше происходить на второй волне BPDU.

После первой BPDU два коммутатора узнали, кто будет рутом. Третий коммутатор еще пока не знает, кто будет рутом. Но рано или поздно, наверное, догадается. Вторая волна BPDU. Левый зеленый свитч как отправлял BPDU с указанием «я рут», так и будет отправлять. У него все порты диссигнейтед. Он отправляет указания «я знаю, как добраться за 0 копеечек до рута». Дальше. Верхний и нижний коммутаторы будут отправлять свои BPDU с указанием «я знаю, как добраться за 10» и «за 50 копеечек», соответственно. Это будет информация про зеленый рут. Справа будет идти информация о том, что рыжий знает, как добраться до рута за 0 копеечек. Смотрим. Информация разбегается. Что происходит? BPDU, которую рыжий отправлял в сторону фиолетово-синего, по-прежнему будет инфирио для них. И оба коммутатора ее игнорируют. BPDU, полученная правым коммутатором, рыжим, от верхнего, в котором написано, что рут известен за 10 копеечек, становится superior по отношению к той, которую отправил сам правый коммутатор.

И поэтому он говорит «я знаю, как добраться до рута». Рут будет зеленый. И теперь нам пришла BPDU, в которой написано, что рут известен за 10 копеечек плюс 10 копеечек стоимость интерфейса, по которому мы это получили. Поэтому всего получается до рута можно добраться за 20 копеечек. И еще одна BPDU пришла снизу, в которой написано, что до рута можно добраться за 50 копеек плюс 10 копеек стоимость интерфейса. Получается, что вот эта вот BPDU по факту стоит 60 копеек. Ну 60 копеек или 20 копеек – разница есть. мы говорим, что эта боподушка будет инфейром по сравнению с той, который мы могли бы сами отправить на этом интерфейсе. Но мы пока ничего не отправляли в этот интерфейс, поэтому когда-нибудь, когда мы отправим следующую боподушку, мы будем ее отправлять. И тогда соседи подчинятся и перестанут своей боподушке, в которых будут рассказывать, что дарута можно добраться за дорого, присылать нам. А мы будем присылать информацию о том, что дарута может добраться за дешево. Вторая волна боподушек. Правый коммутатор узнал, что можно добраться дарута до зеленого. Но у нас есть пока некое несоответствие, потому что у нас два коммутатора продолжают себя считать десигниейтед бриджами за вот этот вот интерфейс.

У нас один коммутатор посылает указание, что он знает, как добраться до рута за 50 копеек, а второй пока еще говорит, а я тоже знаю, как добраться до рута. И он присылал БПДУшки с указанием стоимости 0 в предыдущие разы, но сейчас будет указывать, что знает, как добраться до рута за 20 копеек. Поэтому нам нужна третья волна БПДУшек, и у нас рассылаются БПДУшки вот таким вот образом. Что произошло? Раньше наш коммутатор вот этот вот, нижний, знал, что до рута можно добраться за 50 копеек. Он отправлял БПДУшку, в которой говорит, я знаю, как добраться за 50 копеек. Вот эта БПДУшка, она пришла на правый свитч, и правый свитч ее благополучно проигнорировал, потому что она, очевидно, inferior по сравнению с превосходящей superior БПДУшкой, отправленной самим правым коммутатором. Правый коммутатор отправил БПДУшку со стоимости 20, и эта БПДушка пришла на нижний коммутатор. Раньше он знал, что знает, как добраться за 50 копеек. Сейчас ему пришла БПДУшка, в которой написано, что можно добраться за 20, плюс она пришла на интерфейсе стоимостью 10. Поэтому нижний коммутатор перековывается.

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

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

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

по которому такая БПДУшка получена. А в другой БПДУшке будет написано, что БПДУшка стоит 20 копеечек плюс 10 копеек стоимость интерфейса, через который она получена. Слева БПДушка эффективная стоимость имеет 50, справа эффективная стоимость будет 30. Поэтому самый выгодный способ добраться до РУТа на нижнем коммутаторе это пойти направо, а не налево напрямую на РУТа. то в этом случае какими портами у нас будет обладать. Rout у него оба порта designated. Верхний коммутатор. У него один порт, designated port. Другой порт будет root-порт, как он выгоднее всего смотрит на рута. Правый коммутатор. У него один порт будет рутовой. Rout-порт. А другой порт будет designated port. И, наконец, нижний коммутатор. У него один из портов будет root. То есть то, порт, который смотрит на рута самым выгодным образом. Это будет правый порт. И второй порт будет заблокирован. Он не разблокируется, потому что это порт не рутовый и не диссигнает. И получается у нас петля в этом случае блокируется. Как определяются эти стоимости?

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

Если у вас был интерфейс, производительность 4 Мбит в секунду, для такого интерфейса ИАЕ рекомендовала стоимость 250 единиц. Это не то, что вот именно такое число 250 и ни в коем случае не 249 или 251. Это такое рекомендованное значение, но вы можете вокруг него плясать. ИАЕ также рекомендует указывать разброс значений, вокруг которых вы можете плясать. Опять же, никто вас не заставляет использовать именно эти значения, но если вы уже делаете, то делаете приблизительно как все, условно говоря. И вот рекомендованный разброс значений для вашего права выставить совершенно произвольную стоимость, ИАЕ устанавливает следующим образом. Вот это вот значение, которое рекомендовано, разделить на 10, это минимальное значение, или умножить на 10, это максимальное значение. То есть, если у вас интерфейс 4-мегабитный, вы можете выставить абсолютно произвольное значение, это ваше право. Совсем хорошо, если вы выставляете 250 копеек, но типа разумно, если вы выставите значение от 25 до 2500.

Равным образом, если вы берете 10-мегабитный интерфейс, то вы берете и, чтобы сделать совсем хорошо, ставите значение 100. Если вы хотите поэстетствовать, то совсем хорошо, если у вас будет значение от 10 до 1000. Ну то есть здесь у нас от 25 до 2500 было. 16-мегабитом соответствовала рекомендованная стоимость 62. Ну, соответственно, если вы хотели поэстетствовать, от 6 до 620. Рекомендованное значение было. 100 мегабит в секунду. 10. Ну и, соответственно, от 1 до 100. Гигабит. Единица. А дальше уже больше, чем гигабит, в 90-м году не предусмотрели, что вообще теоретически может случиться. Поэтому для значений больше, чем гигабит, сказали, но это все равно не может такого быть. В 90-м году максимальная скорость, на которой удалось Ethernet раскачать, была 10 мегабит в секунду. Поэтому вот говорили, вот если у вас есть там 10-мегабитный интерфейс, вы выставите ему вот такое значение.

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

Поэтому в 98 году прошла ревизия стандарта 802.1D и рекомендованные стоимости изменились. Для медленных интерфейсов стоимости остались примерно те же. 250 для 4 мегабит, 100 для 10 мегабит, 62 для 16 мегабит, а дальше начался разбор и шатание. 100 мегабитом поставили рекомендованную стоимость 19, гигабиту поставили рекомендованную стоимость 4 и 10 гигабитом поставили рекомендованную стоимость 2. Предполагалось, что если у вас вдруг будет 20 гигабитный интерфейс, вы возьмете и поставите ему стоимость единичку. Ну и все, что больше, это уже область была неведома. Опять же, 1998 год предполагалось, что лучше бы на тех скоростях, которые более-менее используемы, оставить примерно то же самое. А то, что там делают новые всякие нанотехнологии, это неплохо было бы иметь в виду, но закладываться под это дело не стоит. Но в 1998 году предположили именно так. Практика, естественно, показала, что они ошиблись. И пришлось спустя 5 лет переделывать все снова.

И вышла редакция 802.1d 2004 года, которая сказала, давайте мы возьмем и сделаем прямо вот хорошо, прямо вот много сделаем возможных вариантов стоимости, чтобы можно было легко отличить гигабитный интерфейс от 10-гигабитного. В версии 90-го года гигабит от 10-гигабит не отличался. В одном случае единица, в другом случае единица. В версии 98-го года не отличало интерфейсы, которые по скорости были больше, чем 20 гигабит в рекомендованных значениях. Опять же, никто вам не мешал в Spanning 3 сказать, что вы хотите назначить стоимость единичку на 4-мегабитный интерфейс и миллион на 10-гигабитный интерфейс. Никто вам вообще помешать этому не может. Но если вы делаете все рекомендованным образом, то действительно вы назначаете стоимость единички на все интерфейсы, скорость которых больше, чем 20 гигабит в секунду в логике 98-го года. В 2004 году уже 10-гигабитные интерфейсы абсолютно были нормой. Вы могли использовать технологии агрегации этих каналов и получать таким образом скорости существенно больше 20 гигабит.

Поэтому я разработал новую рекомендованную шкалу для стоимости интерфейсов. И она получилась следующим образом. 4-мегабитные интерфейсы получали стоимость 5 миллионов, 10-мегабитные 2 миллиона, 100-мегабитные 200 тысяч, гигабит 20 тысяч и 10 гигабит 2 тысячи. На самом деле легко можно увидеть, что это цифры, не взятые совсем с потолка. Это цифры, полученные по формуле 20 терабит в секунду, разделенные на скорость интерфейса. В таком раскладе получается, что если вы берете 20 терабит, делите на 10 мегабит, у вас получается в сухом остатке 2 миллиона. Если вы берете 20 терабит, делите на 10 гигабит, у вас получается 2 тысячи. Абсолютно аналогично, на самом деле, была устроена изначальная формула 802.1d 90-го года.

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

и вот она будет подавать ровно такие же значения 250, 162, 19, 4, 3, 2, 1. Но, понятное дело, эта формула будет несколько сложнее, чем... Берем скорость, делим на скорость и получаем безразмерное значение стоимости. По факту, если вы хотите запомнить какие-то значения, которые вам, возможно, понадобятся в жизни или на экзамене, вы должны будете запомнить следующие основные значения, которые бывают в Spanning Tree. Для метрики 90-го года 100, 10, 1, 1. Это будут использоваться основные скорости, которые были в 90-м году. 100 мегабит, 10 мегабит в секунду, 100 мегабит в секунду, гигабит, ну и 10 гигабит, а их не было тогда, но как бы потом появилась достаточно популярная скорость. Для 802.1.D. 98 года 100, 19, 4, 2. И для 2004 года 2, 200, 20, 2,000. Здесь формула, здесь формула, здесь просто запомни.

119.4.2. Еще раз подчеркну, что никто вас не ограничивает в вашем праве использовать совершенно произвольные стоимости портов. Если вы хотите, вы можете везде в организации поставить для 10-мегабитных интерфейсов стоимость 164. Для 100-гигабитных, если у вас такие есть, стоимость, не знаю, 288. Вы вправе это сделать. Совершенно произвольные числа использовать для стоимости. Но чем быстрее интерфейс, тем больше должна быть вероятность того, что по этому интерфейсу пойдет трафик, что он не будет заблокирован, что маршрут до рута через этот интерфейс окажется самый выгодный. Поэтому чем быстрее интерфейс, тем меньше должна быть стоимость этого интерфейса. Поэтому выставлять на 10-мегабитный интерфейс стоимость меньше, чем на 10-гигабитный, это как бы под вопросом, насколько это разумное и актуальное действие. Предлагаемый IEE-подход, он достаточно сбалансированный и предлагает назначать стоимости в соответствии с рекомендованными значениями, так, чтобы минимизировать количество возможных проблем. Я надеюсь, что вам стало понятно, как выбирается корневолокоммутатор,

как выбираются диссигдет-бриджи в каждом интерфейсе. Я надеюсь, что вам примерно понятно, как устроены БПДУшки и как определить, что БПДУшка будет inferior или superior по отношению к некоторой другой. И, как всегда, спасибо за внимание!