Протокол STP - роли портов

Привет, коллеги! В этом видео мы обсудим тему короткую, но достаточно важную. Это роли портов в Rapid Spanning 3. Rapid Spanning 3, в общем, известен как 802.1.w, потому что им занималась рабочая группа 802.1.w. Но, в конце концов, он вошел в стандарт 802.1.d. Поэтому мы будем Rapid Spanning 3 называть 802.1.d. 1998. Это год, в котором Rapid Spanning 3 вошел в 802.1.d. стандарт. Что касается этих самых ролей, их всего 4 штуки. Первая роль — это root-порт, вторая — это designated-порт, третья — alternate-порт и четвертая — backup-порт. Начнем с первой. А самая первая роль, которая у нас есть, это root-порт. И здесь все просто. Root-порт будет назначаться на коммутаторе тот порт, на котором получена самая выгодная WPD-ушка. Я предполагаю, что процесс получения WPD-ушек, процесс определения того, какая WPD-ушка более выгодная, какая менее выгодная, вы уже знаете после предыдущих видео. Корневой порт — это тот порт, на котором WPD-ушка получается.

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

На самом деле определяются как раз роли. Самый важный вопрос, который должен получить ответ перед тем, как мы сможем включить коммутацию на интерфейсе, это то, будет ли порт десигнат портом или не будет. Вот если у нас порт объявлен root-ом, то есть кто-то нам прислал WPD-ушку на этом интерфейсе, и мы получили ее и сказали, о, эта WPD-ушка лучше, чем та, которую мы могли отправить, значит наш порт не будет десигнат портом. Это мы точно знаем, что никогда ни при каких обстоятельствах наш порт десигнат портом не будет. Поэтому на этом интерфейсе мы можем, если мы знаем, что WPD-ушка вот именно эта самая выгодная приходит, мы можем сразу разблокировать коммутацию. То есть если вот мы знаем, что никто никогда ни при каких обстоятельствах другую самую выгодную WPD-ушку нам не пришлет. На любом коммутаторе, естественно, не может быть несколько этих самых корневых портов, потому что по определению корневой порт это тот, на котором получена одна самая выгодная WPD-ушка. И не может быть два порта, на которых получены самые выгодные WPD-ушки. WPD-ушки различаются как минимум в части sender bridge ID или sender port ID.

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

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

да, он будет смотреть на нас с designated port, а мы на него будем смотреть, соответственно, alternate портом. Alternate портов на коммутаторе может быть много. То есть, если у вас 10 коммутаторов присылают вам WPD-ушки на 10 разных интерфейсов с криками «Я могу добраться до root», они на вас смотрят достигнутыми портами, а вы на них смотрите, ну, соответственно, почти на всех alternate портами, ну, кроме как на одного, который будет выбран самым-самым крутым. Вот самый-самый крутой порт разблокируется, все остальные недо самые крутые порты, они будут заблокированы. На картинке у нас есть пример. У нас есть 4 коммутатора, наши любимые коммутаторы, соединенные в кольцо. Итак, на картинке у нас есть несколько коммутаторов. Самый левый коммутатор — это root. У него root pass cost 0. Он самый близкий к root из всех участников, которые только есть. Никого ближе к root, чем сам root, не будет. У нас есть один коммутатор, который на root смотрит достаточно неплохо. То есть, к нему приходит BPD-ушка, у которой стоимость будет 10 копеечек. Там в ней написано 0, плюс 10 копеек, получается всего 10.

И больше ниоткуда BPD-ушки не приходят. Как вы помните из предыдущего ролика, те коммутаторы, которые находятся дальше от root, чем вы сами, соответственно, вам BPD-ушки не посылают. Поэтому других BPD-ушек здесь нет. Порт, которым вы будете посылать с верхнего коммутатора на правый, он будет, соответственно, десигнать этот порт. Ну, здесь не помечен, но на самом деле он так и будет. И BPD-ушка, которая будет уходить, будет иметь стоимость 10 копеечек. Плюс 10 копеек, которые стоимость интерфейса правый коммутатор будет видеть. Соответственно, приходит BPD-ушка на правый коммутатор со стоимостью 20 копеечек. Root-посткост у правого коммутатора 20. Он посылает BPD-ушки с указанием «Я знаю, как добраться до ROOTA за 20 копеек». Плюс 10 копеек стоимость интерфейса. Правый коммутатор присылает нам BPD-ушку. Средний нижний коммутатор видит такую BPD-ушку и говорит «Я знаю, как добраться до ROOTA за 30 копеек». То, что я могу также добраться до ROOTA за 50 копеек, то что здесь вот еще приходит BPD-ушка от настоящего ROOTA, но она стоит очень дорого.

Здесь 50 копеек получается. Слева приходит BPD-ушка за 50 копеек. Справа приходит за 30 копеек. Вот мы говорим. BPD-ушка, которая за 30 копеек, она круче. Поэтому мы знаем, как добраться до ROOTA за 30 копеек. Порт, на котором мы получили BPD-ушку 30 копеечную, будет ROOTA-ом портом. Порт, на котором мы получили невкусную BPD-ушку за 50 копеек, будет альтернаит-портом. На самом деле у вас в процессе пересчета табологии этот ROOTA-порт может плавать. То есть конкретно в нашем случае у нас нижний коммутатор узнает про существование ROOTA в несколько этапов. Сначала он узнает про то, что ROOTA есть за 50 копеек. Слева приходит BPD-ушка напрямую, поэтому в течение некоторого времени будет приходить BPD-ушка с указанием, как добраться до ROOTA за 50 копеек. И за 10 копеек невкусный правый коммутатор будет тоже присылать BPD-ушку, но нижний коммутатор не будет ее всерьез воспринимать. Поэтому поначалу ROOTA-портом у нас будет левый порт, который смотрит на настоящего ROOTA.

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

На самом деле здесь можно сделать оговорку. Вы можете разблокировать диссигнет-порт в тот момент, когда вы точно уверены, что никто ближе к ROOTA, чем вы, не окажется. На этом будет основано свойство RAPID-SPINING-3. Достаточно быстро пересчитывать топологию, потому что там могут два коммутатора, которые друг на друга смотрят прямым проводом, договориться о том, кто будет диссигнет-портом. И они быстро договариваются, и сразу после этого быстро разблокируют свой диссигнет-порт. Один коммутатор, а второй уже принимает решение, нужно ли блокировать какой-то другой порт, который будет каким-то там либо ROOTA, либо ALTERNATE-портом. Он примет решение уже, что делать. Что касается нашей топологии, у нас есть ROOT. Вот у него все порты диссигнет-порт один, диссигнет-порт другой. Начинается все с того, что все мнят себя ROOTA, и у всех порты диссигнет-порт. Но через некоторое время все коммутаторы перестают себя считать ROOTA. И, соответственно, у них все порты диссигнет-порт уже не будут.

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

designated port будет на правом коммутаторе в сторону нижнего. Designated port посылает впустные BPD-ушки, ответные BPD-ушки root порт в сторону designated уже не посылает. Нет смысла посылать заведомо inferior BPD-у в сторону чужого designated порта. Designated port в каждом сегменте, как вы помните, только один. Это тот самый порт, который находится ближе всего к root. Если два коммутатора с топологической точки зрения одинаково далеко или одинаково близко находятся к root, дальше там уже начинается tie-break по каким-то формальным критериям. Ну, например, у кого sender bridge ID будет меньше, или у кого sender port ID будет меньше, или, наконец, receiving port ID для приходящих BPD-ушек, у кого будет меньше. Но никогда не может быть такого, что два коммутатора в одном и том же сегменте одновременно посчитают себя designated портами и разблокируют эти порты. Потому что если они это сделают, скорее всего, это будет означать петлю. Backup port — это последняя роль, которая у нас будет. Это запасной designated порт. То есть у нас есть root порт, alternate порт, designated порт и backup.

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

один из этих портов будет выбран designated портом, а все остальные — это будут не designated порты, потому что designated порт по определению в сегменте может быть только один. То вот на этом порту коммутацию, во-первых, нужно выключать, а во-вторых, если designated порт сдохнет, то вот этот вот backup порт можно будет снова включить. Это очень экзотическая ситуация, которая возникает тогда, когда вы, например, берете патч-корд и этим патч-кордом замыкаете два порта на коммутаторе. У вас получается петля, которая состоит из портов самого свеча. Вот тогда один из этих портов будет designated, а второй порт будет backup. Он будет заблокирован. Если вдруг designated порт помрет, то тогда backup порт расслабится и включит коммутацию. Он станет designated портом. Это запасной designated порт. Признак того, что порт будет объявлен backup портом, будет очень простой. Если вы на этом порту принимаете свою собственную BPDU, отправленную другим портом, поэтому эта BPDU будет superior по отношению к той,

которую вы сами отправили, тогда на этом порту вы получаете более вкусную BPDU, чем могли бы сами отправить. Поэтому порт designated стать не может. Какой-то другой ваш порт уже designated на этом интерфейсе, на этом сегменте. Поэтому вы такой порт объявляете backup. Backup порт остается заблокированным после пересчета топологии. Вот как это будет выглядеть. У вас есть коммутатор. У него есть два порта, которые смотрят в один и тот же сегмент. Я специально здесь такой кругленький сегмент сделал, чтобы подчеркнуть, что это на самом деле один и тот же провод фактически, одна и та же физическая среда. И у вас есть два порта, и этими двумя портами вы можете одновременно даже попытаться отправить какие-то BPDU. В одном случае вы отправляете BPDU, и в другом случае отправляете BPDU. У этих BPDU все одинаковое. У них одинаковое root-bridge-id. У них одинаковое root-pass-cost. У них одинаковое sender-bridge-id. И вот только разные у них sender-port-id. Вот если вы на одном интерфейсе отправляете BPDU,

указываете sender-port-id, допустим, первый порт, а на другом вы указываете sender-port-id, второй порт, то тогда BPDU, отправленная первым портом, становится лучше, потому что у нее priority-вектор меньше. Вы отправляете эту BPDU, она доходит до порта бэкапного. Вы говорите на бэкапном порту, что, вы знаете, мы отправили BPDU-ку inferior по сравнению с той, которая была отправлена на ниже на каком-то другом порту. То есть если пришла BPDU-ушка, у которой такой же root-bridge-id, как у нас, такой же root-pass-cost, как у нас, такой же sender-bridge-id, как у нас, но вот только sender-port-id лучше, чем на бэкапном порту, тогда мы этот порт объявляем бэкапным. Еще один забавный момент, связанный с бэкап-портами. Представьте себе, что вы сделали следующую штуку. Взяли коммутатор. Давайте для определенности представим, что это коммутатор Cisco. Вот я его нарисовал, конь C2960. Этот коммутатор вы подключаете одним портом к какому-то самому дешевому коммутатору,

который не поддерживает Spanning 3. Это коммутатор, ну, не знаю, какой-нибудь X-Link. И на этом X-Link коммутаторе вы делаете петлю. Что происходит со Spanning 3? Он у нас есть, подчеркну, только вот здесь. Spanning 3 у нас только на циске. В этом случае вы в момент пересчета топологии отправляете BPDU на этом интерфейсе в сторону такого тупенького свеча. Этот тупенький свеч заворачивает ее в петлю, она у вас проходит по петле, эта BPDU-шка, и отправляется обратно в сторону вашего же порта. Вы получаете ту же самую BPDU-шку, которую вы отправили. Циска ведет себя следующим образом. Она, когда получает BPDU-шку от самого себя на своем порту, она этот порт всегда помечает бэкапным. В стандарте четко написано, что для того, чтобы порт получил роль бэкап, нужно, чтобы BPDU-шка, которая приходила, была бы с таким же SenderBridge ID, как у вас, и она была бы superior. Вот Циска себя ведет немножко не так.

Циска достаточно для того, чтобы перевести порт в бэкап, получение просто BPDU-шки, у которой SenderBridge ID совпадает с тем SenderBridge ID, который у нас есть. Вот в стандарте есть важное слово, вот это вот superior. Циска игнорирует это. Superior просто говорит, если получаем BPDU-шку, которую мы сами отправили, неважно каким портом, неважно лучше, хуже, вот если мы получаем свою собственную BPDU-шку, этот порт помечается как бэкап. Что происходит в таком случае? Вы помечаете порт бэкапом, вы перестаете отправлять BPDU-шки в бэкапный порт, потому что если вам кто-то присылает BPDU-шки лучше, то нет смысла в бэкапный порт посылать BPDU-шки хуже. Вы ждете в течение некоторого времени, ну там MaxH timer, 20 секунд обычно, чтобы вам кто-то перестал присылать BPDU-шки, то что, ну это же вы сами посылали когда-то сами себе BPDU-шки. Вот вы 20 секунд ждете после перевода порта в бэкап, вы перестаете получать свои собственные BPDU-шки, вы расслабляете булки, переводите порт в designated, он у вас, соответственно, начинает посылать трафик,

через некоторое время вы получаете обратно свою собственную BPDU-шку, снова переводите порт в бэкап. То есть у вас порт будет флаппить. designated, бэкап, designated, бэкап, designated, бэкап. После перевода в бэкап вы будете ждать MaxH timer для того, чтобы его пометить designated. После перевода в designated вы будете ждать свою собственную первую BPDU-шку для того, чтобы порт обратно в бэкап перевести. Но вот эта вот петля, которая у нас есть на вот этом маленьком тупеньком коммутаторе, она ресурсы этого коммутатора здорово поджирает. Она, конечно, посылает в сторону вышестоящей CISC много-много-много трафика, но она не все кадры, которые приходят снаружи с CISC, посылает обратно в сторону CISC. Может случиться такая ситуация, что в сторону CISC будут посылаться много-много-много всяких браткастов или анноудий-микастов, но никакие из этих кадров не будут с панинг-трешными BPDU-шками. И тогда, когда у вас мощность матрицы коммутации на вот этом нижнем свече упрется в полку в 100%, вы словите ситуацию, при которой у вас вот эта вот CISC верхняя

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

чтобы вы разобрались с тем, какие роли в Spanning 3 присутствуют. Их у нас, напомню, 4 штуки. RootPort — тот, на котором мы получаем самую выгодную, самую вкусную BPDU-шку. AlternatePort — тот порт, на котором мы получаем чужую BPDU-шку, но она все-таки не самая вкусная. Этих портов может быть много. designated port — тот порт, на котором мы BPDU-шки отправляем. И backup-порт — это тот, на котором мы BPDU-шки не отправляем, хотя, в принципе, могли бы, если бы мы сами себе не мешали. Вот такие вот 4 роли есть в Rapid Spanning 3. И зачем они нужны, мы разберемся в следующей серии, когда проговорим про состояние порта. Какие состояния были в 802.1D 90-го года, какие состояния перешли в 802.1D 98-го года в Rapid Spanning 3. и разберемся, как будет разрешаться или не разрешаться коммутация на портах с теми или иными ролями. А на сегодня все. Спасибо за внимание. Пока-пока.