PVST

Продолжаем разговор про курс по коммутацию Cisco Switch. Обсудили мы с вами то, как по стандарту должен быть реализован протокол Spanning 3 ванильный, так называемый Spanning 3, который классический стандартный 802.1d, либо 802.1d 90-го года, который медленный Spanning 3, либо Spanning 3 с кодом версии 0, либо быстрый Spanning 3, он же Rapid Spanning 3, он же 802.1d 2004 года. Но, соответственно, это стандартное поведение, и если вдруг вы будете работать со свечами какого-то вендора, не CISC, то вы будете работать, скорее всего, как раз с ванильным Spanning 3, либо с MST. А вот на CISC вы не можете включить просто стандартный Spanning 3, то есть вы обязаны работать с фирменным CISC протоколом, который называется PVST, Pervilan Spanning 3.

При этом стандартный Spanning 3 на CISC тоже есть, но он не подконтрольный вам, то есть вы не можете его настраивать. Он свою конфигурацию берет из одного дерева PVST. Вот мы с вами говорили, да, на ICND 1.2, что на CISC есть только фирменный Pervilan Spanning 3. На самом деле там оба Spanning 3 и классический ванильный, и фирменные CISC работают одновременно и синхронно. Но, соответственно, деревья строятся в PVST, а потом одно из этих деревьев используется для того, чтобы работать с классическим Spanning 3 тоже. Так что давайте разбираться, как работают фирменные CISC, и PVST, ну и заодно вы помните, как работают и стандартные ванильные Spanning 3 на свечах CISC. Зачем нужно вообще иметь Spanning 3, который знает что-то про VLAN? То есть почему нельзя использовать ванильные Spanning 3? Я, в принципе, уже рассказывал, что классический ванильный Spanning 3 ничего не может знать про виртуализацию широкопрещательных доменов.

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

У нас получается, что отдельный широковещательный домен здесь и отдельный широковещательный домен здесь. Но это два не пересекающихся широковещательных домена. Несмотря на то, что визуально петля есть, на самом деле петли там нет. Нет негативных последствий петли. У нас не выполняется коммутация из одного провода в другой. За счет того, что это провода в разных широковещательных доменах. Но классический Vanilla Spanning 3 ничего про это не знает, как уже говорилось. Он выбирает рута, независимо от того, кто в каком вилане. Он говорит, что у нас есть два железных коммутатора, каждый из них отправляет в каждый порт или принимает в каждом порту BPDU. Допустим, левый выбирается RUT, он говорит, я отправляю BPDU тут, я отправляю BPDU тут. Другой свитч принимает такие BPDU и говорит, я вижу BPDU от RUT на одном порту, я вижу BPDU от RUT на другом порту. Один порт я объявляю RUT портом, другой порт я объявляю альтернатом и блокирует коммутацию в нем. То, что там был 20-й VLAN и этот 20-й VLAN больше нигде не присутствует, ну как бы это его половые трудности.

По факту 10-й VLAN у нас работает, а 20-й VLAN не работает. То есть у нас выключается целиком интерфейс, в котором бегает 20-й VLAN. Та же самая история возможна и с транками. С транками у нас кадры, которые бегают в каждом конкретном проводе, они будут относиться вообще к разным VLAN. Ну то есть, например, вот у нас представьте себе, что у нас есть два опять же свитча, там два транка между ними проложены, в одном транке 10-й и 20-й VLAN, в другом 30-й и 40-й. И опять же, та же самая история. Классический ванильный Spanning 3 ничего не знает про транки, ничего не знает про VLAN. Он знает только про то, что есть RUT, есть два диссигнает-порта на RUT, диссигнает-порт 1, диссигнает-порт 2. Соответственно, он боподушки свои посылает. Второй свитч принимает боподушку на одном порту, говорит, это RUT-порт. На другом порту принимает боподушку, говорит, это alternate-порт. И блокирует целиком коммутацию на этом порту. Неважно, какие VLAN-ы, какие там метки 802.1 киушные, неважно, там, ISL-овский транк.

Он просто выключает целиком коммутацию на порту вообще совсем целиком. То есть петли по факту нету, но Spanning 3 классический говорит, что, ну, знаете, вот я смотрю просто на железные коробки и вижу, что петля там по факту есть. Поэтому на уровне всей физической топологии есть петля. Этого мне достаточно для того, чтобы коммутацию на порту выключить, даже если это на самом деле делать не нужно или даже немножко вредно. Cisco, когда купила компанию Crescendo, которая придумала VLAN-ы и которая придумала Trunk-и, она столкнулась с проблемой, что вот да, классический Spanning 3 с этими VLAN-ами работал плохо. Поэтому она стала продвигать свой фирменный протокол, который называется PVST. PerVLAN Spanning 3. В принципе, сегодня мы можем встретить этот PVST и его, скажем, развитие PVRST, PerVLAN Rapid Spanning 3, в оборудовании очень многих вендоров. То есть, понятное дело, что сама Cisco его поддерживает и активно продвигает. его можно было встретить в Hewlett Packard, его можно встретить в Juniper, Bracad, Extreme, Dell, который Force 10, Alcatel.

Ну, то есть, так или иначе, очень много вендоров его поддерживают и нормально с ним работают. Вы можете сочетать PVST-шные свечи между собой, даже если они принадлежат к разным вендорам. Но, тем не менее, достаточно много вендоров PVST и не поддерживают тоже. И поэтому, если вдруг вы хотите работать с VLAN-ами каким-то иным образом, не с помощью фирменного Cisco стандарта PVST, то вам доступен другой стандарт, который называется MSTP. MSTP – это протокол разработанной комиссией 802.1.s, который впоследствии вошел в стандарт 802.1.q в редакции 2005 года. Ну, и до сих пор там остается. 802.1.d строит одно единственное дерево. То есть, он говорит, у нас есть физическая топология. Вот граф, который формируется физическими портами, мы в нем обнаруживаем петли в физическом графе и, соответственно, блокируем коммутацию сообразно тому дереву, которое мы будем строить.

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

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

И в каждом дереве выбираем роль для этого порта. Будет ли этот порт там designated, рут или alternate или бэкапом. Вот. Если говорить про MST, MST строит не отдельное дерево за каждый вилан, а MST строит несколько деревьев, но меньше количества деревьев, чем количество виланов у вас есть. И дальше вы привязываете виланы к этим деревьям. То есть вы говорите, давайте построим дерево номер один, и давайте построим дерево номер два. И дальше скажем, что все виланы, которые привязаны к дереву номер один, коммутируются одинаково. То есть мы включаем или выключаем коммутацию на каждом конкретном порту сообразно тому, не что там вилан о себе думает, а что вот это вот дерево, к которому привязан вилан, будет о себе думать. И, соответственно, MST – это протокол, в котором вы создаете отдельные экземпляры деревьев и потом привязываете к ним виланы. В любом случае у вас может быть такое, что каждый коммутатор будет являться участником нескольких деревьев.

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

когда одному коммутатору приходится иметь несколько Bridge ID, не пересекающихся между собой. Вот. Если говорить про PVST, он же PVST+, он же PVRST, это семейство протоколов фирменных цисковских, которые построены на основе классического Spanning 3, но при этом поддерживают виланы. Плюс к тому, циск в процессе развития этих протоколов дополнительно расширял их функциональность и сделала такую штуку, которая называется Spanning 3 Toolkit, STP Toolkit. То есть это всякие ускорители, которые позволяют Spanning 3 быстрее реагировать на изменения в сети. Мы про них, опять же, отдельно будем говорить. Разница между этими протоколами будет заключаться в следующем. PVST – это медленный Spanning 3 802.1D 90-го года, который работает только с ASL-овскими транками. PVST+, это тот же самый протокол, но который поддерживает тоже и транки 802.1Q. В принципе, разницы между ними практически отсутствуют.

Плюсик намекает на то, что действительно разница там такая, чисто косметическая. Есть еще Rapid PVST или PVRST. Это, соответственно, протокол на основе быстрого Spanning 3, но по сути своей он устроен точно так же, как и PVST. То есть это просто медленный фирменный цисковский протокол, в котором сделали те же самые ускорения, что и в быстром Spanning 3 классическом, относительно медленного классического же Spanning 3. что PVST, что PVST+, что PVRST будет строить дерево за коммутацию в отдельном Вилане, а не за всю вообще физическую топологию. То есть, например, вот у нас есть три коммутатора, которые связаны в кольцо, и у нас есть два Вилана, которые в этих линках будут передаваться. То есть все эти линки, это у нас будут по факту транки. И вот для того, чтобы, соответственно, сказать, чем у нас будет PVST отличаться от обычного протокола, как раз идеальный вариант – это посмотреть,

что будет, если мы запустим здесь обычный классический Spanning 3. Обычный классический Spanning 3 скажет, мы выбираем какой-то один коммутатор root-on. У него будут, соответственно, все порты designated. Десигнейтед здесь, десигнейтед здесь. Вот этот вот коммутатор скажет, как можно добраться до рута. Ну вот так вот лучше всего будет добраться до рута. Здесь, соответственно, вот так вот будет лучше всего добраться до рута. Ну и эти двое между собой подерутся. Кто-то один из них скажет designated port, другой скажет alternate port. Ну и alternate port будет заблокирован. По факту из трех линков, которые у нас есть, один заблокирован, два разблокированы и по факту могут быть использованы. Но если мы представим себе, что у нас есть не просто какое-то абстрактное кольцо из трех коммутаторов, а какие-то реальные коммутаторы, которые мы можем встретить в реальной жизни, это что будет? Это будет, например, distribution switch 1, distribution switch 2 и access switch какой-то. Вот. Здесь у нас юзеры. И эти юзеры, они генерируют какой-то трафик. Если мы обычный медленный,

ну медленный, быстрый спарринг 3 запустим, у нас спарринг 3 заблокирует порт целиком. И, соответственно, деньги мы заплатили за два провода, которые тянутся до distribution switch, а по факту работает только один. То, что там distribution между собой связаны, да, позволяют нам трафик вот по какому-то такому пути отправлять во внешний мир с distribution switch 2, если будет у нас такая необходимость. Но, тем не менее, да. Деньги заплатили за два порта, по факту работает только один. В то же время, если мы запустим на этой же топологии отдельные деревья за каждый вилан, за 10 вилан и за 20 вилан, то у нас получится следующая картинка. В 10 вилане рутом будет выбран левый свитч. В левом свитче, давайте я синенькие чернила возьму, синенькие вот такие, например, у нас будет указано, что это будет designated port, это у нас тоже будет designated port, это у нас будет root port, это у нас будет root port, и, соответственно, здесь у нас, ну, вот это, наверное, будет designated port, раз это distribution switch, а здесь будет alternate port. И в синем вилане мы коммутацию здесь вот заблокируем.

В то же время в другом 20 вилане мы можем выбрать рута, иначе мы можем сказать, что root в 20 вилане будет правый свитч, и, соответственно, в правом свитче, в зеленом вилане, у нас будет designated port, designated port, тот же самый порт, но, соответственно, в другом вилане. Здесь у нас будет root port, здесь у нас будет designated port, и здесь у нас будет, соответственно, root port и alternate port. И коммутация зеленого вилана будет заблокирована в другом порту. Деньги заплатили за два провода до distribution switch, физически провода два, и каждый из них используется. В одном из них бегает синий вилан, а в другом из них бегает зеленый вилан. Вот здесь у нас в одном проводе, который до рута смотрит лучше, в зеленом вилане бегает трафик, зеленого вилана, а в другом проводе у нас бегает трафик синего вилана. Деньги заплатили за два провода, по факту работает тоже два. При этом петли нигде нету, то есть то, что одновременно мы по двум проводам гоним трафик в сторону distribution switch,

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

в которые участвует Spanning 3, чем больше виланов в этих портах передается, то, соответственно, тем сложнее фирменному цисковскому Spanning 3 становится жить. А нагрузка на свечи, конечно, в этом случае получается больше, но ничего не сделаешь ради повышения эффективности работы. Для того, чтобы получить в каждом дереве уникальный идентификатор BridgeID, ПВСТ будет использовать следующую штуку. Он говорит, у нас есть BridgeID, он 64-битный. Соответственно, эти 64 бита состоят из 48 бит мак-адреса и 16 бит, которые называются Bridge Private. Вот нам нужно каким-то образом сделать так, чтобы на одном свече у нас получилось несколько разных BridgeID за каждый вилан, в котором мы работаем. мак-адрес на железке может быть только один. Поэтому нам нужен будет какой-то механизм, как сделать из одного мак-адреса много разных BridgeID.

Если бы у нас было много разных мак-адресов, мы бы могли сказать, окей, давайте мы возьмем, сколько вот у нас виланов есть, там на железке поддерживается, там 256 виланов, возьмем 256 мак-адресов. И на каждый вилан, мы просто скажем, виртуальный свитч там в 10 вилане получает такой мак-адрес, виртуальный свитч в другом вилане получает другой мак-адрес. И раньше такая схема тоже использовалась. Она просто предполагала, что у вас на одном свитче может быть много мак-адресов, и на некоторых платформах действительно вы такое могли встретить. Но сегодня это исключительно редкое поведение. Скорее всего, на современных свитчах вы будете получать в распоряжении только один мак. Никаких патчек мак-адресов вам уже не выдается. Поэтому вы будете сегодня использовать схему, которая будет называться Extended System ID. Она заключается в следующем. 16 бит приоритета Bridge Priority – это дофига. Это uber-ультра дофига, потому что это дает нам возможность создать 65 536 разных приоритетов. Это не 65 536 разных свитчей в сети.

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

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

окей, давайте мы под приоритет оставим какое-то разумное количество бит, не 16 бит, а вот, например, 4. Они дают нам 16 различных уровней приоритетов, и, соответственно, оставшиеся биты, 12 бит, дают нам какую-то возможность сделать так, чтобы каждому отдельному виртуальному коммутатору, который мы создаем на физическом коммутаторе, виртуальной вот этой в кавычках машине, мы бы дали уникальный ID. В принципе, случайно так получилось, что Extended System ID, вот это вот поле, которое освобожденное 12 бит от приоритета, оно совпадает по размеру с номером Вилана. То есть туда можно просто тупо номер Вилана вписать. Но это не обязательно означает, что там именно номер Вилана должен быть. Там может быть любое число, которое будет уникальное для конкретного виртуального коммутатора. То есть если вы хотите, вы можете туда вписывать, допустим, номер Вилана плюс 1, или номер Вилана плюс 10, или номер Вилана задан наперед.

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

И мы ему понижаем приоритеты относительно стандартного. Стандартный приоритет, напомню, 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0. И если мы хотим сделать так, чтобы коммутатор стал с большей вероятностью рутом, то мы должны сделать так, чтобы приоритет стал меньше, чтобы вся вот эта левая часть стала в итоге меньше. Но если мы говорим, что мы не можем влиять на вот эту вот штуку, что там у нас будет храниться номер VLAN. Допустим, для VLAN номер один у нас будет число 0,0,0,0,0,0,0,0,0,0,0,0,0,0,1. Это единичка. То, соответственно, мы должны будем вот здесь вот написать что-то, что меньше, чем вот это вот. Это в старшие биты мы записываем некое число. И мы говорим, например, давайте запишем вот такое 0,1,1,0. И, соответственно, у нас получается число 16-ти ричное 0,0,0,0,0,0. То есть вот такой вот bridge ID у нас будет 6,0,0,1, где шестерка – это по факту оставшийся биты приоритета.

Дальше 0,0,1 – это номер VLAN и MAC-адрес, который у нас на железке прописан. В то же время в другом VLAN, в восьмом VLAN, мы номер VLAN записываем, опять же, в Extended System ID. В bridge priority, вот сюда вот, мы вписываем стандартное значение по умолчанию. Это вот как раз 1,0,0,0. И мы получаем в втором дереве bridge ID 8,0,0,2 и дальше MAC-адрес. Это два виртуальных коммутатора, которые работают на одном физическом коммутаторе. На втором свитче у нас абсолютно та же самая история, только инвертированная. Соответственно, в первом дереве мы говорим приоритет 8, во втором дереве приоритет 6. И тогда мы во втором дереве становимся рутом. Левый свитч становится рутом в одном дереве, правый свитч становится рутом в другом дереве. Bridge ID в первом дереве 8,0,0,1, дальше MAC-адрес. Bridge ID во втором дереве 6,0,0,2 и дальше MAC-адрес. Важно понять, что эта схема обратно совместима с обычными Spanning-3шными bridge ID.

То есть после того, как вы bridge ID получили, вот он будет там 6,0,0,1,2,1,1,1. То есть вот эта вот штука, это в принципе обычная нормальная bridge ID. 64 бита, 8 байт, у которого вот эта вот штука будет называться bridge priority, а вот эта вот штука будет называться MAC-адрес. То есть если вдруг вы видите вот этот вот bridge ID, вы не можете утверждать, что он точно и обязательно был сгенерирован по схеме, только левые 4 бита означают приоритет, а все остальное, это на самом деле вот это вот самое extended system ID. Это монолитная штуковина, в которой левые 16 бит означают bridge priority. Просто из них некоторые самые неважные биты были заимствованы для получения уникального идентификатора. Ну и после того, как вы запустили два разных дерева Spanning-3 в такой сети,

соответственно, в каждом дереве у нас выбрался root, в каждом дереве у нас выбираются root порты. И опять же, давайте попробуем выбрать цвета, соответствующие вот этот вот, по-моему, цвет голубенький. Это у нас root. Соответственно, это у нас designated port. Это у нас, соответственно, становится root порт. Ну и в оранжевом, где мне оранжевый взять? Допустим, вот этот оранжевый. Это у нас становится root. Как вот так себе оранжевый. Соответственно, designated port и root порт. В каждом дереве, на каждом физическом порту мы говорим, в каких виртуальных деревьях они участвуют, в каких вот этих самых деревьях Spanning-3 мы говорим, что должны посчитать роль этого порта. И, соответственно, вот у нас один физический порт, но в одном дереве он получает роль designated port, а в другом дереве он получает роль root порт. Это один и тот же физический порт, просто он участвует в двух разных деревьях. Ну и, соответственно, коммутация или отсутствие коммутации на порту в конкомпте конкретно в Вилане,

в случае с PVST, будет осуществляться именно по состоянию роли соответствующего порта. То есть, если мы говорим, что у нас root порт, то, соответственно, он root forwarding. Если мы говорим, что у нас порт, допустим, alternate, то это alternate discarding. И мы коммутацию на соответствующем Вилане в alternate discarding порту не осуществляем. Если говорить про BPDU, которые в PVST будут передаваться, то там все очень просто реализовано. В каждом конкретном Вилане передается отдельная BPDU. И вот здесь у нас пример, когда четыре свеча замкнута в кольцо и четыре VLAN там бегают. Соответственно, VLAN 11, 12, 21 и 22. Да, мы запускаем в каждом Вилане отдельные деревья. В каждом Вилане, в каждом дереве, точнее, мы находим рута. В каждом дереве мы просчитываем роли каждого конкретного порта и говорим, что вот у нас есть, например, вот этот вот свеч.

Он участвует во всех четырех деревьях и в дереве 11, 12, 21, 22. И говорит, что вот у него есть один интерфейс и второй интерфейс. Физические интерфейсы, физические порты, которые смотрят на соседние свечи. И в случае с деревом 11 Вилана мы говорим, вот у нас в 11 Вилане этот порт будет, соответственно, designated. Первый порт. Здесь мы говорим, мы говорим designated, designated порт. А вот здесь вот мы говорим, здесь у нас это же дерево будет, соответственно, alternate порт. То есть, ну, судя по всему... Да, кто бы у нас тут мог такой быть, что мы находимся ближе к руту. Да, ну, предполагается, что у нас есть какой-то еще рут-порт. То есть, ну, наверное, здесь вот где-нибудь у нас рут-порт есть. Да. И такая же история в 12 Вилане. Мы говорим, что у нас вот этот вот интерфейс 1 вот здесь вот на левом свече, он, соответственно, designated.

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

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

Вы не можете посмотреть на Extended System ID, потому что там мы говорили, что может быть схема, например, при которой каждый виртуальный коммутатор в дереве будет получать отдельный свой виртуальный МАК, и, соответственно, в Extended System ID там не будет номера Вилана лежать. Либо просто отправитель будет расставлять эти самые Extended System ID каким-то произвольным образом, например, номер Вилана задом наперед. Поэтому для того, чтобы указывать, в каком Вилане передается каждая конкретная бпдушка, добавляется в хвост бпдушки, помимо того, что там есть, помните, да, заголовок стандартной бпдушки. Это сначала заголовок 5 байт, потом priority vector, потом таймеры. И вот в хвосте фирменных бпдушек циски, помимо всего того, что перечислено, добавляется еще TLV-шка. Тройка type length value, в которую вы добавляете указание, в каком Вилане эта бпдушка была отправлена. То есть помимо того, что у вас в принципе бпдушки 802.1.q будут отправляться с 802.1.q метками, помимо того, что что-то напоминающее номер Вилана чаще всего лежит в Extended System ID, у вас дополнительно номер Вилана прописывается в TLV-шке в самом конце бпдушки.

И это единственное достоверное указание, в каком Вилане бпдушка была отправлена. Бпдушки эти будут модифицироваться. Они будут отправляться на специальный MAC-адрес фирменный цисковский. У них будет не LLC вложение, а LLC плюс SNAP. Поэтому, если вдруг у вас в сети будут какие-то коммутаторы, которые не поддерживают ПВСТ, им будут необходимо отправлять ванильные спаринг-фришные бпдушки, чтобы они поняли, про что идет речь. То есть вы в цисковских свечах CST, классический ванильный спаринг-фришный, не можете выключить. Он всегда есть, всегда работает, если у вас работает ПВСТ. То есть вы включаете ПВСТ, и спаринг-фри дефолтный классический сразу тоже включается. И он будет использовать для вычисления ролей, для вычисления того, какие порты надо заблокировать, разблокировать, базу первого Вилана. То есть он берет дерево первого Вилана ПВСТшного и клонирует это дерево для использования с ванильным спаринг-фри.

Если в первом Вилане вы говорите, что этот порт, какой-то там конкретный порт Ethernet 01, будет рутовым, то вы говорите, окей, значит это рутовый порт и в ванильном дереве тоже. Если вы говорите, что порт в первом Вилане будет, например, designated, и мы фирменные цисковские БПДушки посылаем в этом порту, то мы говорим, окей, значит мы будем посылать и классические БПДушки на этом порту тоже. С таким же root path cost, с таким же root bridge ID, который мы знаем в первом Вилане. Вот. Ну и соответственно, да, в первом Вилане БПДушки, которые будут приходить на ваших портах, они будут влиять на дерево. И классические спаринг-фришные БПДушки, которые будут приходить от соседних свечей, они точно так же будут влиять на ваше дерево первого Вилана. То есть какие БПДушки будут вкуснее, такие вы и будете брать.

Так. Вот, собственно, да, как будут выглядеть БПДушки фирменные цисковские, ПВСТшные. Мак-адрес получателя будет 010000C. Это хорошо заметная ОУИшка циски 0.0.0.0.0.0C, но у которой первый битик, самый младший битик первого байта, выставлен на единичку для того, чтобы показать, что это мультикаст. И вот такой вот CC, CC, CCD, хвостик. Он немножко отличается от CDP, VTP, что там еще у нас было, других фирменных протоколов циски, которые обычно CCCCC используются. Вот для ПВСТ будет использоваться CCCCD. Инкапсуляция LLC и SNAP, то есть LLC говорит, что у нас Destination Service Access Point, Source Service Access Point будет AA. И дальше SNAP вложение указывает на то, что внутри лежит протокол фирменный цисковский, код вложения, не код вложения, а Organization Code 000000C. Что-то напоминает. И тип протокола, протокол ID 010B.

Запоминать не надо, просто как бы заметьте, что вкладываются в кадры Ethernet фирменные цисковские с ПВСТ немножко иначе по сравнению со стандартным спарингтейтом. Поэтому они в принципе несовместимы между собой. Вы не можете отправить ПВСТшную БПДушку и надеяться, что классический ванильный свитч ее поймет. Они отправляются на разные маки, они отправляются с разным типом вложения. Ну и кроме того, у фирменных цисковских БПДушек будет еще хвост. Хвост вот этот вот самый Originating VLAN TLV. И соответственно она будет 6 байт размером. Туда вкладывается 1 байт тип TLV, 1 байт длина и 4 байта... Так, нет, вру. 2 байта тип, 2 байта длина, 6 там будет лежать. И соответственно 2 байта содержимое. Вот VLAN как бы да, у нас 12-битовый идет, поэтому в 2 байта он как раз и влезет.

Всего получается 2 байта здесь, 2 байта тут и 2 байта само содержимое. Получается всего 6 байт. ВПДушки цисковские будут отправляться с метками того VLAN, в котором они выходят. Но соответственно за исключением native VLAN. Если у вас есть VLAN, который указан как native, то есть кадры этого VLAN вы отправляете без метки, то и ВПДушки будут отправляться без метки. Эти ВПДушки не отправляются на коммутацию, то есть в принципе можно было бы эти самые метки 82.1Q не ставить, но вот надо просто запомнить, что в ПВСТ метки расставляются, так же как и в случае, если бы это были боевые кадры, по тем же самым правилам. Но трафик на коммутацию по факту не посылается. Так. Да, и еще одна замечательная особенность у таких кадров, которые будут отправляться с ПВСТшными ПДушками, что у них проставлен приоритет network control.

Если мне память не изменяет, он максимальный по сравнению с любыми другими кадрами, которые вы будете видеть. То есть помните там те же самые биты, которые назывались class of service. Вот. Как раз там вот все единички будут означать, что это очень важный трафик. Если кто-то вдруг будет внимательно читать эти самые биты приоритета, то, соответственно, вот ПВСТшные ППДушки, они будут обрабатываться максимально приоритетно. Так. Так. Что касается настроек на цисках по умолчанию. Начнем, наверное, с таймеров. Таймеры по умолчанию стандартные. Рекомендованные. Hello timer 2 секунды. Forward delay 15 секунд. Max edge 20 секунд. То есть ничего нового. Как по стандарту, так по ПВСТ. Такие же таймеры будут использоваться. Extended system ID на старых свечах не использовался. То есть на старых свечах вы могли встретить ситуацию, при которой на каждый виртуальный коммутатор, который у вас поддерживался на железке,

назначался отдельный маг. И приоритет вы могли выставлять с любой гранулярностью. Вот все 16 бит вам были доступны для редактирования. На новых железках вам приоритет доступен для редактирования только в старших 4 битах. А, соответственно, все остальные биты автоматически заполняются номером VLAN. Ну и метод вычисления стоимости интерфейсов взят из 802.1D 1998 года. То есть это надо будет запомнить, опять же, на экзамене. 119.4.2. Для 10-мегабитного интерфейса, соответственно, будет стоимость 100 копеек. Для 100-мегабитного интерфейса стоимость 19 копеек. Для гигабитного интерфейса 4 копейки. И для 10-гигабитного интерфейса 2 копейки. Вот это вот надо на экзамене будет, опять же, помнить как ученаш. Это не поведение, которое описано в актуальной редакции 802.1D 2004 года.

Это поведение, которое описано как раз в 98-м году. С тех пор оно уже поменялось, но ЦИСКО все еще живет в 98-м году. Плюс к тому, если говорить про, скажем, достаточно недавнее прошлое, по умолчанию на ЦИСКОвских свитчах работал ПВСТ+. Стандарт. То есть вы доставали свитчи с коробки, и там работал медленный фирменный ЦИСКОвский спарнинг 3 ПВСТ+. Начиная с ИОС-15.2.4, режим по умолчанию изменили на Репет ПВСТ. Произошло это буквально года три назад. То есть до 2015 года, 2014-2015, я точно не помню, ЦИСКОвский работало с медленным спарнинг 3 из коробки. Если у вас ИОС более старый, чем вот такой вот 15.2.4, то вы по умолчанию работаете с медленным спарнинг 3. Так, если вы хотите переключить режим работы спарнинг 3, то вы можете использовать команду спарнинг 3, пробел мод, пробел.

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

Во-первых, вы можете поменять бридж-правиль. Из очевидного, если мы хотим в разных деревьях использовать разную топологию То мы хотим выбирать рута по-разному. В одном дереве хотим выбрать рутом один свитч В другом дереве хотим выбрать рутом другой свитч Чаще всего вам это нужно будет в ситуации, когда у вас есть реальная коммутируемая сеть предприятия У вас есть два дистрибьюшена. Дистрибьюшен 1, дистрибьюшен 2 И, соответственно, есть пачка access свитчей, на которых сидят юзеры И вот они там треугольниками соединяются Дальше, в зависимости от того, что у вас за дизайн будет Вы можете сказать, что у вас будет либо loop free access L2 Либо у вас будет looped access И вам тогда нужно будет Spanning 3 здесь использовать Когда у вас есть петли, вот эти вот петли И вам надо с помощью Spanning 3 их разрывать Вот в этой ситуации это называется looped L2 access Access свитчи у вас тупые L2-шные На дистрибьюшенах работает маршрутизация

Но до них Spanning 3 тоже дотягивается И, соответственно, есть петли между access свитчами и дистрибьюшенами Эти петли нужно Spanning 3 разрывать Вот в этой ситуации вы должны будете сказать, что у нас есть пачка виланов В некоторых виланах рутом будет левый дистрибьюшен В некоторых виланах рутом будет правый дистрибьюшен И, соответственно, трафик до тех виланов Пардон, трафик до дистрибьюшен уровня в тех виланах, где рутом выбран левый свитч Будет ходить через левые транки Трафик в тех виланах, где рутом выбран правый свитч Будет ходить через правые транки И у нас получается, что на каждом access свитча Деньги мы заплатили за два провода И по факту задействованы оба два провода Но это предполагает, что мы по-разному назначаем рутов на каждом вилане И мы должны будем играть приоритетами в каждом отдельном вилане Задавать мы можем в случае, если мы используем схему с Extended System ID Только старшие четыре бита приоритета Остальные биты назначаются автоматически с номером вилана

Так, пардон Вот Если вы указываете приоритет в явном виде Вы используете команду Spanning3 Дальше Указываете дерево, с которым вы работаете В случае с PVST Дерево у нас строится отдельно за каждый вилан Например, в первом вилане будет вилан 1 Это опять же дерево, да? 3 И дальше вы указываете ключевое слово Priority И вопросик подсказывает, что здесь можно задать приоритет Если вы используете схему с Extended System ID То вы можете назначить приоритет только с шагом в 4096 копеек В TLV-шке номер вилана указывается Да На самом деле TLV-шка — это единственное место, где номер вилана указывается достоверно То есть, если вы хотите увидеть, за какой вилан отправлена та или иная БПДУшка Единственное место, где вот прям точно написан номер вилана Это вот та самая TLV-шка, потому что в Extended System ID непонятно, что написано Может быть, используется схема с Extended System ID

А может быть, не используется По 64-битам Bridge ID не видно По какой логике этот Bridge ID был составлен То есть, Bridge ID — это просто Bridge ID и все 64 монолитных бита, которые непонятно откуда взялись 802.1 киевшные метки в заголовке кадра тоже не обязательно там будут присутствовать Поэтому TLV-шка — это единственное место, где можно увидеть номер вилана точно, прям гарантированно Так вот, по поводу приоритета Вы можете выставлять приоритет с шагом в 4096 копеек И это не случайно То есть, если вы будете назначать только старшие 4 бита приоритета То эти биты могут иметь следующее значение 0, 0, 0, 0 и потом 12 нулей 0, 0, 0, 1 и потом 12 нулей 0, 0, 1, 0 и потом 12 нулей То есть, вы то, что записывается в Extended System ID не пишете в приоритете Вы эти биты заполняете нулями И поэтому, если вы имеете младшие 12 бит нулевые

Это все равно, что вы возьмете некое число 4 битное и умножите его на 4096 То есть, 0, 0, 0, 0 — это нолик 0, 0, 0, 1 — это единичка 0, 0, 1, 0 — это двойка Двойка Пардон Если вы все это умножаете на 4096 То получается 0, 0, 0, 0 и дальше куча нулей — это 0 Единичка 0, 0, 0, 1 и дальше куча нулей — это 4096 Двойка 0, 0, 1, 0 и дальше куча нулей — это 8192 и так далее И, соответственно, самое старшее значение, которое будет — это число 15 Или битвы 1, 1, 1, 1 и дальше куча нулей Соответственно, умноженное на 4096 Оно дает значение 61, 440 Допустимые значения указываются вот в этой табличке Эту табличку вы можете легко вызвать, попытавшись указать в Sparling 3 VLAN чего-то, Проверите чего-то там С указанием числа, которое не делится на целом 4096

То есть, если вы попытаетесь указать в Sparling 3 VLAN 1 Проверите там 1234 То система скажет Извините, это не число, которое 16-битное, у которого 4 старших бита какие-то кастомные А дальше 12-бит нулевые для того, чтобы туда можно было вписать номер VLAN Вот, и подсказывает, какой допустимый ввод она примет Ну и, соответственно, вы можете сказать Окей, я понял, значит, вот это значение по умолчанию Вот это самое маленькое, которое может быть Вот это самое большое, которое может быть Соответственно, вот любые из вот этих вот значений я могу указать для того, чтобы рутом мой свитч гарантированно Ну, не гарантированно, а с большей вероятностью стал, чем он есть сейчас По умолчанию приоритет 32768 Это 1, 0, 0, 0 Есть рекомендованные значения для того, чтобы вы знали просто эти значения На экзамене они тоже могут понадобиться 32768 это дефолтное значение 1, 0, 0, 0 Циско рекомендует для того коммутатора, который должен стать рутом

Значение 24576 Это значение 0, 1, 1, 0 То есть, если вот это 1, 0, 0, 0, это 16-ти ричное число 8 16-ти ричное То 0, 1, 1, 0, это, соответственно, шестерка 16-ти ричная Почему шестерка, почему не семерка? Дело в том, что семерка рекомендуется для запасного рута То есть, если у вас есть, допустим, вот эта вот петля Два distribution switch и access switch У вас есть тот switch, который должен стать рутом штатно У вас есть тот switch, который рутом не должен стать никогда И у вас есть другой distribution, который не должен становиться рутом по умолчанию Но который больше должен стать рутом, чем любой access switch, который в сети будет находиться Поэтому мы говорим, что у нас приоритет по умолчанию 8000 16-ти ричный будет у нормальных свечей Это дефолтный приоритет, и менять его нет смысла У нас есть приоритет 6000 для distribution switch, который основной рут

6000 16-ти ричная Это 24576 6, 0, 0, 0, 16-ти ричная Это 8, 0, 0, 0, 16-ти ричная И вот это 7, 0, 0, 0, 16-ти ричная Так вот, 6000 это для основного рута 7, 0, 0, 0, это для запасного рута 28672 Это число 16-ти ричная Это число 10-ти ричная Вот, так что стандартное дефолтное значение Вот то, которое ровно посерединке 32768 Десятичная или 8, 0, 0, 0, 16-ти ричная Это дефолт, мы его не трогаем, оно у всех такое Но на двух distribution мы говорим Одному мы сделаем приоритет чуть-чуть получше, чем у всех А другому чуть-чуть посильнее получше, чем у того, который мы только что назначили Поскольку мы назначаем фактически приоритет только в старших 4-х битах Вот мы говорим У всех 8-ка, у запасного рута 7-ка, а у основного, хорошего, самого рута будет 6-ка Это рекомендованные значения для, соответственно, основного рута и запасного рута

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

Вот я перелистнул слайд, и вы, я думаю, что уже забыли, какой именно приоритет должен быть у рута Ну, потому что вот эти вот самые 16-ти ричные значения, да, вы можете помнить, что там 6000 должен быть у рута Но какой он в десятичном виде должен быть, ну, это... никто это не помнит на самом деле Это каждый раз все заходят на циску и говорят, ну, приоритете какое-то там 1, 2, 3, 4 вбивают И смотрят, какие значения будут допустимы Но, если вы хотите, вы можете воспользоваться макросом, который гарантированно сделает ваш свитч рутом Ну, почти гарантированно, скажем Сделает ваш текущий свитч, на котором выполняется этот макрос рутом Делает он очень забавную вещь Вы выполняете команду spawning3, дальше в каком дереве вилан 1 И дальше макрос root primary Делает он следующую штуку Если ваш текущий приоритет рута То есть того свитча, который будет рутом в указанном вилане

Не ваш, именно вашего свитча, где вы это выполняете А приоритет текущего рута в том дереве, в котором вы хотите стать рутом Если приоритет текущего рута 32768 Это означает, что администратор забил болт на настройку spawning3 до сего момента И вот сейчас у вас проснулась совесть и вы начинаете конфигурировать этот самый spawning3 То если рутовый приоритет сейчас по умолчанию То выставляется приоритет ровно 24576 То есть вот эта вот штука это 800016-ричная Вот эта штука это 600016-ричная То есть выставляется рекомендованный приоритет для рута Если у текущего рута другой приоритет То вам выставляется приоритет либо такой же, как у текущего рута Но если это у вас MAC адрес лучше То есть он делает вам такой же приоритет Но с учетом того, что MAC адрес у вас лучше, вы становитесь рутом Либо он выставляет вам приоритет на копеечку меньше Тогда если у вас MAC адрес числового больше, чем у текущего рута

Вы на копеечку проседаете по приоритету Ну и соответственно приоритет плюс MAC адрес у вас становится меньше, чем у текущего рута Поэтому этот макрос вас в один момент делает рутом Ну естественно, что если у текущего рута приоритет был 0000 И Bridge ID целиком был вот такой вот красивый 00000001 Вот превзойти такое вам будет, конечно, очень сложно То есть если вдруг у текущего рута и приоритет 0 и MAC адрес вот такой вот То есть это ксероксовский MAC адрес То ничего с этим не сделаешь, да? Что придется смириться с тем, что вы не станете рутом Но тем не менее, если у вас просто нормальные какие-то разумные адекватные свечи в сети есть То root primary удобный макрос, который ваш коммутатор сразу за одну команду делает рутом Независимо от того, какой рут сейчас есть Если вы хотите назначить запасной рут, то есть макрос Sparling 3 VLAN Дальше дерево, какое-то root secondary

У этого макроса поведение более простое То есть он не смотрит на приоритет текущего рута Не делает вам приоритет в зависимости от текущего рута Либо такой же, либо меньше на единичку Он просто фиксирует всегда 28672 То есть это рекомендованный приоритет для резервного рута И, соответственно, если вы назначаете root secondary Это значит, что root primary Ну, или текущий приоритет основного рута Вы как бы уже тоже сделали Это ваша задача как администратору убедиться Что все это дело согласовано между собой Вы можете выполнить команду root secondary Просто в чистом поле И ваш приоритет будет 28672 И, например, если у всех остальных коммутаторов приоритет по умолчанию Он станет рутом То есть вы прописываете, что root secondary А на самом деле он становится сразу root on Ну, да, жизнь боль Вот Более того, нет никакой гарантии Что после отказа текущего рута

Именно тот коммутатор, где вы выполнили root secondary Обязательно станет root on То есть может быть такое, что у вас у текущего рута приоритет 0.0.0.0 А еще в сети есть 0.0.0.1 0.0.0.2 Ну, какой он там 1.0.0.0 2.0.0 3.0.0 Какие-то другие коммутаторы с приоритетами вот другими И поэтому, когда вам выставляется приоритет 7.0.0.0 Вы на самом деле становитесь запасным рутом На случай отказа только рута Который единственный имеет приоритет больше, чем ваш Ну и опять же, да, вы как администратор должны будете убедиться, что такой коммутатор только один Гарантии того, что вы станете рутом после отказа текущего рута, никакой нету Вот, ну и да, нет гарантии того, что изменение вашего приоритета на 28672 не сделает ваш рутом прямо сейчас Так что он просто прибивает к вам гвоздями приоритет 7000 и все Удобная штука

Если вы настраиваете циски не очень часто, то вот макросы это прям очень круто Так, что еще можно будет здесь понастраивать? Помимо того, что вы можете назначать bridge priority Это то, с какой вероятностью вы станете рутом и с какой вероятностью вы станете designated bridge'ом Будет этот самый bridge priority влиять на это Потому что когда вы отправляете BPDU, вы указываете там и то, кого вы считаете рутом и то, кто, собственно, вы такой Поэтому на самом деле bridge priority важная вещь, даже если вы с рутом не становитесь Потому что, например, если у нас есть текущий рут И, соответственно, есть два коммутатора, которые вот так вот в кольце расположены друг с дружкой И, соответственно, у текущего рута приоритет 6000 А два коммутатора, которые равно удалены от текущего рута, они, соответственно, смотрят на него рут-портами Сам рут на них смотрит designated портами И здесь рут-порт

Два коммутатора должны будут подраться за то, кто заблокирует со своей стороны вот этот вот порт нижний И если мы хотим сказать, что заблокировать должен правый, а не левый Тогда на левом коммутаторе мы должны будем сказать У правого приоритет 8000 дефолтный, а на левом мы делаем приоритет 7000 И тогда левый коммутатор при отправке BPDU, я знаю, как добраться до рута За столько же копеек, как и правый, они будут рассказывать, что могут добраться до рута за одинаковое количество копеек Потому что и тот, и другой, например, за 10 копеек рута видят Дальше они будут мерять со своим Sender Bridge ID И у левого свеча Sender Bridge ID будет лучше, чем у правого И в этой ситуации левый скажет, я ближе к руту, просто потому что у меня Bridge ID меньше, чем у тебя И в этом случае он объявит себя designated портом А второй, соответственно, скажет, да, я вижу, что у меня Sender Bridge ID хуже, чем у тебя Я со своей стороны порт заблокирую и помечу его альтернативным портом Вот, это про Bridge Priority

Но на самом деле у нас есть еще и порт Priority Потому что если вы помните, Priority Vector, он состоит из следующих полей Сначала root Bridge ID, кого мы считаем рутом Здесь все понятно, Bridge ID мы уже умеем им играть за счет приоритетов Потом root Path Cost С root Path Cost, ну, соответственно, надо будет уметь назначать стоимости на интерфейсе Ну, это, опять же, довольно просто и буквально там чуть дальше будет про это рассказ И Sender Bridge ID и Sender Port ID Вот Sender Port ID – это двухбайтовое поле, которым указывается, каким портом мы отправляем BPD-ушку И потом, когда мы получаем такую BPD-ушку, мы еще добавляем Receiving Port ID Тоже, соответственно, каким портом мы получили BPD-ушку И вот в этом вот порядке сравнивается, у кого меньше, тот и прав Сначала одно, потом другое, потом третье, потом четвертое, потом пятое Так вот, Port ID изначально состоял из двух однобайтовых полей Так же, как Bridge ID состоял из двух полей Левые 16-бит, порт Bridge Priority

И правые 48-бит, это был MAC-адрес Ну вот, соответственно, на самых первых свитчах, которые работали со Spanning 3 Предполагалось использовать Port ID, двубайтовое поле, которое состоит из двух однобайтовых полей Port Priority и Port Number Предполагалось, что свитчей с больше, пардон, с больше, чем 256 портами существовать никогда не будет Сегодня мы уже знаем, что это не так, что свитчи с больше, чем 256 портами более чем существуют Но вот на тот момент никто не догадывался, что можно себе такое представить И поэтому сказали, давайте мы все порты, которые есть на свитче, пронумеруем Они получат какой-то номер, и вот мы этот номер будем вписывать Мы этот номер вписываем автоматически на основании того, что у нас есть порт номер 8 Вот мы в младшие биты вписываем номер порта И старшие биты, Port ID, будут выставляться в какое-то дефолтное значение 1.0.0.0.0.0.0.0.0.0.0

Это число 128 Вот, и, соответственно, если вдруг мы захотим поменять приоритет порту То мы можем вот эти старшие биты поменять так же, как мы меняем Bridge Priority Если мы хотим сказать, что у нас есть какой-то более интересный, более приоритетный порт Например, в ситуации, когда у нас есть BPD-ушки, приходящие от одного и того же свитча Он отправляет на BPD-ушку с одинаковым root-bridge-id, с одинаковым root-path-cost, с одинаковым sender-bridge-id Но он говорит, я отправляю BPD-ушку одним портом с номером единичкой, а с другим портом с номером двоечкой И я хочу, чтобы сосед заблокировал порт, на котором приходит BPD-ушка с номером единичкой Хотя это число меньше, чем на другом Но вот в этой ситуации мы можем сказать, окей, тогда здесь мы проставим приоритет, допустим, 6.126.1 А здесь оставим 128.2 Пардон, наоборот, 128.1 и 126.2

И у нас получится, что на нижнем порту у нас целиком порт ID стал меньше за счет того, что мы в порт priority записали число чуть поменьше, чем там изначально было Наверху, как было 128.1, так и отправляется А внизу мы говорим 126.2 То есть старшие 8-бит мы вписали число меньше И итоговое число тоже получилось меньше И поэтому как раз блокироваться будет верхний порт, а не нижний Ну или если, опять же, вот у нас есть сосед, который присылает нам BPD-ушку, одну он посылает А дальше эта BPD-ушка разветвляется на две То есть это хаб, здесь у нас свитч, здесь у нас тоже свитч И мы говорим, что вот у нас BPD-ушка отправляется одна и та же У нее один и тот же root bridge ID, один и тот же rus-post-cost, один и тот же sender bridge ID, даже sender port ID один и тот же Потому что это одна и та же BPD-ушка Просто она приходит в двух разных экземплярах на два наших разных порта И мы хотим сказать, что вот это вот порт номер 1, а вот это порт номер 2

И мы хотим заблокировать порт номер 1, а порт номер 2 оставить разблокированным В этом случае мы говорим, у нас 128.1 это вот порт priority и порт number внизу И нам нужно порт number оставить таким же, как есть сейчас на свитче с большим номером Но порт priority мы говорим 126.2 или 127.2 Мы понизили приоритет порту и тем самым сделали так, что у нас итоговый порт ID стал меньше И, соответственно, в этом случае как раз блокироваться будет порт с меньшим номером Потому что его порт ID целиком больше, чем на другом порту Но, как понятно, да, идея с номерами портов, она немножко провалилась Потому что есть свитчи, которые сильно более объемные, чем 256 Например, какие-то свитчи типа Cisco Nexus 7-тонники 77-18 свитч, на котором можно 16 линейных плат по 48 гигабитных портов каждой сделать

А то еще там можно бывает еще и так называемые фабрики-экстендеры использовать То есть вы можете носовать в такой свитч расширители фабрики, при котором там количество портов будет за несколько тысяч переваливать Поэтому вам придется заимствовать некоторые биты порт priority под расширение номера порта То есть если у вас порты имеют номера не 1-байтовые, а, например, 12-битовые То в этом случае вы можете сказать, окей, 2-байтовое поле порта ID мы делим на две части, но вот таким вот образом Вот это вот порт number и вот 4 бита остаются под порт priority Или если мы говорим, что у нас не хватает даже под это количество бит, мы говорим, ну окей, 2 бита под порт priority и 14 бит под порт number То есть в зависимости от того, какая у вас будет ситуация, вы можете по-разному это делать, но смысл будет примерно такой Что мы 2 байта делим на две части в зависимости от того, какого размера у нас будут номера портов И вот на некотором свитче можно видеть, что у нас есть команда sparing3, port priority И дальше вопросик можно показать и нам показывают, какие приоритеты нам будут доступны

Опять же, если вы здесь попытаетесь вбить какое-то число кривое, оно вам скажет, что такое число вбить нельзя Но можно вбить число с шагом приоритета 64, то есть 0, 64, 128 или 192 Всего 4 возможных варианта Ну как раз это означает, что у нас вот здесь вот 2 битика, куда можно вписать номер, куда можно вписать приоритет конкретного порта И все остальное это будет сам уже номер порта, то есть у нас номер порта 14-битный Можно будет указать, что порт priority у вас целиком для всех деревьев, которые используют этот порт, будет использоваться одинаковый Либо можно поиграть приоритетами в разных деревьях и сказать, что вот на каком-то конкретном дереве приоритет порта у нас будет какой-то вот прям конкретный Сразу вы должны будете понимать, что в реальности вам все эти приоритеты нафиг не упали Потому что, ну, если у вас есть действительно 2 свеча, которые там друг на друга двумя портами смотрят Ну какая разница, какие именно они будут заблокированы, правда?

Что порт priority в последнюю очередь нас будет интересовать, что нас больше всего будет интересовать bridge ID И действительно, вот когда мы CCNA проходили, мы bridge ID смотрели, а про порт ID мы вообще молчали, как рыба об лед Но тем не менее, да, в экзамене это есть И то, что оно так работает, вы, конечно, понимать все-таки будете должны Далее, далее, далее, далее По поводу стоимостей Можно менять стоимость отдельно порта Соответственно, Spanning3 и Cost указывает, что стоимость порта будет такой, которую вы зададите Можно сказать, что стоимость порта будет только в отдельно взятом дереве редактироваться То есть команда Spanning3, дальше указываете дерево и Cost И можно будет сказать, что по умолчанию вы будете использовать разные стоимости Разные методы вычисления стоимостей То есть есть метод, который используется в PVST по умолчанию Это так называемые короткие стоимости, потому что они получаются маленькие, 119.4.2

Либо вы можете переключить их в long и использовать стоимости, которые характерны для 2001 до 2004 года Где мы берем 20 Тбит в секунду и делим на скорость интерфейса То есть если у нас есть 10 Мбитный линк, то, соответственно, у него получается метрика 2 миллиона Если у нас 100 Мбитный линк, то получается 200 тысяч Если у нас Гигабит, то это получается 200 тысяч И, соответственно, 10 Гбит, то 2000 Запоминать вот это вот не обязательно, но 20 Тбит, деленное на скорость, вы все-таки должны понимать Ну и редактируется это SpanningTree PathCostMethod и дальше вы указываете LonglyShort Я так сильно подозреваю, что это не ConfigEv только Это в глобальном конфиге это делается Не на уровне интерфейса, а на уровне всей железки целиком Так, таймеры Той же можно будет поменять Опять же, настраивается это все на уровне отдельного дерева

Вы указываете, что в дереве, допустим, вилана 10, вы хотите поменять какие-то вот конкретные таймеры Можно задать HelloTime, как часто отправлять БПДушки Можно указать ForwardTime, это ForwardDelay И можно указать MaxH Все три таймера будут... ну не все три, ладно, HelloTime будет зависеть от того, как вы сильно хотите напрягать вашу циску И опять же, циски позволяют работать только с целочисленными количествами секунд Поэтому самое маленькое значение, которое вы можете задать, это единичка Ну, в принципе, если вдруг вы хотите полагаться на SpanningTree для блокировки петель Есть смысл переключать HelloTimer в единичку То есть вы тем самым ускоряете работу SpanningTree почти вдвое Дальше, ForwardDelay, ForwardTime Должен будет зависеть от того, какой у вас используется диаметр сети То есть вы должны будете понять, какой самый длинный способ после отказа в каких-то каналах У вас будет добраться от любой точки сети до любой другой

Вот самый-самый-самый длинный, самый кривой способ Посчитайте количество линков, умножьте на HelloTime, прибавьте единичку и получите ForwardTime, ForwardDelay Ну, самое маленькое значение, которое можно задать, 4 И 4 на самом деле довольно опасное значение Потому что если представить себе какую-то типичную ситуацию Где у нас есть два Distribution Switch'а, Distribution 1, Distribution 2 Есть, соответственно, Access Switch, Access 1 Есть какой-то другой Switch, Access 2 И у нас вот такой вот, соответственно, дизайн используется Вот Ну и может случиться так, что у нас здесь откажет один канал Здесь откажет другой канал И у нас получается, как добраться Так, пардон, немножко не так Здесь отказывает так Да, у нас вот так вот Нет, сейчас соображу

Так, трафик идет вот сюда Вот сюда, вот сюда, да Вот так вот заблокируются каналы То есть это не заблокируется, это у нас произойдут какие-то отказы И у нас получится, что трафик между этими двумя свечами ходит вот по такой вот схеме То есть здесь у нас получается три прыжка между свечами Плюс еще какое-то время нужно будет на обработку БПДУшек То есть три прыжка между свечами раз, два, три Плюс единичка Это вот как раз 4 секунды Минимальное значение для Forward Delay у нас можно будет назначить Если у вас где-нибудь есть какой-то более сложный дизайн То есть здесь вот еще какой-нибудь, не знаю, в гирлянде будет Access Switch 3 То, соответственно, это будет увеличивать ваше количество прыжков между свечами И вы должны будете, опять же, посчитать самое большое количество прыжков между двумя С самыми удаленными друг от друга свечами и прибавить еще один прыжок Еще одну секунду на всякий случай И количество прыжков умножить на Hello Timer Ну вот самый маленький таймер, который можно выставить, единица и четверка

Это вот как раз для ситуации, когда у вас вся сеть построена по правильной схеме С дистрибьюшенными аксессами И плюс вы, соответственно, вот для того, чтобы Forward Delay выставить в 4 секунды Должны будете, обязаны будете Hello Timer выставить в 1 секунду И MaxH это сколько времени вы помните BPDU, когда вы ее получаете Ну, на самом деле, вы не то, что помните ее А вы до какого времени будете считать, до какого возраста этой BPDU вы будете досчитывать Когда получаете какую-то BPDU от соседа И опять же, если представить себе, что у вас самая правильная, самая маленькая сеть Которая может быть в природе посчитана по вот такой классической Построена по классической формуле У вас между двумя свечами может быть 3 прыжка И вы говорите, окей, допустим, представим себе, что вот этот вот нижний свитч будет рутом От него будет BPDU уходить Раз, два и три То есть до свитча A2 BPDU будет доходить с указанием MessageH 3 секунды То есть вот здесь вот MessageHage будет 3 секунды

И, соответственно, если мы хотим сказать, что вот у нас все было хорошо со свечом А потом BPDU от него приходить перестали То мы должны будем потерпеть, но хотя бы две BPDU мы должны дать ему право потерять То есть одна BPDU потерянная вообще не считается То, что от одной BPDU не должна происходить смена топологии Это медицинский факт Две BPDU тоже не должны являться показанием для смены топологии А вот три потерянные подряд BPDU уже должны считаться показанием для смены топологии Поэтому мы получаем BPDU с MessageH 3 И дальше мы начинаем считать 4, 5 и 6 Вот если мы три подряд BPDU пропустили при условии, что таймеры у нас минимальные То вот MaxH 6 секунд будет означать, что мы допускаем в самой-самой-самой плохой ситуации Что если вдруг у нас такая вот супер маленькая сеть с самыми маленькими таймерами Которые только можно при себе представить Что вот в этой ситуации, если вдруг перестанут приходить от соседа BPDU, То мы должны будем три подряд BPDU потерять

И по самой последней BPDU, которую мы получили с MessageH 3 Она, соответственно, на три секунды должна устареть Три секунды, которые к нам приходят MessageH Плюс три секунды, которые мы терпим отсутствие BPDU, получается MaxH как раз 6 секунд Так, далее Spanning 3 у нас будет, как уже понятно, строить отдельные экземпляры дерева за каждый VLAN Если мы говорим про фирменную CISCO-Spanning 3 И каждый конкретный экземпляр Spanning 3, каждое конкретное дерево можно будет продиагностировать и посмотреть Команда будет, соответственно, Show Spanning 3 и дальше вы указываете, какое дерево вас интересует Есть, кстати, команда просто Show Spanning 3, она покажет вообще все деревья Но Show Spanning 3 за конкретное дерево покажет вам именно конкретный экземпляр Показывается название экземпляра Вот это вот, это не название VLAN, это название дерева Spanning 3 Покажется, используете ли вы в этом дереве либо фирменный CISCO-овский медленный Spanning 3

Либо фирменный CISCO-овский быстрый Spanning 3, либо MST Вот это вот RSTP, не верьте глазам своим, это PVRST Фирменный CISCO-овский быстрый Spanning 3 Если вам здесь напишут IEEE, еще раз не верьте глазам своим, это PVST Фирменный CISCO-овский медленный Spanning 3 Это невозможно понять, и надо запомнить Дальше в каждом дереве вам показывает блок про то, кто root Что вы про него знаете, кто вы такой и какие интерфейсы входят в это дерево Про root вы получаете его Bridge ID, и он будет состоять из 64-бит И вы знаете, что из этих 64-бит, левый 16-бит это Bridge Priority И правый 48-бит это его MAC-адрес Вы не знаете, как построены левые 16-бит Построены ли они по схеме Extended System ID Или построены ли они как-то еще То есть может быть гипотетически Просто администратор взял и ручками задал вот такой странный приоритет 24 577 копеек

Имел на это полное право Например, в ситуации, когда у него была возможность на каждый виртуальный коммутатор Назначить отдельный MAC-адрес Вот этот вот виртуальный MAC-адрес он назначил в дерево первого VLAN И, соответственно, ручками прописал приоритет 24 577 Не 24 578, не 24 576, а вот именно 24 577 Имел на это полное моральное право и прописал Мы не знаем, откуда взялась эта цифра Мы вот говорим, видим 16-бит, верим ей безусловно Дальше показывается, если вы сами root в этом дереве Фраза This bridge is the root Если вы не root, то показывается, каким интерфейсом вы смотрите до root И какой у вас root pass cost Дальше показываются таймеры, которые к вам приходят в BPDU-шках от root Которые вы по факту используете Вот здесь таймеры по умолчанию 2 секунды, 15 секунд и 20 секунд И дальше показывается блок про вас То есть, что вы собой представляете

Ваш приоритет 24 577 И вы знаете, откуда ваш приоритет взялся Вы его сами составили Это приоритет с использованием схемы Extended System ID То есть, в Extended System ID вы вписали ровно номер VLAN 1 Номер VLAN 1 Номер... Ой, пардон Номер VLAN 1 Номер VLAN 1 Вы могли бы сюда просто что-то другое вписать Но уникальное для каждого VLAN Что может быть более уникальное для каждого VLAN, чем его номер? Дальше вы сказали, что приоритет у нас 16-битный Но номер VLAN 12-битный Поэтому в 4 старших бита мы вписываем рекомендованное значение 0, 1, 1, 0 И у нас получается 24 576 Это число 6, 0, 0, 0, 16-ричное Равняет 24 576 И, соответственно, да Мак-адрес вот он такой же, как у текущего РУТа То есть, это мы сами РУТ и есть

Вот таймеры, которые настроены на нас Если мы РУТ, то они у всех используются То есть мы рассылаем БПДушки И все, кто принимает РУТовые БПДушки Дальше эти таймеры будут рассылать Поэтому, если бы мы РУТом не были Мы бы заимствовали таймеры из БПДушек, которые бы приходили от РУТа А вот если мы сами РУТ, то мы эти БПДушки сами рассылаем И aging time 300 секунд Это время, в течение которого у вас в норме записи в таблице коммутации устаревают Если не приходит трафик из-под этих Мак-адресов То есть это тесно связано с процедурой коммутации Мы говорим, окей, у нас есть какие-то записи в таблице, которые мы замаклернили Но эти записи хранятся там не бесконечно И штатный таймер устаревания Мак-адресов в таблице Это вот как раз 5 минут Ну и дальше показывается по каждому интерфейсу Какая у него роль, какое у него состояние То есть роль это designated Если мы сами посылаем БПДушки Если мы ближе к РУТу, чем все остальные

РУТ, если мы принимаем самую вкусную БПДушку от РУТа на этом интерфейсе Alternate, если мы принимаем вкусную БПДушку Вкуснее, чем мы могли бы сами отправить Но не самую вкусную, не такую вкусную, как на РУТе И backup, если мы получаем на этом порту свою собственную БПДушку TLV можно в Airshark, да, только в Airshark посмотреть Ну сейчас посмотрим Дальше, на каждом интерфейсе показывается стоимость Вот эта вот штука, это порт ID Хорошо видно, что она состоит из двух частей Priority и Number Ну, соответственно, Priority 128 и номер 4 Priority здесь мы вот как раз выставляем На самом деле только старшие там 2 или 3 бит или 4 бита Но показывается нам монолитное 16-битное значение Разбитое на 2 8-битовых поля Вот 128.4, да, это вот конкретно порт ID И дальше показывается тип порта

Point-to-point Это значит, что на этом интерфейсе мы ожидаем видеть соседа Но не больше, чем одного Если это абонентские порты Нам по-хорошему бы надо будет эти порты переключить Сказать, что на этом порту у нас будет только пользователь И никогда соседнего свеча не будет Происходит ли изменение в состоянии портов В ситуации, когда мы меняем таймеры на руте Изменения в смене топологии, по-моему, нет Потому что смена таймеров Это не основание для смены топологии То есть просто рут продолжит рассылать новые БПДУшки С указанием новых таймеров И эти БПДУшки передадутся на все остальные свечи Таймеры из них передадутся на все остальные свечи И они просто заимствуют новые таймеры Замечательно Давайте попробуем понастраивать Spanning Tree Применительно к нашей топологии Если вы помните, у нас есть два провода

Которыми наши свечи соединяются с центральным свечом Core S И в Show CDP Neighbors мы, по идее, эти провода должны будем видеть Show CDP Neighbors Да, вот Core S у нас виден за интерфейсами Ethernet 01 и за Ethernet 03 Если я правильно помню, также у нас один из этих свечей Один из этих интерфейсов, а может быть даже и оба Будут транковыми Show Interfaces Trunk Ethernet 01 у нас транк, потому что на этом интерфейсе мы переводили режим работы SwitchPort Mode Dynamic Desirable И, соответственно, у нас согласовался автоматический транк на этом интерфейсе с центральным свечом По умолчанию на всех свечах DTP работает на всех портах Поэтому на центральном свече я никаких настроек не делал Со стороны свеча 8 я сказал Dynamic Desirable И у нас там транк поджегся Виланы, которые на этом транке разрешены вообще все

Но, соответственно, по факту передаются-то там не все виланы, а только первый и 108 И когда у нас Spanning 3 попытался понять, что с этим транком вообще делать Он сказал, да, у нас Cisco Switch По умолчанию на Cisco Switch мы работаем с фирменным цисковским протоколом Spanning 3 Это PVST на старых EOS и PVRST на новых И вот там по факту только два инстанса будут задействовать Ethernet 01 транк Это инстанс Вилана 1 и инстанс Вилана 108, то есть два дерева У нас этот порт будет участвовать в двух деревьях Если мы захотим посмотреть на то, какие у нас есть деревья в Spanning 3 Как он у нас вообще глобально настроен Для этого есть команда showspanning3.summary Она покажет, что вот у нас за экземпляры есть Вот в нашем случае два Вилана Вилан 1 и Вилан 108 Ну и кратенько рассказывают про то, что у нас здесь присутствует

Показывается, что Switch наш в режиме медленного Spanning 3 PVST Показывается Да, в каждом из деревьев, какие у нас есть порты с какими ролями То есть всего у нас в первом Вилане есть три порта И в 108 Вилане у нас два порта Немножко странно может показаться поначалу, что эти номера портов суммируются То есть всего-то железных портов у нас на железке только четыре И Ethernet 0, 0, 1, 0, 2, 0, 3 Но некоторые из этих портов, соответственно, транки Некоторые аксессы в разных Виланах Поэтому, да, вот показывается Сколько портов всего участвует в первом Вилане Сколько портов всего участвует во втором, там, в 108 Вилане И зачем-то это все дело суммируется Вот суммируется оно не просто так Дело в том, что у вас каждый порт, который участвует в каком-то дереве Он расценивается как отдельная сущность То есть то, что у вас Ethernet 0, 1 порт участвует и в первом Вилане, и в 108 Вилане

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

То есть количество портов физических на железке-то оно у вас фиксированное А вот количество Виланов и, как следствие, количество виртуальных портов Оно у вас варьируется Если Виланов слишком много, то и виртуальных портов тоже становится слишком много И это повод уйти от фирменного цисковского ПВСТ в сторону, например, МСТ Где вы можете регулировать количество деревьев И оно напрямую с количеством Виланов связано не будет Но в нашем случае у нас всего 5 портов Так что проблем здесь у нас нет Если мы захотим посмотреть на поведение экземпляра Вилана 1 Мы можем сказать А ну-ка покажи нам showVilan ID Show, простите, Spanning 3 Vilan и дальше номер Вилана, который нас интересует На самом деле нас не номер Вилана интересует А нас интересует идентификатор дерева И дерево у нас как раз называется Vilan 1 То есть мы просим отобразить дерево с идентификатором Vilan 1 И мы видим, что у нас есть это самое дерево Spanning 3 Enabled Protocol EEEE

Не верьте глазам своим, никакого там EEEE-шного Spanning 3 нету Это медленный Spanning 3 Вот, показывается приоритет текущего рута Показывается MAC-адрес текущего рута Мы знаем, кто это, потому что к нам приходит Bridge ID рута в каждой ПДУшке, которую мы получаем Показывается, сколько стоит добраться до рута Rout Path Cost 200 эффективная стоимость, как добраться до рута на этом свитче Rout Port это Ethernet 0.1 И, соответственно, таймеры, которые мы получаем от рута, это вот какие-то конкретные Дальше показывается, кто мы Вот, Bridge ID показывается, что наш приоритет 32 769 И в отличие от вот этого 32 769, который непонятно откуда взялся Вот этот 32 769, мы абсолютно точно можем сказать, откуда он взялся Потому что мы его придумали, это наш собственный Bridge ID Мы его сами породили, и мы его породили 4 битами Дефолтными 16, одним из 16 значений приоритета

И дальше номер VLAN Ну, в нашем случае, да, номер VLAN единичка Extended System ID мы единичку тоже записываем Вот, таймеры, которые у нас настроены, но которые мы по факту не используем Вот такие И дальше показываются порты, которые входят в дерево первого VLAN Поскольку в нашем случае именно мой Switch, Switch 0.8, не является рутом То я вижу два порта, на которых приходят BPD-ушки от рута И, соответственно, это все приходит от центрального свеча И один из портов у меня помечен как рутовый А другой помечен как альтернаит Вот на обоих них я получаю BPD-ушки Один из них более выгодный я помечаю как рутовый Другой из них я помечаю как менее выгодный И это будет альтернаит-порт, запасной рут В колонке STS показывается статус То есть фарвардинг или блокинг в нашем случае Стоимость 100 копеечек Действительно, на 10-мегабитном интерфейсе стоимость должна быть 100 копеек

То есть 119.4.2 стоимостью по умолчанию здесь вы как раз и видите Порт ID на каждом порту показывается два значения 128.2 Это на самом деле двухбайтовое монолитное число У которого некоторые левые биты означают приоритет Мы не знаем заранее какие И правые биты означают номер порта Ну, здесь просто двухбайтовое число показывается в виде двух однобайтовых значений, разделенных точкой Ну и тип порта Point-to-point указывает на то, что на этом интерфейсе мы ожидаем не больше одного соседа Потому что у нас наши свечи соединены прямыми проводами То же самое можно увидеть в 108-м Вилане Там, я думаю, что не сильно что-то будет отличаться От нашего вот этого поведения Поэтому там примерно та же самая картинка и будет Ну, можно заказать Вилан, допустим, 108-й Здесь у нас этот Вилан передается в Trunk И передается в том аксессовом порту, который Ethernet 0.0 смотрит на наш роутер Два порта В обоих них мы не получаем WPD-ушки

Поэтому мы root Вот И, соответственно, оба порта, которые у нас есть, у нас designated forwarding Давайте сделаем так, чтобы у нас появились Виланы Какие-то общие для вообще всех Ну, то есть понятно, что у нас есть первый Вилан, в котором вообще все узлы у нас присутствуют Давайте сделаем так, чтобы у нас появились все остальные Виланы в том числе Все остальные – это вот это 101, 102, 103 и так далее Давайте пропишем наличие этих самых Виланов ConfT VLAN 101-100 Давайте про запас 108 И выхожу Таким вот нехитрым образом можно создать сразу диапазон Виланов со 101 по 108 Я предлагаю вам именно это и сделать, чтобы у нас на всех свечах появились эти Виланы И главное это надо сделать на центральном свече Enable ConfT Виланы 101-108

Выхожу После того, как у нас порождаются новые Виланы, у нас запускается пересчет топологии И Show Sparning 3 VLAN 108 должен сейчас показать нам, что у нас что-то должно изменяться Вилан 101 Да, вот показывается, что есть у нас Есть у нас экземпляр Вилана 101-го И в этом Вилане мы держим один порт Ethernet 01 Прямо сейчас показывается, что мы root за этот Вилан Потому что, видимо, еще не успел прочихаться центральный свеч Так, я там вышел из конфига Вышел Интересно Ну ладно, в общем, сейчас он прочихается

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

И у нас есть какие-то порты, которые в первый Вилан входят Если мы начинаем взаимодействовать с какими-то свечами Не с помощью ПВСТ, а с помощью классического ванильного Sparning 3 То кадры, отправляемые классического ванильного Sparning 3 Они будут иметь в себе вектор, priority vector Который берется из первого Вилана Соответственно, мы на одном и том же порту будем отправлять И БПДушки первого Вилана ПВСТшные И БПДушки классические ванильные Которые к Вилану не привязаны вовсе И, соответственно, мы будем кодировать эти БПДушки по-разному Будут вкладываться в Ethernet они по-разному Но вектор, priority vector у них будет одинаковый RootBridgeID у нас будет тоже одинаковый CenterBridgeID будет одинаковый В общем, содержимое, мясо этих БПДушек будет одинаковое Ну и вот можно будет посмотреть на то Что здесь будет по факту передаваться Как раз с помощью, например, того же Wireshark Давайте поглядим на Wireshark Посмотрим на то, как там что-то передается

Вот у нас есть Wireshark, который ловит данные на моем Ethernet 0.1 И, соответственно, я вижу, что здесь, среди прочего, бегает вот куча всякого Sparning 3-шного барахла Давайте остановлюсь И посмотрим на какую-нибудь Sparning 3-шную БПДушку Во-первых, если посмотреть на Sparning 3, который у нас здесь бегает Видно, что вот это, например, БПДушка, которую я выделил Это БПДушка, которая вкладывается в Ethernet с использованием LLC-заголовка И у нее как раз Source Service Access Point и Destination Service Access Point Это стандартный Sparning 3 БПДУ Соответственно, 0x42 Это означает, что это ванильный БПДУ И вот здесь Sparning 3 протокол указывает на то, что мы здесь будем видеть Показывается протокол Identifier все нули Протокол Version Identifier Sparning 3 0 Это медленный Sparning 3 Дальше это Configuration БПДушка Просто обычная нормальная БПДушка RootBridgeID

Ну вот какой-то вот приоритет 32768 Возможно номер VLAN 108 И дальше отправляется MAC-адрес RootBridgeID RootPathCost Как добраться до Root Сколько стоит добраться до Root BridgeID Кто это послал И дальше PortIdentifier Каким портом он это послал 8.0.0.8 Это означает, что номер порта 8 И вот эта вот старшая восьмерка Это как раз дефолтное значение PortPriority MessageH То есть мы отправили БПДушку И мы говорим, что вот у этой БПДушки Прямо сейчас возраст 1 секунда MaxH Таймер, который отправляется от Root Всем остальным Говорит, что вот эта БПДушка Должна протухнуть через 20 секунд После того, как ее Root отправил И вот 1 секунда уже от этой протухшести прошла И каждый раз, когда информация про Root Будет передаваться все дальше и дальше и дальше MessageH будет увеличиваться на единичку HelloTimer 2 секунды

ForwardDelay 15 секунд То есть вот содержимое здесь все довольно простое Дальше хочется посмотреть на фирменную цисковскую БПДушку Есть у нас здесь такая PVST Так Так Так Так Что-то как-то все не то, что я хочу Сейчас, секунду, соображу, как это сделать Давайте выполним команду На центральном свече и на наших всех маленьких свечах ConvT Spanning3 Modia

И здесь мы укажем RapidPVST Переключаем нашу циску в быстрый режим Я надеюсь, что ей это как-то поможет Потому что то, что сейчас там я видел, этого быть не должно Spanning3 ModrapedPVST И смотрим на то, что в итоге получится Опять же запускаем Varshark Да, проблема была в следующем Проблема была в том, что у нас был динамически согласованный транк И наш эмулятор некорректно понимал, что это такое На железных свечах вы такую штуку не словите Это именно замута этого эмулятора Причем я перебрал несколько версий эмулятора Они ведут себя одинаково Если у вас транк автосогласованный с помощью Dynamic Desirable И они согласуют ISL транк То там вот Spanning3 начинает отправлять Ну, как бы делать вид, что отправлять кадры неправильные Он отправляет кадры типа стандартного Spanning3 Но при этом он помечает их, как будто это кадры определенного Вилана

То есть если взять и переключить Spanning3 Не Spanning3, а Switchport Trunk and Capsulation.DattingQ Switchport Mode Trunk, то начинают отправляться уже нормальные кадры Такие, какие и должны быть И вот PVST-шные BPDU-шки Они идут не на тот самый Mac, который мы видели до того Давайте отмотаю немножко назад Там как раз где происходит граница между отправкой одних и других кадров Вот, предыдущая BPDU-шка отправлялась еще стандартная У нее destination MAC-адрес 0180C2000 Это хорошо известный адрес мультикастовый для Spanning3 Ну, для других протоколов и ЕЕшных Дальше идет указание того, сколько содержимого передается И если у нас указывается длина, то в трактовке длины дальше должен идти заголовок LLC В заголовке LLC в стандартной BPDU-шке идет 0.42.0.42 Что это Spanning3 отправляет другому Spanning3 Control Word, контрольное слово 0.3, всегда 0.3, там безусловные

И дальше внутри уже сам Spanning3 передает свою BPDU-шку Стандартная BPDU-шка без каких-либо TLV-шек, без ничего Просто BPDU-шки и все Дальше я переключил Switchport Trunk and Capsulation.DattingQ Switchport Mode Trunk И Trunk переключился по-честному в режим Trunk Уже не автосогласованный, а жестко прибитый гвоздями И, соответственно, у нас переключился режим работы порта И мы начали отправлять BPDU-шки фирменные, цисковские То, как они должны быть То есть вот это, это ошибка, такого быть не должно Вот это, это нормальное, то, которое и должно быть И на уровне Ethernet-а MAC-адрес, куда оно идет Не 0108C2, а 010000C, CCCCD Внутри идет метка 802.1Q, которая не была в предыдущем случае Соответственно, кадры, которым отправляются, маркируются 802.1Q-шным заголовком Мы указываем, какой VLAN там будет Но мы ожидаем, что не во всех кадрах обязательно у вас будет этот самый

Как называется Обязательно 802.1Q присутствовать в заголовок Потому что может быть такое, что вы отправляете кадр в Native VLAN Если кадр идет в Native VLAN Вот, например, следующая штука Следующая ПВСТ-шная VPDU-шка Она идет за первый VLAN, который у нас Native И здесь 802.1Q-шной метки нету Ну вот, если 802.1Q-шная метка есть, то она присутствует Дальше идет указание того, чего внутри лежит Внутри лежит у нас длина 50 байт То есть дальше идет LLC-шный заголовок В LLC не 042.042, а 0AA То есть это snap вложение Дальше после LLC-шного вложения, который указывает на то, что дальше идет snap заголовок Указание того, что за компания произвела BPDU-шку Произвела протокол, который отправил эту BPDU-шку 0.0.0.0.0.0.C Хорошо известное значение для CISC И, соответственно, дальше указание на то, что за протокол передается

0.1.0.B Это P-V-S-T+. Дальше, соответственно, у нас передаются сами вот спанинг-тришные BPDU-шки Кстати, мне пришло в голову, да, когда мы видели вот это вот Я понял, почему мы вот здесь видели Дело в том, что в ASL не было этой самой TLV-шки То есть ASL-овские BPDU-шки и 802.1Q-шные BPDU-шки Различались как раз наличием вот этой вот самой метки TLV Которую мы сейчас не видели, но которую сейчас обязательно дальше посмотрим В ASL-овских BPDU-шках у вас в каждом кадре был надежный указатель на VLAN Не могло быть такого, что вы отправляете ASL-овский кадр, содержащий BPDU-шку И в нем непонятно, к какому VLAN-у оно относится ASL-овские кадры обязаны были быть промаркированы VLAN-ом Соответственно, если бы мы видели кадр, который приходил в ASL-овском транке

То мы бы вот действительно вот такой вот и видели, который здесь показывается Фишка в том, что этот эмулятор не умеет заворачивать боевые данные в ASL-овский транк То есть он здесь не показывает содержимое ASL-овского заголовка Он там есть на самом деле, но он здесь не показывается И посмотреть ASL-овский заголовок можно, например, только если... DTP, где у нас есть? DTP, отдайся ASL Замет Так ASL так сможет? Вот, ASL-овский заголовок, да Мы его можем на DTP посмотреть Там, соответственно, MAC-адрес получателя Мультикастовый MAC ASL-овский MAC-адрес источника Это отправитель Тот, который... тот свитч, который придумал метку ASL-овскую Придумал заголовок ASL-овский Он себя там указывает А свитч получателя, который получит такое кадро маркированное

Он этот заголовок срежет и никому больше не покажет И потом, если надо будет отправить эти данные в другой ASL-овский транк Он заново нарисует новый ASL-овский заголовок Заново проставит себя в качестве отправителя этого ASL-овского кадра Ну и, соответственно, это будет уже другой кадр Вот Ну так вот, возвращаемся к нашим баранам Где у нас PVST-плюс? PVST-плюс Нет, так не умеет Так, вот PVST-шный кадр У нас есть метка 800-2.1.q Но в ней не обязательно будет указан номер VLAN Дело в том, что если у вас будет native VLAN То, соответственно, могут быть кадры, в которых метки VLAN не будет Поэтому к стандартной BPD-шке добавляется вот эта вот штучка Эта штучка — это как раз метка TLV с указанием номера VLAN PVST-просто и PVST-плюс отличаются именно наличием вот этой вот фиговинки

Указанием заведомо правильного номера VLAN PVST-плюс фактически использовал стандартные заголовки Стандартное содержимое BPD-ушек Просто отправлял их немножко по-хитрому завернутые в ASL-заголовок Так, дальше Протокол Identifier Вот мы переключили его в быстрый режим Соответственно, протокол Identifier у нас остался Spanning 3 Но режим быстрый указывает на то, что версия протокола изменилась Стал Rapid Spanning 3 версии 2 BPD-ушка типа 2 То есть это просто BPD-ушка, не Topology Change Notification, не Configuration BPD-у А единственная неповторимая BPD-ушка, которая есть в быстром Spanning 3 BPD-ушка отправляется с флагами То есть мы не сообщаем о том, что мы подтверждаем смену топологии Мы не соглашаемся на какие-то другие какие-то пропозалы, которые к нам присылаются

Но мы посылаем пропозалы, говорим, мы хотим стать диссигнит-портом на этом порту Не возражает ли кто-нибудь? Ну и, соответственно, мы пока не ведем Learning, мы не ведем Forwarding Мы пока что находимся в Listening режиме на этом порту Ну, то есть аналог Listening режима Вот, ну тут дальше RootBridgeID, RootPathCost, SenderBridgeID, SenderPortID Таймеры, MessageH, MaxH, HelloTime, ForwardDelay Вот как-то так А то есть видно хорошо, что PVST-плюсовская BPD-ушка от стандартной или от ASL-овской BPD-ушки отличается, ну, в общем, заметно Заметно отличается по, во-первых, заголовку, по тому, как оно вкладывается в Ethernet И заметно отличается по как раз вот этому вот самому Originating VLANID Так, это что касается BPD-ушек наших

Вот, содержимое их довольно простое Вы должны будете его знать То есть я вам говорил, да, что вот некоторые протоколы вы не должны знать, как отче наш А вот некоторые протоколы вы должны будете знать Вот, по крайней мере, вот эти вот штуки RootBridgeID, RootPathCost, SenderBridgeID, SenderPortID Вы должны будете знать, как отче наш Ну и таймеры, если хотите, тоже можете запомнить Так Давайте попереключаем наши порты Во-первых, в жесткий транк, чтобы там все было по-честному А во-вторых, сделаем так, чтобы мы в своем VLANе стали бы рутом Так, у меня отвалился мой свитч Enable, ConfT Switchport, ModeRank, я думаю, что вы сами пропишите А вот дальше Do, Show, Spanning, 3, Summary Какие у нас есть VLANы И вот у нас есть VLAN, допустим, 108, 107, 106, 105, 101 и так далее

То есть у каждого из нас есть свой собственный VLAN, который мы можем использовать И я предлагаю как раз это и сделать Сделать следующую вещь Чтобы мы в своем VLANе, там, какой у вас номер комплекта есть Вот у меня 8-й комплект, поэтому я 108 VLAN возьму И я в этом VLANе стану рутом ConfT Spanning 3 VLAN 108 Root Primary Поскольку текущий приоритет рута дефолтный 32768 плюс возможный Extended System ID То этот макрос делает следующее Он выставляет мне приоритет 24576 Show, Show, Spanning 3 VLAN 108 И вот действительно я стал рутом Действительно текущий приоритет рута 24684 Это 24576 плюс номер VLAN 108

Таймеры, которые мы используем, это наши собственные таймеры 2 на 15, на 20 И два порта у нас в этом VLANе присутствуют То есть один порт аксессовый, другой порт ранковый И оба порта, поскольку мы root, будут designated На центральном свече я сейчас поставлю Стать рутом за первый VLAN ConfT Interface Spanning 3 VLAN 1 Root Primary И соответственно на маленьком свече Мы посмотрим, что у нас стало с первым VLANом Сейчас как раз у нас очень интересное состояние Потому что идет пересогласование топологии Я сейчас на именно этом эмуляторе поставил типы портов Shared Link Я пока траблшутил проблему с типом BPDU Я там поставил более старую версию И там он использует half-duplex по умолчанию Соответственно вот у вас в типе портов будет point-to-point

И соответственно там используются все ускорения быстрого Spanning 3 Которые есть И поэтому они быстро выбираются Быстро выбираются designated порты Быстро разблокируются все Поэтому там вы вот это вот состояние возможно не заметите А у меня типы среды Shared Link И как следствие я не работаю со всеми ускорениями Я не использую всякие пропозлы агрименты И соответственно я обнаружил, что случилась смена топологии Я вижу, что в первом вилане root изменился Соответственно мы начинаем смену топологии Мы флажим все маки И мы блокируем коммутацию на всех портах И вот здесь вот я вижу, что на Ethernet 0.1 и на Ethernet 0.3 приходят BPDU от root И помимо всего прочего Соответственно одна из этих BPDU будет вкусной, а другая нет Поэтому root порт мы переводим в root forwarding Запасной root порт мы переводим в alternate blocking А на Ethernet 0.2 мы говорим У нас на этом порту никто нам не отвечает Мы отправляем туда BPDU и мы переводим этот порт сначала в designated discarding

Потом в designated learning И каждый раз мы forward delay timer 15 секунд ждем Чтобы кто-нибудь нам там что-нибудь возразил Но поскольку никто не возразит То мы через некоторое время переведем этот порт в designated forwarding Но вот прямо сейчас это designated blocking Вот сейчас он перешел в designated forwarding Еще там промежуточное состояние был designated learning То есть это как раз первый таймер forward delay мы подождали Потом второй таймер forward delay это designated learning И наконец после того, как мы в течение 30 секунд не обнаружили никакого соседа Который возражает что-то, что мы хотим стать designated Мы переводим этот порт в designated forwarding Если вы хотите поменять приоритеты ручками Никаких проблем ConfT Spanning3 Milan108 Route Не Route, а Priority И дальше вы указываете приоритет Вот если я захочу какой-нибудь кривой приоритет указать Укажутся допустимые значения приоритета

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

Здесь можно посмотреть на Так Спанинг Спанинг 3 Вот здесь можно посмотреть на то, что можно поиграть со стоимостью линка Можно поменять линк тайп, но про это мы будем говорить дальше И можно поменять приоритет порта То есть если вдруг мы захотим на уровне порта поменять приоритет Сказать, что при прочих равных Либо бпдушки отправляемые с этого интерфейса Должны быть более вкусными, чем наша же бпдушка отправляемая с другого интерфейса Либо если мы принимаем одну и ту же бпдушку от соседа Который раздваивается, например, через транзитный свитч Который не поддерживается по некоторой Либо через хаб Ну то, соответственно, какой порт мы должны будем блокировать Будет блокироваться тот порт, у которого порт ID будет больше Ну и вот мы можем на порт ID повлиять, поменяв его старшие биты Опять же, если мы будем порт priority выставлять

То мы это делаем с шагом Вот на наших свитчах меняется с шагом в 64 Если я поставлю здесь какое-то значение кривое Он скажет, поменяй, пожалуйста, либо на 0, либо на 64, либо на 128, либо на 192 Вот такая вот история Ну давайте порт priority, может, поменяем У нас же там есть 108 бпдушка, кажется Так, интересно, где я только это ловлю? Я хотел в Airshark посмотреть, но я забыл, на каком порту я в Airshark запустил Так Что еще можно сделать? Про порты поговорили, про приоритеты поговорили В общем, все Запомните, пожалуйста, на экзамене алгоритм

Это root bridge ID, root pass cost, sender bridge ID, sender port ID, receiving port ID Если вы вот это вот помните, то это будет серебряная пуля для всех вопросов про спанинг 3 Почему спанинг 3 выбрал такой порт рутовым, такой порт для сигнета Только потому, что он сравнил бпдушки, посмотрел, какая из них superior, какая inferior И сделал он это по алгоритму Root bridge ID, root pass cost, sender bridge ID, sender port ID, receiving port ID У кого меньше, тот и прав Так Ну что Наверное, на этом базовый модуль про цисковский спанинг 3 можно считать завершенным