STP

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

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

То есть с их помощью мы будем управлять поведением коммутации, будем управлять тем, в какие порты коммутаторы не будут посылать копии кадров, для того, чтобы не устраивать негативные эффекты, которые возникают в сетях с петлями. За это как раз будет отвечать протокол Spanning 3. У меня здесь есть мультик. Мультик показывает, что будет, если у нас будет в сети петля, то есть несколько вариантов, как добраться от одной части сети до какой-то другой. Например, вот у нас есть узел А, и, соответственно, он может отправить кадр в сторону коммутатора, и этот кадр попадет в петлю. Давайте посмотрим на этот мультик. У нас отправляется первый кадр на ближайший коммутатор. Дальше этот кадр может разбрасываться по нескольким портам, например, если это Broadcast. Дальше, соответственно, этот кадр тоже начинает отправляться на все остальные порты. Ну, в общем, у нас получается такая классическая петля, что каждый коммутатор разбрасывает копии кадров во все порты, кроме порта источника. Ну, как с Broadcast'ами, это довольно типичное явление. Получается, что если у вас такая вот штука есть, то каждый кадр, который вы отправляете, Broadcast'овый, например, ну или AnonyCast'овый, Multicast'овый, тот самый Boom Traffic, Broadcast'ы, Unicast'ы, AnonyCast'ы и Multicast'овый,

он будет в петле зависать. То есть, если у вас есть полноценная петля, то каждый кадр будет отправляться от узла отправителя и будет дальше разветвляться в одну сторону петлю и в другую сторону петлю. Соответственно, когда у нас это происходит, дальше одна копия кадра, которая отправилась по одной части петли, она будет закручиваться в петле постоянно в одну сторону, а другая будет закручиваться в петлю в другую сторону. И никогда из этой петли оно не выйдет. В Ethernet'е нет механизма типа TTL, который есть в IP, поэтому, соответственно, да, у нас, когда кадр попадает в такую петлю, он обречен крутиться в ней навечно. Ну и, соответственно, за счет того, что у нас одни и те же линки используют множество, одни и те же линки будут использоваться этими самыми зависшими в петле копиями, то у нас получится, что одновременно три проблемы будут влиять на неработоспособность сети.

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

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

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

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

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

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

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

общей шиной коммутации в эзернете штатно не предполагалось и поэтому когда коммутация появилась как костыль она стала вызывать вот проблему три проблемы при возникновении петли автор протокола спарринг 3 это радио перлман женщина она его придумала на самом деле тогда когда еще бреджей в эзернете не появилась она его придумала отдельно от эзернета но потом адаптировала его для работы с эзернетом изначально идея у нее появилась в 1985 году ну и когда в 88 89 году на рынке стали появляться первые бриджи запустилась работа по стандартизации этого протокола по адаптации его к эзернету и и соответственно международный институт электро инженеров и электронщиков включил спанинг 3 в стандарт 802 1d то есть 802 1d это про бриджинг вообще ну то есть фактически про свитчинг и в 90-м году выходит первая версия этого стандарта и там написано что если вы включаете бриджинг обязательно используйте спанинг 3 нельзя включать бриджи без этого самого спанинг 3 как вы знаете сегодня большая

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

определять какие линки формируют петлю и коммутации на этих линка будет блокироваться так что по факту тот путь который пройдет трафик будет ходить по графу который не содержит петли и этот граф без петель называется деревом в случае с английским наименованием мы будем встречать термин спанинг 3 то есть дерево которое распространяется между разными коммутаторами и в русской литературе можно будет встретить термин остовное дерево ну да не могу сказать откуда он взялся но тем не менее термин такой есть стандартная версия спанинг 3 то 802 1d иногда этот 802 1d 90 года называют еще медленным спанинг 3 потому что это действительно протокол неспешный в 90 году традиционная скорость эзернета была 10 мегабит в секунду то есть все более скоростные эзернета они появились более-менее позже а и соответственно всякие вот эти 100 мегабит гигабит и прочее это все уже дела более свежие более новое и

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

возможных петель давайте убедимся что все остальные узлы тоже запустили алгоритм и вот он будет блокировать всю коммутацию до тех пор пока не убедиться что все действительно хорошо и действительно вот 802 1d 90 года он прям очень медленный он может как уже говорилось блокировать коммутацию на достаточно большое время порядка минуты когда стали появляться более быстрые стандарты ethernet а стал более популярным использование изомнета в бизнесе то есть проникновение компьютера в бизнес стало существенно более глубоким и бизнес сказал нам бы надо как-то это ускорить его и соответственно в 98 году начинается разработка 802 1w то есть это набор рекомендаций как можно ускорить спарнинг 3 и соответственно в 2004 году она становится стандартом заменяет медленный спарник 3 то есть старый 802 1d 90 года считается устаревшим протоколом 802 1d 2004 года это более новая версия этого же стандарта там уже есть только рэпид спарник 3

который обратно совместим с классическим и рэпид спарник 3 в большинстве ситуации будет обрабатывать изменения в сети за существенно меньшее время то есть при идеальных условиях рэпид спарник 3 будет работать за единицы ну за десятки миллисекунд единицы мир нет а вот десятки до у вас эти что-то произошло появился появилась какая-то петля и спарник 3 рэпид спарник 3 быстро быстро перестроил сеть для того чтобы подстроиться под новую топологию параллельно с рэпид спарник 3 с 802 1w работал другая комиссия 802 1s эта комиссия которая пыталась адаптировать спарник 3 для ситуации с виланами потому что опять же в 90-м году никаких виланов еще толком не было была концепция свечинга но виланов не было и соответственно стандартный спарник 3 работал за всю физическую топологию он говорил у нас есть линк этот линк смотрят на соседние свечи у нас есть другой линк который смотрит на соседние свечи эти линки сформируют физическую петлю поэтому мы должны эту физическую петлю разорвать там никто не

проверял что возможно в этих линках передается трафик разных виланов и возможно у вас блинки в виланах там один в 10 вилане 2 в 20 то есть формально петли нету логических негативных последствий никаких не возникает но спарник 3 про это ничего не знал и для того чтобы научить спарник 3 понимать про какие виланы идет речь появился стандарт 802 1s ну или на самом деле он потом вошел в стандарт про виланы и соответственно 802 1s 2003 года это тот самый 802 1s который вот заголовки кадров изменяет он соответственно указывает что если вы используете спарник 3 в коммутируемой сети с виланами то спарник 3 у вас должен быть особенный когда циска свои виланы начала делать она их начала делать существенно раньше 2003 года и если говорить про цисковские свечи с виланами опять же да это свечи крещенда который циска

купила порядка в 93 что ли года вот они естественно поддерживали виланы циски очень хотелось чтобы этих виланах спонят 3 все-таки как-то работал чтобы он не блокировал целиком коммутацию а чтобы споник 3 вот на фирменных цисковских свечах с фирменными цисковскими виланами мог блокировать коммутацию только в пределах определенного вилана поэтому циска создала протокол pvst это первый land споник 3 проприетарный расширение протокола 802 1d для работы с отдельными виланами споначал он работал только с крещендов скими транками а если но потом его адаптировали pvst плюс и для 802 1к юшных виланов тоже ну и когда появился репет спарник 3 циск сказал о какой замечательный протокол ну точнее не то что прям это было именно так сначала циска сделала свой первый land rapid споник 3 а потом он стал стандартным фактически да там обратное проникновение было сначала циска сделала быстрый протокол а потом этот протокол стандартизировала

уже под именем 802w и соответственно вот pvrst первилан репет споник 3 это быстрый протокол цисковские для работы с виланами чтобы вы растет что 802 1с он же мастер умеют работать с виланами но делает абсолютно в абсолютно разной манере мы с вами оба варианта будем изучать как работает спарник 3 сначала в каким-то образом все свечи выбирают так называемый корневой коммутатор корневой коммутатор будет называться root bridge root bridge дальше потом все остальные коммутаторы пытаются определить каким образом они расположены по отношению к этому самому руту соответственно в каждом сегменте мы выбираем точку который находится ближе всего крутым мы сейчас не определяем что такое ближе мы просто говорим что вот есть какой-то механизм определения кто ближе кто дальше и этот механизм работает одинаково

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

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

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

Это выделенный коммутатор, который никогда в сегменте свою коммутацию не блокирует И трафик пользователей, который будет ходить в этом сегменте, будет до рута доходить именно через него Каждый раз, когда у вас запускается Spanning 3, вы должны будете определить, где вы находитесь по сравнению с рутом То есть не являетесь ли рутом вы, и, соответственно, если вы не являетесь рутом, то где рут? И для каждого интерфейса вы должны будете определить, соответственно, вы являетесь designated bridge в этом сегменте, в котором вы смотрите интерфейсом, или нет В сегменте по определению может быть только один designated bridge Поэтому, если вы принимаете решение, что вы ближе всего к руту в этом сегменте, то вы designated bridge будете, и вы, соответственно, этот порт объявляете designated портом Вот здесь, например, вы говорите, я здесь на этом интерфейсе ближе всего к руту, и вот здесь ближе всего к руту, а вот здесь не ближе Здесь кто-то другой ближе к руту Я его здесь не нарисовал, но и вот здесь тоже, соответственно, есть кто-то, кто ближе к руту, чем вы

Поэтому здесь вы объявляете себя designated bridge, здесь объявляете, здесь нет, и здесь тоже нет Каким образом это будет происходить, мы сейчас разберем, но смысл будет именно в том, что вы каким-то образом можете это определить вы будете определять где находится root то есть ближе вы круту в каждом порту или не ближе вы круту чем все остальные с помощью такой штуки которая называется порт правил эти вектор то есть она будет определять в каком направлении root на каждом конкретном порту будет здесь вот стрелочка она говорит что мы знаем что root ближе к нам чем кому-либо еще в этом сегменте вот в нижнем поэтому root здесь вот у нас находится и порт правильте вектор указывает что все абоненты подключенные к этому сегменту которые здесь возможно сидят они будут находиться они будут ходить в сторону рота через нас то есть вектор в сторону рота в этом сегменте указывает на нас на десерный этот бридж в этом порту в то же время например вот здесь вот мы говорим что root находится где-то ближе к кому-то

другому поэтому мы здесь не десерный этот бридж и наш порт продолжить и вектор на этом порту указывает такого-то другого то есть вы определяете где root ну стрелочка рисуете в каждом проводят где route если стрелочка указывать на вас то это значит выберите на этот бридж если стрелочку указывать на кого-то еще это кто-то другой десери этот бредж по определению стрелочка указывает только на кого-то одного то есть вы должны будете уметь указывать на коммутатора который ближе всего находится круто в в каждом проводе. Если вам кажется, что два коммутатора находятся одинаково близко к роту, то вы должны будете каким-то образом определить в каждом проводе, соответственно, кто из двух очень похожих друг на друга соседей будет все равно ближе. То есть вам нужно всегда в сторону только одного соседа, в сторону одного соседнего коммутатора стрелочку будет направить. Так, как будет работать Spanning 3? Сначала нужно будет выбрать корневой коммутатор. Здесь стена текста, не обращайте внимания, это просто для меня, скажем, краткие тезисы.

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

что они не знают ничего о соседях. Поэтому они считают себя корневым коммутатором за всю топологию, и Designated Bridge, Designated коммутатором за все сегменты, в которые они смотрят. Естественно, это не совсем так, потому что корневой коммутатором должен быть только один, и Designated Bridge в каждом сегменте должен быть только один. Поэтому так работать коммутация не может. Поэтому пока все коммутаторы не догадаются, кто на самом деле из них всего один корневой коммутатор, и кто Designated Bridge всего один в каждом сегменте, у вас вся коммутация блокируется. То есть Spanning 3 начинает с того, что блокирует коммутацию на всех интерфейсах, говорит, я рут, я Designated Bridge. Каждый из коммутаторов, который у вас есть в топологии. Дальше, если вы считаете себя Designated Bridge, вы отправляете в каждый порт свой, в тот порт, на котором вы считаете себя Designated Bridge, вы отправляете так называемый BPDU, Bridge Protocol Data Unit. И вы указываете, кого вы считаете рутом,

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

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

Из CCNA, я думаю, что вы это должны будете помнить, 64 бита, такое большое число, но все-таки просто число. Дальше. Да, если вам кто-то рассказывает про более достойного рута, у которого root-бриджа иди меньше, чем у того, кого вы считаете сейчас рутом, то вы перековываетесь, начинаете рутом считать того, кого вам прислали. Если вам кто-то присылает BPDU, и вы видите, что в этой BPDU кто-то присылает такого же рута, как вы знаете, но указанное расстояние в этой BPDU будет меньше, чем у вас, то вы говорите, ага, я, соответственно, нахожусь дальше от рута, чем кто-то другой. То есть, если вдруг есть два коммутатора, соответственно, есть общий провод между ними, и один говорит, я знаю, как добраться до рута за 10 копеек, а вы сами могли бы сказать, я знаю, как добраться до рута за 15 копеек,

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

я в сети считаю себя рутом, и я к руту ближе, чем все остальные. Но у нас здесь нарушается фундаментальное требование, что в сети может быть только один designated bridge, поэтому пока топология не устаканится, все коммутаторы с момента начала пересчета топологии запускают таймер. И, соответственно, они говорят, за время работы этого таймера мы точно должны будем узнать, кто будет рутом, и мы точно должны будем узнать, соответственно, мы ближе к этому руту или дальше от этого рута, чем все остальные. Начинается все с того, что все считают себя рутами, и все считают себя designated bridge за все сегменты. Как только мы запускаем подсчет топологии, все отправляют BPDU. BPDU отправляются, и у нас коммутаторы некоторые получают BPDU от соседей, в которых написано, что рутом будут не они. То есть вот у нас первый коммутатор прислал BPDU в сторону третьего и говорит, у меня root ID вот такой. Третий тоже в сторону первого послал, что у меня root ID вот такой, root bridge ID. Но, соответственно, bridge ID первого коммутатора и bridge ID третьего коммутатора,

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

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

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

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

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

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

Ну, то есть при соблюдении определенных условий. Для того, чтобы разблокировать сеть, надо, чтобы все коммутаторы знали, а, кто root и, б, каким портом мы отправляем или принимаем самые вкусные BPDU в каждом сегменте. Так, ну дальше уже все стабильно, BPDU отправляется на диссигменты портах и рассказывает про то, как добраться до root-бриджа единички. По окончании пересчета топологии, то есть после окончания вот рассылки этих самых BPDU-шек с указанием того, кто root, будут разблокированы некоторые порты. При начале пересчета топологии все порты блокируются, то есть не выключаются, а именно коммутация блокируется. Если у вас есть заблокированный в Spanning Tree порт, это не означает, что на этом порту вообще ничего не ходит. То есть на заблокированном порту, во-первых, передается и принимаются сами Spanning Tree-шные BPDU-шки. Во-вторых, передаются всякие штуки типа CDP, LLDP и прочего.

То есть то, что не коммутируется, то, что направляется только на процессор самого свеча, но дальше не передается во все остальные порты. Spanning Tree-шные BPDU-шки, они не передаются во все остальные порты. А CDP-шные пакетики, они не передаются во все остальные порты. Мы на порту получаем CDP-шные кадры и обрабатываем их, и дальше не передаем. Если вдруг мы на каком-то порту рассылаем CDP-шные пакетики, это потому что мы их сами порождаем. Так что некоммутируемые кадры нормально через такие интерфейсы проходят. А вот то, что на движок коммутации направляется, оно, соответственно, блокируется. Можно будет сказать, что мы временно выключаем линк. Ну вот помните, да, я говорил, что у нас есть такой вот железный свитч, на котором мы говорим, запущена виртуальная машина VLAN 1, запущена виртуальная машина VLAN 2 и VLAN 3. И у нас есть физический порт, на котором приходят какие-то кадры, мы говорим, это все кадры относятся к VLAN 2. Вот можно сказать, что мы выключаем интерфейс виртуальной машины, которая смотрит на указанный свитч. Мы не коммутируем кадры, приходящие в определенном VLAN, которые подлежат коммутации.

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

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

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

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

Вот такая вот штука. Как уже говорилось, при отправке BPDU мы указываем идентификаторы коммутаторов, и, соответственно, у нас у каждого коммутатора должен быть вот этот самый идентификатор. Причем он должен быть уникальный. Уникальность его будет обеспечиваться наличием внутри этого самого bridge ID, внутри числа, какого-то прям заведомо уникального содержания. У нас есть замечательные уникальные идентификаторы при работе с Ethernet. Называется MAC-адрес. Но MAC-адреса хороши тем, что они уникальны, и плохи тем, что они не контролируются. То есть да, у нас действительно, если мы будем брать просто MAC-адрес в качестве идентификатора, каждый узел получит уникальный идентификатор, но мы не можем влиять на то, какой он получится, потому что он прошит на заводе, и поменять его нельзя. Соответственно, для того, чтобы иметь возможность влиять на выбор корневого коммутатора,

мы договорились использовать bridge ID меньше в качестве, скажем, определения хорошести или плохости идентификатора в части выбора рута. У нас MAC-адрес будет предваряться 16-битами, так называемыми bridge priority. То есть вот 48-бит MAC-адреса, перед ними дописывается 16-бит приоритета, и получается монолитное 64-битное число. Так, здесь немножко поехала разметка. 32 768 в десятичной системе счисления, то есть это 32 768 десятичная, и это 8016-ричная. По умолчанию bridge priority записывается именно такой. То есть 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0. Это число 32 768 десятичная или 8 0 0 0 16-ричная.

0 x 8 0 0 0 0. Ну и, соответственно, MAC-адреса. Если мы не меняем приоритеты, то bridge ID различаются по MAC-ам. Если мы хотим поменять какому-то коммутатору приоритет для того, чтобы он стал более, скажем, интересным кандидатом при выборе рута, то мы можем занизить bridge priority, сделать его поменьше, чем 32 768. И тогда при сравнении bridge ID у нас коммутатор, у которого bridge priority занижен, будет иметь меньше приоритет, чем все остальные коммутаторы, у которых этот bridge priority не занижен. Если мы дописываем к какому-то числу слева какие-то дополнительные разряды, и, соответственно, дописываем мы больше разряда, число становится сильно больше. Дописываем мы поменьше разряда, число становится меньше. Ну, в общем, здесь достаточно очевидно все. И вот пример. У нас есть два коммутатора. Мы их соединяем в простейшую топологию просто прямым проводом. И мы говорим, что у каждого коммутатора есть bridge ID. Дефолтные приоритеты мы, допустим, не меняем.

И у нас получается число вот такое вот. То есть мы к дефолтному приоритету 8000 приписываем справа MAC-адрес и получаем приоритет вот такой и MAC-адрес вот такой. Все это вместе называется bridge ID. Ну и для другого коммутатора тоже берем приоритет, берем MAC-адрес, склеиваем вместе, получаем тоже bridge ID. И сравниваем, у кого меньше. Каждый коммутатор рассылает бпдушки, говорит, я root, и меня зовут вот 8000 deadbif1111. И другой говорит, я тоже root, меня зовут вот так-то. Дальше один из них говорит, ну, у меня-то root ID поменьше. Другой говорит, о, я-то раньше считал себя root-ом, а мне кто-то рассказал, что root ID будет поменьше, поэтому немедленно перековывается и начинает root-ом оба коммутатора считать вот этот вот ID-шник. Очень простая схема, при которой каждый коммутатор получает заведомо уникальный идентификатор из коробки, который к тому же можно будет еще и редактировать и делать различные, скажем, приоритеты при выборе root-а.

Так, дальше. Когда бпдушки рассылаются, в них как раз эти самые приоритеты и бридж-а.д указываются в самом содержимом бпдушки. И мы уже говорили, что бпдушки могут быть лучше или хуже по сравнению друг с другом. Вот в этом случае мы говорим, что в бпдушках у нас передается некоторая информация. Формат бпдушки будет примерно следующий. Сначала идет заголовок 5-байтовый. Там номер версии, всякие флаги, но это нам сейчас неинтересно, что там внутри передается. Потом 22 байта, которые называются priority vector. Сender. Они состоят из 8 байт root-bridge-id, кого мы считаем рутом. Root-path-cost. До того, кого мы считаем рутом, сколько стоит добраться в копеечках, 4-байтовое значение. Сender-bridge-id, кто мы. И сender-port-id, каким портом мы это послали. Вот все в совокупности получается 22 байта. И, соответственно, табо-пдушка, у которой priority vector будет числово меньше по сравнению с какой-то другой,

будет называться superior. То есть более лучший, более хороший. А если есть две бпдушки, у одной из них priority vector будет получаться больше, чем у другой, то она будет называться inferior или хуже по сравнению с другой. То есть вот две бпдушки, которые вы рядышком между собой сравниваете, сравниваются по вот этим вот 22 байтам. 22 байта в одной бпдушке, 22 байта в другой бпдушке. 22 байт – это число. И вы можете сказать, вот мы берем монолитное число 22 байта и сравниваем. У кого меньше, тот и прав. И, соответственно, меньше два числа будут очевидны, если одна бпдушка имеет root bridge ID какой-то один, а другая какой-то другой, то бпдушка, у которой root bridge ID будет меньше, она будет более правильной, она будет superior. Ну и, соответственно, бпдушка, у которой root bridge ID больше, будет по определению inferior. То есть у них 22 байта, начиная с самых первых, самых левых байт будут, соответственно, различаться. И в одной из них это число будет заведомо больше, чем в другой.

Вот самые первые байты, которые здесь идут, root bridge ID, первые 8 байт из числа 22, они больше всего влияют на результат. Поэтому если вдруг две бпдушки сравнивать между собой и root bridge ID у них будут разные, то та бпдушка, у которой root bridge ID будет меньше, та и будет более правильной, более хорошей, superior. Если две бпдушки имеют одинаковые root bridge ID, то дальше мы говорим, ну окей, в левых 8 байтах они оказались равны, но, наверное, они тогда в других байтах окажутся разными. Вот следующие байты, которые есть, это root path cost. 4 байта. Соответственно, если есть две бпдушки, одна говорит, я знаю, как добраться до рута за 10 копеек, а другая говорит, я знаю, как добраться до рута за 15 копеек, вот та, которая за 10, будет лучше. Если вдруг так получилось, что у нас есть две бпдушки, и одна говорит, я знаю, как добраться за 10 копеек, и другая говорит, я знаю, как добраться за 10 копеек, нам надо каким-то образом из двух отправителей этих бпдушек выбрать ту, которая будет лучше, бпдушку лучше,

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

У вас есть свитч и ваш свитч. И эти два свитча соединены двумя параллельными линками. У вас на одном порту приходит бпдушка, и на другом порту приходит бпдушка. Это бпдушки, отправленные одним и тем же соседом. И в этом случае у них рут bridge ID, естественно, одинаковый, рут подкосты, естественно, одинаковый. Сендер bridge ID тоже одинаковый. Они отправлены одним и тем же соседом. Но, соответственно, они отправлены разными портами. Поэтому каждый порт у отправителя будет пронумерован, и вот с EnderPortID это указание на то, каким портом мы это отправили. И если у нас приходят две такие BPD-ушки, вот мы говорим, да, действительно, это один и тот же сосед, и у нас BPD-ушка здесь приходит чуть-чуть получше, а вот здесь приходит чуть-чуть похуже, и разница между ними будет заключаться в том, что вот эта вот BPD-ушка, например, отправлена Ethernet-ом нулевым, а эта Ethernet-ом первым. И, соответственно, номер порта здесь на единичку меньше, чем здесь. Поэтому BPD-ушка в одном интерфейсе отправленная чуть-чуть получше, чем в другом.

И, соответственно, ближе к руту будет провод вот левый, а второй будет, ну, типа чуть дальше от рута. Не топологически, опять же, а чисто вот при подбрасывании монеток мы сказали, что мы принимаем решение, что дальше от рута находится тот, кто отправляет нам чуть подальше BPD-ушки. Так. Как будут коммутаторы определять, кто из них будет рутом? Ну, то есть мы уже знаем, что при начале работы Spanio 3 начинает рассылать BPD-ушки. Мы понимаем, что там есть логика вида. Если кто-то нам прислал BPD-ушку, что считает рутом кого-то, кто лучше, чем тот рут, которого мы считаем сами сейчас, то мы начинаем считать рутом того, кого нам прислали в более вкусной BPD-ушке. Ну, и, соответственно, дальше вы начинаете рассказывать всем остальным, кого вы считаете рутом уже сейчас. Начинаете вы с того, что рутом считаете себя. И вот на картинке у нас как раз ситуация вида 4 коммутатора в топологии.

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

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

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

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

Но до него добраться можно за стоимость. Сколько пришло в бопудушке стоимость? 0. Плюс 10 копеечек стоимость интерфейса, на котором такая бопудушка была получена. Соответственно, итоговая стоимость, как можно добраться до рута. Здесь вот у нас root path cost 0. Root path cost на верхнем коммутаторе 10. Root path cost на нижнем коммутаторе 0 копеечек, пришедшая в бопудушке. Плюс 50. Стоимость интерфейса получается 50. Ну и, соответственно, правый коммутатор пока ничего про зеленый и про левый не знает. И, соответственно, продолжает считать себя рутом. Говорит, я root, я знаю, как добраться до самого себя за 0 копеечек. Так. Дальше. Второй шаг. Рассылаются снова бопудушки. Про то, как можно добраться до рута. Левый продолжает считать себя рутом, продолжает рассылать бопудушки за 0 копеек. 0 отправляет сюда, 0 отправляет сюда.

Верхний говорит, я знаю, как добраться до рута за 10 копеек. нижний говорит я знаю как добраться за рута до рута за 50 копеек и правый свеч говорит окей я раньше рассказывал про то что я сам root теперь мне рассказали про то что рут на самом деле левый и соответственно я знаю как добраться до рута через один способ через бопадушку стоимостью 10 копеек плюс интерфейс 10 копеек получается здесь вот 20 root pass cost 20 и альтернативный способ я получаю чуть менее вкусную бопадушку со стоимостью 50 плюс 10 копеечек ну соответственно 60 из двух вариантов как можно добраться до рута я выбираю тот который будет дешевле там где эффективный root pass cost получается 20 там где за 60 получается невкусно я туда не хожу на этом дальше процесс не останавливается на самом деле дальше продолжают рассылаться по подушки и получается что давайте я сотру здесь ненужные со слайда вот эти вот товарищи нам здесь уже ничего нового не расскажут вот на вот

этот вот линк можно посмотреть более внимательно в этом линке у нас есть свеч который знает когда браться до рута за 50 копеек и свеч как добрают знать как добрация до рута за 20 копеек другой уже они друг другу будут посылать до подушки то есть левый свеч расскажу что знает как добраться до рута за 50 правый в ответ к нему пришлет бы подушку я знаю как добраться дурта за 20 копеек и соответственно левый точнее нижний свитч скажет окей я теперь знаю более правильный способ добраться до рута раньше я про него не знал а теперь я вижу чтобы подушка который приходит за 20 копеек она вкуснее чем душка который будет за 50 копеек даже с учетом того что за 20 копеек плюс 10 транспортная стоимость как бы самого интерфейса получается что на самом деле на следующем шаге у нас нижний свитч будет знать как добраться дурта за 30 копеек вот ссылаются и у нас перековывается нижний свитч говорит я теперь получил информацию как добраться дурта за 30 копеек и на этом сеть уже дальше устаканивается по поводу

стоимости вы можете стоимости выставить руками в любой логика который вам хочется рекомендованные значения приведены в табличке есть рекомендованные рекомендованы и значения и есть рекомендованный диапазон если вы хотите поменять эти стоимости руками но в принципе да вы можете выставить стоимости совершенно по любому правилу который вам будет хотеться чем меньше стоимость интерфейса тем больше вероятность того что через этот интерфейс будет проходить трафик характерные рекомендованные значения будут следующие в оригинальной формуле 90 года было сказано давайте возьмем скажем эталонную полосу пропускания в 1 гигабит в секунду и поделим ее на скорость интерфейса мы получим рекомендованные значения стоимости этого такого интерфейса и там было просто табличка в которой указывалась если это интерфейс 4 мегабитный то дальше кто-то автор протокола достану к vocês поделил 1 гигабит на 4 мегабит и сказал рекомендованное значение для 4

мегабит 250 копеек точно также рекомендованное значение для 10 мегабит 100 копеек рекомендованное значение для 16 мегабит 62 копейки и так далее то есть рекомендованные значения были прописаны до 1 гигабита 2 гигабита 10 гигабиты Jos 형 до эту же были как бы не допустимая скорость и на момент создания этого протокола я просто Напомню, что все это создавалось даже не в 90-м году, а типа в конце 80-х, когда гигабитных интерфейсов в принципе на тот момент не существовало. Поэтому нормальной скоростью было порядка 10 мегабит, поэтому это была нормальная разумная скорость. Можно было сказать, давайте мы возьмем, например, 100-мегабитный линк. На тот момент 100-мегабитные линки уже подходили к своему развитию и в принципе авторы протокола уже догадывались, что скоро, наверное, они станут основными. Поэтому 100-мегабитные линки получали стоимость 10. Ну и наиболее популярными линками были все-таки 100-мегабитки и нормальной рабочей стоимостью для интерфейса была как раз 100 копеек.

Если вы хотели, вы могли эту стоимость в любом случае переопределить по своему хотению. В 98-м году стало понятно, что с этими стоимостями есть фундаментальная проблема. И проблема заключается в том, что рекомендованные значения для всех интерфейсов были прописаны вплоть до гигабита, у которого стоимость была 1 копеечка. В 98-м году гигабитные интерфейсы уже были. И из ArtChannel были уже. Поэтому были уже интерфейсы с производительностью 2 гигабита в секунду. И на подходе были 10-гигабитные линки. Они уже тоже были вполне как бы в проекте. Если в 85-м, 87-м году гигабитных линков не было и 10-гигабитных линков не было, это все были далекие мечты фантастов, то в 98-м году 10-гигабитные линки были уже вполне реальностью. Они уже в лабораториях работали и скоро должны были войти в продакшн. Поэтому 802.1.98 года сказал, давайте изменять стоимости. То есть, учитывая, что мы можем относительно безболезненно регулировать эти самые стоимости,

мы же можем просто сказать, давайте мы рекомендации поменяем. Ну, раньше были такие рекомендации, сейчас будут всякие, какая разница. Главное, чтобы вы в одной логике внутри своей сети эти самые стоимости назначали на всех устройствах. И дефолтные стоимости, рекомендованные, в стандарте 802.1.90 года изменили на следующее. 4 мегабита и 10 мегабит, это все по-прежнему табличка. Остались те же самые. 16 мегабит тоже те же самые. 250, 100 и 62. Для 100 мегабитного изернета, опять же, это основная рабочая лошадка на тот момент, стоимость поставили 19. Для гигабитного изернета это 4 копейки. Для 2 гигабитного это пара гигабитов, это 3 копейки. И для 10 гигабитных линков 2 копейки. Вот. И, соответственно, если у вас были линки быстрее, чем 10 гигабит, они получали стоимость 1 копейку.

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

Ну, гигабит 20 тысяч, 10 гигабит 200 тысяч, 100 гигабит 200 Ну, то есть, понимаете, да? Вы до 20 терабитных линков откладываете решение этой проблемы Ну, а 20 терабит на подходе пока что даже не предвидится Дело в том, что дальше мы уже упираемся в два фундаментальных ограничения Первое ограничение, что по линку больше, чем, допустим, терабит Перегнать трафик становится очень сложно Мы упираемся во много разных физических... В несколько разных физических ограничений, да? Связанных с тем, что мы не можем слишком часто дергать кварцы Мы не можем слишком гранулярно за какие-то разумные деньги Определять, соответственно, что сигнал какой-то пришел Померить этот сигнал надо То есть каждый битик, он же приходит в виде аналогового сигнала Его надо оцифровать с нужной степенью точности Передать дальше

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

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

Поэтому если вы используете CISC-свитчи, имейте, пожалуйста, в виду, что метрика у них вот такая вот старенькая Ну, MST-протокол на CISC-ах на тех же самых работает с метрикой уже нормальной Просто такая забавная особенность, что вы можете стоимости выставлять по умолчанию в какой-то логике и не обязательно разные железки у вас будут работать в одной и той же логике Может быть такое, да, что часть железок работает в одной логике соответственно что один и тот же интерфейс на железке одного производителя будет стоить там условно 19 копеек а на другой железке другого производителя точно тот же самый интерфейс точно такой же будет стоить 200 тысяч копеек убедить пожалуйста при работе со своим оборудованием спалник 3 что логика у вас на значение стоимостей одинаковые ну и если нет то поправьте и и скажите что она должна быть одинаковая либо назначить все стоимости ручками придется ну тоже как бы это

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

бпд ушка которая вы могли бы сами отправить в этот интерфейс обратно она по определению дороже на стоимость этого интерфейса ну и поэтому да поэтому вы обратно в сторону соседа более плохую некачественную инферию бпд ушку не посылайте никогда ибо пдушка который к вам приходит от рута она соответственно по определению будет вкуснее чем ваше собственное так да вы считаете кратчайший способ как добраться дурта на каждом коммутаторе на самом руте нечего считать если вы сам рут то вы не должны отправлять трафик ни в какой физический порт чтобы он дошел до рута поэтому на самом руте никакой порт корневым не объявляется на всех остальных коммутаторах вы говорите мы получаем на некоторых портах бпд ушки от рута самые вкусные и не отправляем бы подушке в этот порт и соответственно мы выбираем среди всех портов на которых мы получаем бпд ушки от рута один самый самый самый хороший самый дешевый на верхней коммутаторе все просто мы пають обо hatırroそ peoplesan только на одном парту это вот

вот этот порт там написано 0 копеек плюс 10 копеек получается соответственно стоимость эффективное Это самый выгодный способ добраться до рута. На втором порту, вот здесь, мы бпдушку не получаем, потому что мы ее сами отправляем. Мы там диссигнаем этот бридж. На нижнем коммутаторе мы получаем самую вкусную бпдушку от правого коммутатора за 20 копеек плюс 10 копеек транспортной стоимости того 30. И мы получаем бпдушку от самого рута, где рут говорит, что он знает, как добраться до рута за 0 копеек, плюс 50 копеек будет стоимость транспортная. Поэтому у нас есть два варианта, как можно добраться до рута. Одна за 20 плюс 10 – 30 копеек, вторая за 0 плюс 50 – за 50 копеек. Вот мы говорим, самый выгодный способ добраться до рута – это вон туда. Поэтому рут-порт у нас будет на нижнем коммутаторе в сторону правого. Ну и на самом правом, соответственно, мы получаем бпдушку тоже только на одном порту. И говорим, рут-порт будет вот только один, тот, который у нас есть. Альтернативы ему просто особых нет.

Альтернативы порт – это тот порт, который является запасным рутом. То есть если у нас есть несколько портов, где мы получаем бпдушки от соседей и не отправляем бпдушки, потому что если мы получаем вкусную бпдушку, то кто нам ее присылает, находится ближе к руту, чем мы. И если мы находимся дальше от рута, то нам нет смысла в сторону того, кто ближе, посылать невкусную бпдушку. Так вот, получается, что если нам кто-то присылает вкусную бпдушку, то мы либо смотрим на него root-портом, либо мы не смотрим на него root-портом. Вот один порт из числа всех портов, на которых мы получаем вкусные бпдушки, мы помечаем рутовым. А все остальные порты, на которых мы получаем вкусные бпдушки, вкуснее, чем мы сами могли бы отправить. Но мы не объявляем такой порт рутовым. Мы помечаем как alternate-порт. И вот этот вот alternate-порт – это запасной рут. Если у нас текущий root по каким-то причинам сдохнет, то из числа всех альтернатов будет выбран один новый root-порт, который будет чуть похуже, чем бывший root, но, соответственно, все равно он будет самый-самый хороший из числа всех оставшихся.

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

Вот, тогда вы один порт из числа всех, на которых вы получаете вкусные BPD-ушки, объявляете root-овым, все остальные объявляете альтернат-ами. Если вы не получаете вкусную BPD-ушку на порту, то вы ее сами отправляете. И, соответственно, эта BPD-ушка, которую вы отправляете, будет означать, что вы находитесь к root-у ближе, чем все остальные. Вы отправляете BPD-ушку, вы не получаете на диссигнет-порту никаких чужих BPD-ушек, потому что нет смысла в сторону того, кто ближе к root-у, посылать BPD-ушку от свеча, который находится дальше от root-а. Если вдруг даже кто-то согласился бы отправлять вашу сторону BPD-ушки, BPD-ушки, которые бы приходили, они по-определению приходили бы хуже, чем ваши. Диссигнейтед порт – это единственный, в который вы будете отправлять BPD-ушку. Ну, то есть их может быть много на коммутаторе, естественно. Может быть такое, что у вас на коммутаторе 10 портов, и во всех 10 вы находитесь ближе к root-у, чем кто-либо еще, особенно если вы root-сами.

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

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

Вот, это запасной диссигнейтед порт. То есть у вас получается, что если вдруг вы замыкаете два порта какими-то линками, где у вас пользователи сидят, то есть один из способов добраться до этой сети, соответственно, основной, который будет лучше, чем все остальные ваши собственные порты. Есть другой интерфейс, который смотрит в эту же среду, но он должен быть заблокирован, потому что кто-то присылает нам BPDU лучше, чем вы могли бы сами ее отправить. Кто же это мог быть? То есть на диссигнейтед порту вы отправляете BPDU, вы указываете, что у вас root-bridge-id, ну какой-то там, не знаю, единичка, root-pass-cost, вы говорите, я знаю, как добраться до рута. Ну сколько-то вы там проставляете, не знаю, 10 копеек, говорите, знаю, как добраться до рута за 10 копеек. Sender-bridge-id, вы указываете, кто вы, ну допустим двоечку, и дальше sender-port-id, вы указываете, каким портом вы это отправили, и дальше вы указываете номер порта.

BPDU, который вы могли бы отправить на запасном диссигнейтед порту, будет иметь следующий вид. Root-bridge-id. Точно тот же самый, потому что это один и тот же коммутатор отправляет. Он говорит, я тоже знаю, что root-ом будет первый коммутатор, какой-то первый, неважно какой. Root-pass-cost, как добраться до рута? Ну столько же, сколько на соседнем порту мы отправили, тоже говорим, за 10 копеек можно через этот порт добраться до рута. Sender-bridge-id, такой же, как на предыдущем случае, то есть мы сендер в любом случае говорим, нас зовут коммутатор с айдишником 2. И вот сендер-порт-id на этом порту будет другой. Он, соответственно, будет там, допустим, двоечка. И вот мы сравниваем вот эти 22 байта и вот эти 22 байта. И получается, что в самом последнем пункте у них есть расхождение. Одна из BPDU лучше, а другая хуже. Поэтому диссигнейтед порт будет посылать BPDU, и они будут чуть-чуть лучше, чем BPDU, которую мы могли бы послать на бэкапном порту, но не посылаем, потому что нет смысла. А бэкапный порт говорит, я свой порт должен буду заблокировать,

потому что он формирует петлю по факту. То есть, да, нам не надо, чтобы в бэкапный порт мы принимали трафик. Но если вдруг диссигнейтед порт сдохнет, то бэкапный порт разблокируется и позволит нам обслужить трафик этих самых пользователей. Бэкапный порт назначается по принципу, если вы принимаете BPDU, которая суперер по отношению к вашей, и у нее сендер-бридж-ид совпадает с вашим собственным. То есть, если вы видите свою собственную BPDU на порту, отправленную каким-то собственным же, но другим портом, то вы объявляете этот порт бэкапным. Бэкапный порт останется заблокированным после пересчета. То есть, из числа четырех ролей портов, которые мы видим, root, alternate, designated, backup, у нас будут root и designated, которые будут разблокированными, и alternate и, соответственно, backup, которые останутся заблокированными после окончания пересчета топологии. Root и alternate – это порты, на которых вы получаете вкусную BPDU,

бэкапную подушку, designated – это бэкап, и это порты, где вы сами могли бы в сегмент отправить вкусную бэкапную подушку. То есть, никто вам другой не рассказывает про то, что он находится ближе к руку, чем вы. Только designated – это вы, где действительно посылаете бэкапную подушку, а бэкапный порт, где вы не посылаете бэкапную подушку, потому что вы другим портом в этот сегмент уже вкусную бэкапную подушку послали. Теперь, когда мы знаем, по какому принципу коммутаторы будут работать, что они будут делать после обмена BPDU, мы давайте посмотрим, что в самих BPDU будет передаваться. Мы уже знаем, что там есть priority vector 22 байта. Мы знаем также про то, что там есть некий заголовок 5-байтовый, и кроме того, там есть еще так называемые таймеры. Вот существуют BPDU, в которых все это действительно есть. И BPDU, которые именно влияют на вычисление топологии, они содержат все действительно эти поля.

На табличке справа показан детальный расклад по тому, что содержится внутри каждого поля. Заголовок у нас будет передавать какие-то общие свойства про конкретную BPDU. Там сначала будет идти protocol identifier, что это идет в spanning 3. там указывается 0, 0, что это именно spanning 3. Потом protocol version. Это протокол, версия конкретного spanning 3. Для медленного spanning 3 там будет 0. Для быстрого spanning 3 там будет 2. Ну, еще MST есть 3. Там тоже, на самом деле, такой же формат заголовка будет. Но про MST будет сейчас отдельный расклад. Дальше BPDU type там указывается, что это за BPDU. И она бывает одного из двух типов. Полная, когда действительно есть заголовок, есть priority vector и есть таймеры. И она называется configuration BPDU. То есть это BPDU, в которой содержится все необходимое для перенастройки топологии. И есть еще так называемый topology change notification,

у которых только вот первые вот эти вот 5 байт и больше ничего нету. То есть если BPDU type стоит единичка, что это BPDU configuration, topology change, точнее, там не единичка, там единичка в одном бите стоит, то это значит, что есть только заголовок. Topology change notification в бдушке существует только в spanning 3 совсем медленном, который вот тот самый 90-го года. в быстром spanning 3 они упразднены. И сегодня вы их встретите, можете, только если у вас есть сосуществование медленного spanning 3. И где-то вот в сети застрял какой-то старый свеч, он работает только с медленным spanning 3. Вот там будет использоваться topology change notification. И ну и дальше таймеры. Таймеров 4 штуки, каждая по 2 байта указывается время там в очень забавных единицах измерения. Это единица измерения. Вы вот в каждое поле двухбайтовое вкладываете некое число, и это число в 256 долях секунды.

То есть если вы хотите сказать, что у вас есть какой-то таймер, ну например, там допустим, hello time равный 2 секундам, то вы указываете, что у вас вот эти вот 2 байта, 16 бит, в первом байте вы указываете число в секундах, а во втором вы указываете 0, что это 256 раз под, два раза под 256 единиц. И каждая единица это 1 256 секунды. Ну то есть если вы хотите указать, что таймер у вас будет целочисленный, то по факту вы из двух байт будете задействовать только один. А вот еще один байт вы при этом просто обнуляете. Но гипотетически hello time можно будет задать, ну равно как и все остальные таймеры, можно будет задать очень гранулярно, с гранулярностью до 1 256 секунды, и для этого вы будете использовать все 2 байта целиком. Там с этими таймерами будет забавная история, поэтому про них расскажу отдельно.

Так, как бы подушки эти будут передаваться? Они будут передаваться на специальный MAC адрес 01800C2 000000. И вот эта вот OOI-шка характерная для так называемых slow protocols. Точнее не slow protocols, а IEE protocols. Вот, то есть сюда будут относиться всякие spanning tree, сюда будут относиться LATSP, сюда будет относиться много всякого разного другого. Так, да, дальше. MAC адрес получателя, там вот мультикастовый MAC адрес и E-шных протоколов. Дальше внутри лежит LLC вложение, но без snap вложения. Там будут source service access point и destination service access point равные 0x42. То есть получается, что кадр, в котором передается 802.1D-шная BPDU-шка, будет в себе содержать адрес получателя, destination address, вот этот вот самый мультикастовый.

Дальше source address – это каким MAC адресом мы это отправили. Дальше указание, сколько внутри лежит длина. Дальше LLC-шный заголовок с вот этими полями 042, 042, 03. То есть 42, 42, 03. 03, как вы помните, control award. И дальше, если бы у нас было snap вложение, то здесь было бы AA, AA, 03. И дальше был бы snap заголовок. Но у нас нету AA, поэтому snap заголовка нету. Дальше идет сразу вложение с полейнгтричной STP. Это на самом деле один из редких случаев, когда в сети, в современной, вы можете увидеть чистое LLC вложение без snap. То есть действительно там вот указывается свой собственный код вложения в Ethernet. 042 – это хорошо известные спаниктричные вложения. Так, ну и соответственно, что у нас дальше там будет? Priority Vector вот этот вот, 22-байтовый.

Он передается в Configuration BPD-ушках, и мы его уже знаем. Сначала идет root bridge ID, потом root path cost, потом sender bridge ID, потом sender port ID. Содержимое priority Vector надо знать, как ученыш на экзамене. То есть, ну его запомнить на самом деле легко. Bridge ID по 8 байт, вы это знаете. Root path cost, ну просто надо запомнить, что он 4-байтовый. Sender port ID 2 байта. Ну всего получается 8 плюс 4 – 12, плюс 8 – 20, плюс 2 – 22. То есть 22 байта в каждой BPD-ушке передается. Если говорить про полностью priority Vector, который в стандарте описан, то к вот этому priority Vector, который мы получаем в BPD-ушке, мы можем еще прибавить стоимость, как добраться до ROOTA, через какой интерфейс мы можем добраться до ROOTA. То есть, когда приходит BPD-ушка через какой-то интерфейс, мы к root path cost добавляем еще штучку одну. Это стоимость интерфейса. И на самом деле, когда мы говорим, что вот через какой-то интерфейс мы получаем определенную BPD-ушку, мы к этому priority Vector еще 2 байта дописываем. Это receiving port ID.

Каким портом мы это получили? Но про это опять же там чуть дальше будет. Указание на то, каким портом мы это получили, еще будет 2-байтовый. Поэтому вместо не круглой цифры в 22 байта, на самом деле priority Vector будет 24 байта. Начнем сначала. Протокол ID у Spanning 3 всегда все нули, 2-байтовые. То есть, если вы видите, что просто какое-то что-то имеет отношение к Spanning 3, то вы там видите 0, 0, 0, 0. Spanning 3-шные BPD-ушки всегда начинаются на 2 байта нулевые. Потом протокол version. Что за версия Spanning 3 передается? Если это медленный Spanning 3, там нули. Ну, 1, 0, 1-байтовый. Если это быстрый Spanning 3, то там 0, x2. Еще есть MST. Это, соответственно, 0, x3. После чего BPD-у Type. Это вот те самые Configuration или не Configuration BPD-у. Если это медленная BPD-ушка, то там указывается 0. Если это медленная BPD-ушка без содержимого, только с заголовком,

то там указывается 0, x80. Это 1, 0, 0, 0, 0, 0, 0. То есть единичка в самом старшем битике выставлена. И есть еще BPD-ушка быстрая, RST-пэшная. Она по структуре такая же, как и Configuration BPD-у, но она объединяет в себе и задачи Configuration медленного BPD-у, и Topology Change. Поэтому у нее отдельный тип 0x02. Так, дальше. Флаги. С флагами все довольно скучно. То есть запоминать их не надо, но примерно надо представлять, что там будет. В них есть флаг Topology Change. То есть если вдруг вы отправляете указание, что я знаю, что у нас сменилась топология, то вы выставляете этот самый флажок. И, соответственно, у нас у каждого коммутатора есть алгоритм, что делать в случае, если сменилась топология. Ну, как минимум надо заблокировать все порты. Как минимум надо сбросить базу MAC-адресов, потому что если у нас сменилась топология, то, возможно, у нас сменился root. Возможно, у нас сменятся порты, которыми мы смотрим на root.

Возможно, у нас какие-то порты, через которые мы раньше получали трафик от каких-то абонентов, будут заблокированы. Поэтому мы превентивно удаляем все из таблицы MAC-адресов. Так называемую флажем таблицу. И проводим процедуру построения топологии заново. Вот единичка, это как раз топология change. У нас самый старший битик будет, который указывает на то, считаем ли мы, что топология изменилась или нет. Дальше proposal. Proposal – это будет в быстром Spanning 3 использоваться штука. Есть flag proposal и есть flag agreement. В ситуации, когда у нас есть медленный Spanning 3, эти флаги отсутствуют. Они неопределены. И если у вас есть медленный Spanning 3, то может быть ситуация вида. Два свеча друг друга видят. Один посылает боподушку. Второй говорит, я принимаю эту боподушку, но я в ответ ничего не посылаю. Потому что если вдруг я буду что-то посылать, то моя боподушка будет заведомо хуже. И нет смысла в ответ на боподушку, которая лучше, присылать что-либо еще. И он ничего не посылает в ответ, потому что таких свечей, которые могут хуже быть, чем текущий Signited Bridge, может быть много.

Если каждый начнет отвечать в среде с конкурентным доступом, у вас будет огромное количество коллизий встречаться. То есть мы же заранее не знаем, сколько в общем толстом желтом коаксиале будет свечей. Правда? Поэтому если один говорит, я ближе всего к рту, все остальные сидят, молчат в тряпочку. Быстрый Spanning 3 говорит, что, знаете, 98-й год на носу, никаких коаксиалов уже в общем в сетях не остается. Поэтому вот этого всего у нас не бывает. Если у нас есть два свеча, которые друг с другом связаны проводом, то в этом проводе есть ровно два свеча, никаких абонентов, ничего лишнего нет. То есть всегда у нас топология в нормальной сети предприятия будет point-to-point. Физически два свеча будут соединены только прямым проводом и ничем иначе. И в такой ситуации, если мы отправляем сообщение, я хочу сказать, что я ближе всего к рту, поэтому я своим портом считаю себя designated bridge. И вы принимаете такое указание, как другой свеч, вы говорите, ко мне кто-то прислал указание, что он будет designated bridge.

Я с этим согласен. Я не против того, чтобы он стал designated bridge. И вы в ответ посылаете agreement, что вы согласны с тем, что вы не будете designated bridge. Поэтому если вы с ВИЧ, который работает с быстрым испанинг 3, и вы понимаете, что сосед у вас весьма вероятно только один в проводе, вы посылаете BPDU с криком «Я буду designated bridge», но не просто BPDU, а BPDU с флажком proposal. Типа, если ты, дорогой сосед с ВИЧ, не против того, чтобы я был designated bridge в этой сети, ты, пожалуйста, согласись на этот proposal, пришли мне, пожалуйста, в ответ BPDU, я согласен. И вот в этой ситуации вы, как отправитель вкусной BPDU-шки, проставляете флаг proposal, и как получатель, соседний свитч, который будет получать такую BPDU-шку, вы говорите, я не против того, чтобы сосед стал designated bridge, вы отправляете inferior BPDU-шку с флагом agreement. То есть ответная BPDU-шка идет, окей, ты будешь designated bridge.

Вот эта вот ответная BPDU-шка, она будет заведомо inferior, но чтобы не было сомнения, что эта BPDU-шка спорит с той BPDU-шкой, которая пришла в оригинале, у нас немножко переименовывается поле. Вот в priority vector у нас есть поле sender bridge ID. В быстром Spanning 3 она немножко переименовывается не sender bridge ID, а designated bridge ID. По сути своей ничего не изменилось. То есть когда вы говорите, я designated bridge, я посылаю BPDU-шку, то есть по определению я же и sender, и я же свой bridge ID здесь показываю. Для отправителя вкусной BPDU-шки ничего не изменилось. А вот для отправителя подтверждения, что я не против, что ты будешь designated bridge ID, есть небольшое изменение, что это BPDU-шка, которую он отправляет от своего имени, но он не прописывает себя в качестве designated bridge ID. Он говорит, я вижу, что designated bridge ID будет вон тот. Ну, соответственно, да, proposal agreement, они вот такие вот. Если вы используете медленный Spanning 3, то дальше там два бита будут port role,

ну, точнее, там они не определены, просто там зарезервированы под будущее расширение. И в быстром Spanning 3 эти биты были действительно задействованы. Расширение там указывает роль порта, которым вы отправляете эту BPDU-шку. Роль и состояние, точнее, более правильное. И, соответственно, если вы отправляете какую-то BPDU-шку, вы говорите, что за порт, которым вы эту BPDU-шку отправили. Если вы отправляете просто BPDU-шку с криками «я здесь считаю себя самым главным», то вы отправляете указание «я себя считаю designated bridge ID» на этом порту. Это нормально. Если вы отправляете BPDU-шку с подтверждением того, что вы не против, что кто-то другой станет designated bridge, то есть ваша BPDU-шка будет заведомо хуже, чем какая-то другая, но вы отправляете свою inferior BPDU-шку в ответ на чью-то BPDU-шку с пропозелом, то вы указываете, соответственно, в флаге, что вы либо этот порт потом разблокируете, что вы не против того, чтобы порт отправителя был designated,

но вы при этом сообщаете, что ваш порт будет рутовым. Или вы сообщаете, что ваш порт будет альтернейтом, ну или бэкапом, что вы со своей стороны порт заблокируете. То есть в ответ на BPDU-шку «я не против» вы указываете, какое ваше состояние будет на этом порту. Не то, чтобы оно отправителю было как-то зачем-то интересно, но просто так, чисто ради прикола, чтобы он знал, будет ли этот порт заблокирован или будет ли он разблокирован. По факту это не используется нигде. Поэтому чисто информационное сообщение и удобно для дебагов, что если вдруг вы там в Airshark смотрите, что по сети у вас бегает, вы сразу будете видеть, кто, чего, что и где заблокировал. Дальше показываются состояния порта. У вас есть флаги Learning и Forwarding. Learning означает, что на этом порту идет MacLearning, что кадры, которые к вам приходят, вы анализируете, смотрите, с каких MAC-адресов они пришли, и MAC-адреса эти, заносите в таблицу MAC-адресов. И Forwarding – это указывает на то, действительно ли на этом порту работает коммутация.

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

Опять же, это только в быстром Spanning 3 используется, поэтому в медленном Spanning 3 не может быть такого, что вы отправляете указание, что на этом порту вы ведете MacLearning, или на этом порту вы Forwardите кадры. Там просто вы отправляете боподушки, и все, и точка. И последний флажок – это Topology Change Acknowledge. Если у нас происходит Topology Change, в медленном Spanning 3 распилается специальная боподушка Topology Change Notification. И, соответственно, подтверждение Topology Change Notification будет полноценная боподушка Topology Change Acknowledge. Мы про это будем говорить подальше, когда будем говорить про сравнение медленного и быстрого Spanning 3. По поводу Priority Vector. Да, в BPDU у вас отправляется 4 значения. Опять же, знать надо их как отчинаж. Это root bridge ID. Кого вы считаете рутом? Root path cost. Через сколько копеечек вы знаете рута как отправитель?

Sender, оно же designated bridge ID. и sender port ID. Вот. Когда вы отправляете такие боподушки, вы указываете, как на отправителе, вот вы знаете, как добраться до рута. Когда получатель принимает такую боподушку, он может этот Priority Vector сравнивать в чистом виде. Например, если у нас есть интерфейс, и на этом интерфейсе мы получаем две боподушки от двух разных соседей. Или сами можем отправлять боподушку. В этом случае мы сравниваем именно чистые Priority Vectora, которые в этих боподушках будут указываться. Но если мы хотим сказать, что мы принимаем боподушку от соседа, и мы должны сравнить ее эффективное значение, то мы на самом деле говорим, что у нас есть, например, два интерфейса. На одном интерфейсе мы получаем какую-то боподушку, и на другом боподушку принимаем. Поэтому нам по факту надо сравнивать эффективное значение, как мы можем добраться до рута через определенного соседа, через определенный интерфейс. Не то, кто лучше боподушку в интерфейс отправляет,

а то именно, сколько стоит добраться через интерфейс до рута. Поэтому мы к root path cost добавляем порт cost, сколько у нас стоит интерфейс, и плюс мы к этому Priority Vector 22-байтовому добавляем еще 2 байта Receiving Port ID, каким портом мы это получили боподушку. И у нас получается в итоге 24 байта вот такой вот полноценный Priority Vector. Это число, опять же, и вы можете сказать, что если у нас с одной стороны приходит BPDU, и с другой стороны приходит BPDU, вот как определить, через кого до рута вкуснее можно добраться. При выборе рут или альтернатив портов это как раз будет очень актуально. И вы будете как раз сравнивать эффективные значения этих самых Priority Vector, то есть с учетом port cost, с учетом Receiving Port ID. В случае с port cost там все достаточно очевидно, а вот Receiving Port ID – это интересный случай, зачем он может пригодиться. Смотрите, как это будет выглядеть. Может быть ситуация вида. У нас есть свитч. Этот свитч смотрит на хаб

или на свитч без поддержки Spanning 3, от которого до вас доходят 2 линка. И, соответственно, одна и та же BPDU, которая отправляется соседам, она разветвляется и принимается двумя разными портами на нашем свитче. И в этом случае у них все будет одинаково. У них будет одинаковый root bridge ID, у них будет одинаковый root pass cost, у них будет одинаковый sender bridge ID, у них одинаковый sender port ID, потому что это была одна и та же BPDU, но нам нужно будет сказать, что если мы оба этих порта разблокируем, и этот, и этот, у нас получится петля, потому что здесь вот есть по факту петля. Но мы со своей стороны должны будем один из этих портов объявить rootовым, а другой будем блокировать. Ну или оба заблокируем, возможно. И, соответственно, вот если у нас идет выбор между одной BPDU и второй, мы говорим, мы добавляем, во-первых, port cost, если мы скажем, что у нас есть интерфейс, который стоит 10 копеек или 20 копеек, то в этом случае одна и та же BPDU через один интерфейс будет стоить одно количество копеек, а другая, та же самая BPDU,

через другой интерфейс будет стоить чуть-чуть подороже. Но если мы даже этого и не сделаем, то может быть такое, что мы скажем, ну окей, стоимости портов мы не задаем, но мы задаем receiving port ID. И, соответственно, у нас есть указание, что вот этот вот порт будет Ethernet, допустим, нулевой, а вот этот порт Ethernet первый. И тогда мы скажем, что лучше будет та BPDU, которую мы принимаем интерфейсом Ethernet нулевым. То есть, sender port ID и receiving port ID именно в таком порядке проверяются. Запомните, пожалуйста, вот этот вот алгоритм, в каком порядке вы проверяете, какие бы подушки будут лучше, какие хуже. Сначала root bridge ID, потом root pass cost, может быть полный, может быть только то, что в подушке написано, sender bridge ID, sender port ID и receiving port ID. Так, про таймеры. Есть таймер, соответственно, как часто отправлять BPDU-шки. Задается hello time на корневом коммутаторе.

Дальше он начинает рассылать BPDU-шки с указанием своего hello time. И этот hello time заимствуется всеми остальными узлами. То есть, даже если вы сконфигурируете hello timer на каком-то конкретном узле в значение, которое отличается от rootового, все равно по факту эффективный hello time будет браться с рута. Это то, как часто отправлять BPDU-шки на интерфейсах. Задается, как уже говорилось, он в долях 256-х долях секунды. Поэтому, если вы указываете, что там значение, которое вы указываете в двухбайтовое поле будет 256, это не 256 секунд, а 256-х, 1 256-х долей секунды. То есть, одна секунда. Если вы записываете это в двухбайтовое поле, то, соответственно, вот у нас в старший байт записывается количество секунд, в младший байт записывается количество фракций секунды. Дальше. По поводу hello timer вы можете задать hello timer,

который дробный, который будет меньше, чем 1 секунда. Есть нюанс, который в стандарте прописан, что получатель не обязан обрабатывать hello timer дробные. То есть, он как минимум обязан обрабатывать целочисленные, целосекундные таймеры. Но гранулярность, с которой он будет обрабатывать этот таймер, вот он, она может быть разной, и она не стандартизирована. И в стандарте написано, что hello time гарантированно поддерживается фактически секундный. И многие вендоры, они работают только с целочисленными таймерами, то есть целосекундными. Вы можете сказать, что таймер у вас будет 1 секунда, или 2 секунды, или 3 секунды. Поэтому по факту из 2 байт, которые там будут, в младший байт записываете 0, а в старший байт вы записываете количество секунд. Например, 2. Это будет, на самом деле, число 512. 0x200. Вот так вот. Так. Hello time понятно. Как часто отправлять hello пакеты на интерфейсах?

Forward delay. Это время, в течение которого у вас информация в подушках передается от любого коммутатора в топологии до любого другого. То есть, если у вас информация от рута начинает разбегаться, то в любом случае эта информация за время forward delay добежит до всех коммутаторов в сети. Более того, если какой-то коммутатор в сети начнет рассылать какую-либо информацию, вот за forward delay time эта информация точно разбежится по любой траектории до любого другого участника. Вот. да. Тоже двухбайтовое значение. Давайте таймер по умолчанию разберем. Hello timer по умолчанию как раз 2 секунды, forward delay таймер по умолчанию 15 секунд. Forward delay будет считаться дважды. То есть, он дважды применяется при стандартной работе Spanning Tree. Как вы, возможно, помните, при перестроении

топологии мы сначала блокируем коммутацию на порту, на всех портах, а потом постепенно разблокируем коммутацию на этих портах. Но перед тем, как разблокировать коммутацию, мы включаем процедуру MacLearning. И, соответственно, первый раз таймер forward delay мы говорим, что мы блокируем коммутацию и не выполняем MacLearning на порту в течение вот этого forward delay таймера 15 секунд. А потом мы включаем MacLearning на порту, но по-прежнему блокируем коммутацию. Поэтому сначала 15 секунд и потом еще 15 секунд. Так, hello timer разобрали, forward delay разобрали. Это, соответственно, время, в течение которого информация передается. И этот таймер forward delay нужен на каждом свече для того, чтобы понимать, насколько запускать процедуру блокирования вообще любой активности на порту и насколько запускать процедуру MacLearning при выключенной коммутации. когда вы рассылаете BPD-ушки, вы пересылаете

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

приходить до вас перед тем, как объявить смену топологии. Этот срок будет называться max age. Пардон, max age. То есть, это срок, до которого может дожить BPD-ушка. Если вдруг последнюю BPD-ушку вы получили от рута за время больше, чем max age, то вы говорите, окей, значит, от соседа мы перестали принимать BPD-ушки. Это означает смену топологии. Мы перестали возможность иметь добраться до рута, поэтому нам нужно произвести перевыборы. Возможно, в той части сети, где мы остались, рут у нас будет изменен. Но есть проблема, скажем, связанная с тем, что BPD-ушки от рута до всех остальных свечей распространяются не синхронно. То есть каждый раз, когда рут посылает BPD-ушку своим соседям, информация от рута пересылается в сторону всех остальных свечей, всех остальных соседей не прямо сразу. То есть может быть такое, что вы отправили BPD-ушку одному соседу,

тот отправляет BPD-ушку другому, но не прямо сразу с какой-то задержкой, а причем задержка может быть до hello time, до двух секунд. Тот, соответственно, третий ему пересылает. В итоге у нас накапливается определенная задержка, которая указывает, что чем дальше вы от рута, тем больше времени на самом деле прошло с момента, когда эта BPD-ушка по факту, ну, мясо этой BPD-ушки, основа этой BPD-ушки, скажем, RUT под кост изначально была выпущена. То есть если у нас есть прямо RUT-RUT, вот он говорит, я RUT, я знаю, как добраться до рута за 0 копеек. Он отсылает эту BPD-ушку соседу, сосед принимает такую BPD-ушку, говорит, я знаю, как добраться до рута за, допустим, 10 копеек. Но он эту BPD-ушку, хотя сам и сожрал, но информацию из нее, что до рута можно добраться вот таким-то образом, он дальше пересылает своему соседу. И он говорит, я знаю, как добраться до рута за 10 копеек. По факту он говорит, я знаю, как добраться до рута. Можно это сравнить с протоколом каким-то дистанс-векторным. То есть, например, с RIP-ом

или с EJRP. Когда у нас приходит какой-то маршрут на наш роутер, мы говорим, о, мы знаем, как добраться через соседа до какой-то сетки, мы рассказываем про эту сетку своим соседям. То есть, мы, получается, ставим в таблицу маршрутизации какой-то маршрут и начинаем его рассылать дальше. Равно и информация про доступность рута может быть сравнена с этим механизмом. То есть, у нас от соседа пришло указание, что про рута что-то известно, что вот рут такой, что добраться до него стоит столько-то. И, соответственно, мы ее дальше используем сами, ставим ее в кавычках в таблицу маршрутизации. То есть, записываем эффективный рут-паскост и пересылаем дальше, за сколько мы знаем, как добраться до рута. И получается, что если рут рассказывает про то, что он известно ему, как, что он сам рут, что он знает, как до самого себя добраться за 0 копеек, эта информация начинает передаваться сначала одному соседу, здесь может быть определенная задержка, потом другой сосед отправляет эту информацию третьему. Здесь задержка будет

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

срок, который уже прожила эта BPD-ушка в его представлении. На самом деле он там прибавляет единичку к тому MessageH, который он получил. То есть он говорит, пришла BPD-ушка про 0 копеек, как можно добраться до root-а, он говорит, окей, я рассказываю, что я знаю, как добраться до root-а, и MessageH в той информации, как добраться до root-а, это 1 копея, 1, ну, типа, секунда. Дальше следующий свитч передает эту информацию дальше, говорит, я знаю, как добраться до root-а, но мне рассказали, как добраться до root-а, и там бы BPD-ушка прожила уже 1 секунду, поэтому я добавляю еще 1 секунду и пересылаю дальше эту информацию. Вот каждый свитч добавляет 1 секунду к эффективному MessageH. И когда какой-то свитч в цепочке говорит, я принимаю информацию и MessageH там указан, например, 7, а MaxH указан, например, 20, это по умолчанию как раз таймер, 20 секунд, то, соответственно, до 20 секунд мы считаем не с единицы, а начиная с вот этого как раз MessageH. Если вдруг сосед перестает

присылать нам BPD-ушки, мы говорим, окей, мы запускаем таймер 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 20, если за эти 13 секунд мы не получаем новую BPD-ушки от соседа, мы говорим, сосед перестал присылать нам информацию про root-а, это значит, что root сдох или до root-а мы теперь добраться не можем, следовательно, мы обязаны объявить перевыборы. Поэтому по факту получается, что когда мы говорим, что у нас случилось изменение в топологии, это более-менее все одновременно свечи будут говорить, у нас случилось изменение в топологии, у нас перестал быть известен root. MaxH задается, соответственно, рутом, сколько секунд должно пройти с момента получения последней информации о доступности root-а. И MessageH, это вот сосед, говорит, сколько по факту надо использовать начальное значение таймера для того, чтобы досчитать до MaxH, если вдруг мы ничего нового

не присылаем от root-а. Вот, такие вот четыре таймера есть в Spanning3. Ну, основные, понятное дело, HelloTime и ForwardDelay. Их надо знать, опять же, как ученаж. MessageH, MaxH, можете разобраться, как они работают, если вдруг будете разбираться, но на экзамене вряд ли по ним будут вопросы. Дальше. Если говорить про медленный Spanning3, каждый порт в активной топологии, то есть в топологии Spanning3 имел одно из пяти состояний. Первое состояние, если у нас есть какой-то физический порт, мы можем сказать, что на этом порту Spanning3 не работает. Spanning3 не работает либо потому, что мы на нем явно выключили Spanning3, либо потому, что сам порт лежит в дауне, и, соответственно, состояние будет disabled. То есть на каждом конкретном порту, если вдруг Spanning3 на этом порту не работает почему-то, то состояние будет disabled. Продолжительность такого состояния неограничена долго, пока вы не включите порт или не включите

Spanning3 на порту. На выключенном порту в Spanning3 не выполняется коммутация, не выполняется McLearning. То есть если у нас есть живой порт, и мы говорим выключаем этот порт совсем целиком, то, естественно, там не ведется коммутация, там не ведется Самоклёрнинг. Порт не работоспособен. Может быть такое, что вы, соответственно, выключите порт самостоятельно ручками, и тогда вы должны будете включить порт, опять же, ручками. Когда это произойдет, заранее неизвестно. Поэтому состояние стабильное, disabled. Ну, с ним все просто. Я предлагаю дальше его уже всерьез не воспринимать, поэтому просто игнорируем и оставляем только четыре следующих состояния. Первый из них будет блокинг. На заблокированном порту вы получаете бы подушку вкусную, вкуснее, чем вы могли бы сами отправить, но недостаточно вкусную. На каком-то другом порту вы получаете бы подушку лучше. То есть эта петля, коммутация в таком порту не осуществляется. Если какие-то кадры приходят из-под каких-то MAC-адресов, вы эти кадры просто выкидываете. MAC-лёрнинг из этих кадров не происходит.

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

то в этом случае состояние порта будет нормальный фарвардинг, это стабильное состояние. Коммутация на таком порту будет осуществляться, и MAC-лёрнинг на этом порту тоже будет осуществляться. Если вы объявили все-таки смену топологии, то есть что-то произошло, либо новый порт добавился, либо root перестал откликаться, либо еще что-то, то в этом случае каждый порт у вас переходит в состояние лисенинг. И в этом состоянии лисенинг вы проверяете на порту, есть ли петля или нет. Состояние лисенинг вы проводите в течение формы R-дилай таймера. Коммутация на порту не осуществляется, MAC-лёрнинг на порту не осуществляется. То есть через этот порт проходят только спаринг-тришные кадры, проходят всякие кадры протоколов, которые некоммутируемы. Это SEDP, LLDP, VTP, бла-бла-бла. То есть все вот эти протоколы, которые направляются напрямую на процессор и не направляются на матрицу коммутации, они здесь нормально будут работать. И в течение форвард-дилей таймера вы находитесь, ожидая получения чужих BPD-ушек.

То есть важное самое в состоянии лисенинг – это не получить BPD-ушку, в которой будет сказано, что root находится где-то дальше от нас. Если вы не получаете BPD-ушку, в которой кто-то скажет, что он ближе к root, чем мы, то есть что root где-то далеко, то в этом случае мы будем считать себя root-ом или мы будем считать себя designated bridge-ом. Ну, соответственно, в любом случае мы этот порт потом будем разблокировать. А вот если там придет BPD-ушка, то мы должны будем определить, BPD-ушка, которая пришла, это будет самая вкусная BPD-ушка среди всех портов или не самая. Но в любом случае мы слушаем чужие BPD-ушки, мы сами ничего в этот порт особо боевого не отправляем, отправляем только свои BPD-ушки и ждем BPD-ушки чужие. Не скажет ли кто-то, что он находится ближе к root, чем мы. Дальше, спустя форвард-дилей таймер, вы переходите в состояние learning и делаете примерно то же самое, что в состоянии listening, за одним исключением, что на этом порту происходит MacLearning. И часто возникает вопрос, что за херня?

То есть чем listening отличается от learning, помимо того, что в одном случае мы MacLearning ведем, а в другом нет. Какая логика в этом? Логика следующая. Если у нас есть какая-то топология в сети, вот это вот облачко, наша внутренняя сеть, тут какие-то коммутаторы в цепочке находятся, и у нас на одном коммутаторе случилась какая-то беда, случилось что-то, и, соответственно, он начинает рассылать информацию про то, что у нас случилась беда, рассказывает, что у нас топология чейндж, соответственно, надо заблокировать все порты, перевести все порты в listening, и информация про топология чейндж рассылается по всей сети, и время, в течение которого рассылается эта информация, может быть вплоть до форвард-дилей таймера. То есть может быть такое, что в одном углу сети у нас что-то произошло, а в другом углу сети узнают про это только спустя форвард-дилей, там 15 секунд. Когда на одном из коммутаторов происходит топология чейндж, он у себя сразу блокирует все порты, сразу переводит все порты в listening, начинает читать форвард-дилей. И к моменту, когда он понимает,

что его состояние listening закончилось, он знает, что все-все-все коммутаторы точно как минимум сблокировали свои порты. Но, соответственно, если вдруг вы объявили состояние listening, и начинаете рассказывать, что у вас что-то произошло, и где-то в дальнем углу сети про это узнают только через 15 секунд, то когда вы закончите свое состояние listening, там в том дальнем углу только начнут состояние listening. И еще состояние listening у них будет продолжаться 15 секунд. Поэтому нет смысла рассылать боевые кадры в такую сеть, потому что там с той стороны точно заблокирует кто-то может быть. Поэтому в состоянии learning вы ждете, чтобы у всех остальных состояние listening прошло, чтобы хотя бы они запустили у себя какую-то базовую активность, которая будет не полностью выбрасывать все приходящие кадры, а хотя бы что-то с ними делать, хотя бы learning вести. То есть когда вы включаете состояние listening, вы говорите, мы начинаем рассылать Topolage Change по ПДУ,

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

мы просто пополняем таблицу адресов. Поэтому два раза forward delay считается именно для того, чтобы адаптироваться под ситуацию вида либо мы в ближнем углу сети, а кто-то есть в дальнем, и надо подождать, пока он узнает про то, что надо объявить смену топологии, либо, соответственно, мы в дальнем углу, а кто-то, кто уже начал смену топологии, вот, что он уже закончил свои два раза forward delay таймеры и начал боевой forwarding. Поэтому мы знаем, что в первой половине forward delay таймера точно никакие боевые кадры мы обрабатывать не должны, а во второй половине forward delay таймера мы, соответственно... Ой, так, животное, уйди, простите. Да, во второй половине forward delay таймера мы понимаем, что если кто-то присылает нам боевые кадры, то, соответственно, эти боевые кадры уже заведомо нормальные, заведомо не приходят из петли. Так, ну, в общем, да, как-то так.

По умолчанию hello timer 2 секунды, forward delay 15 секунд применяется дважды, max age 20 секунд, время, в течение которого вы храните BPD-ушки, полученные на порту. BPD-ушки, полученные на порту от, соответственно, свеча, который ближе к руту, чем вы, и который присылает вам информацию о доступности рута. Max age — это время не столько, сколько вы прям помните, а возраст, до которого вы будете досчитывать BPD-ушки, которые к вам приходят о том, что рут существует. Соответственно, вы начинаете считать от message age. Это не таймер message age, это указание просто, сколько прожила BPD-ушка, которые к вам приходят, начиная с момента, когда рут ее отправил самому первому свечу в топологии. Если вы сами рут, то вы указываете message age 0. Если вы не рут, то вы получаете информацию от кого-то, возможно, от рута, и прибавляете единичку, отсылаете дальше message age на единичку больше во всех BPD-ушках на своих диссигментных портах.

Эти таймеры взялись не случайно. Они рассчитаны по некоторой достаточно сложной формуле. И формула исходит из того, что в любой совершенно произвольной сети, насколько бы вы сумасшедшими в сети предприятия ни были, у вас вряд ли будет совсем какая-то жуткая гирлянда вида. Много-много коммутаторов соединяются по цепочке один с другим. То есть если у вас вот такая вот штука будет, много-много-много-много коммутаторов прям по цепочке соединяются, то Spanning 3 в этой сети работать будет не совсем корректно. Он предполагает, что максимальное расстояние между любыми коммутаторами не превосходит 7 прыжков между ними. То есть вот 1, 2, 3, 4, 5, 6, еще один, 7. То есть 8 коммутаторов могут пересылать друг другу информацию. Каждый прыжок занимает до 2 секунд. Поэтому если у вас 7 коммутаторов в цепочке, каждый прыжок до 2 секунд, здесь 2 секунды, здесь 2 секунды, 2, 2, 2, 2, 2. 7 раз по 2 секунды дает 14 секунд.

Плюс еще немножко времени занимает обработка каждой BPDU. То есть если вдруг так получится, что мы получили BPDU на порту от RUT, немножко ее обработали, поняли, что до RUT стоит добраться вот столько, дальше начинаем BPDU отсылать на своих интерфейсах. И так получилось, что мы вот только-только-только отправили предыдущую BPDU, поэтому мы должны ждать следующий hello timer, следующие 2 секунды. И вот в самом неудачном раскладе, если у вас максимальное количество коммутаторов топологии между двумя точками в сети, это 7 коммутаторов, время, в течение которого будет информация от одного куска сети до другого добираться, вот оно не будет превосходить forward delay timer. Это любой в Spanning 3, у которого таймер есть, вот они вот такие вот по умолчанию. Но опять же, все зависит от конкретного вендора, но мне про вендоров, у которых умолчание другие, честно говоря, неизвестно. Дальше.

Максимальный диаметр сети 7 коммутаторов, максимум bridge transmit delay 1 секунда. Если у вас тормозные коммутаторы, они могут обрабатывать BPDU за большое время. То есть может быть такое, что вы получаете BPDU, и дальше вам ее надо прочитать, понять, что в ней root bridge priority вектор, он, соответственно, будет какой-то конкретный, возможно, лучше, чем ваш. Соответственно, вы должны поменять root, а вы должны пересчитать root path cost. Все это делается на центральном процессоре. Центральный процессор на свечах может быть очень-очень слабенький, и он может делать это очень долго. Ну вот максимальное время, которое дается по стандарту на то, чтобы подумать, почесать животик, подумать еще раз, запустить центральный процессор, это вот как раз одна секунда. Maximum bridge transmit delay. И когда вы формируете BPDU, максимум BPDU transmission delay,

одна секунда, это вот сколько в среднем вы будете отправлять каждую BPDU на интерфейсе. Если максимальный hello timer у нас две секунды, то, скорее всего, BPDU в среднем будет отправляться за задержкой в одну секунду. И максимум message age increment – это вот одна секунда, сколько к каждому message age мы будем добавлять времени жизни BPDU, когда принимаем BPDU с одной стороны про рута и отправляем про доступность рута BPDU в другую сторону. Ну, по умолчанию как раз одну секунду и добавляем. Вот. Исходя из того, что у вас сеть вот так вот устроена, соответственно, таймеры 2 секунды hello time, 15 секунд forward delay и 20 секунд max age, они должны удовлетворять в вашей сети любым изменениям, которые в ней могут произойти. Есть нюанс, который заключается в следующем. Если вдруг у вас есть, как это назвать,

если вдруг у вас есть более компактная сеть, то есть она не совершенно произвольная, вы знаете, что у вас между любыми двумя точками сети, даже если произойдет отказ какого-то линка, не 7 коммутаторов в цепочке, а, например, 5 или 4, вы, соответственно, можете таймеры в этом случае подкрутить. Во-первых, вы можете сказать, что hello time у вас будет не 2 секунды, а 1 секунда. Или даже вы можете поменьше сделать, например, сказать полсекунды или четверть секунды, или даже 1 256 секунды. Здесь есть нюанс, я про него сейчас отдельно расскажу. Вот. Второй момент. Вы hello time можете подкрутить, вы можете forward delay подкрутить. То есть вы можете, опять же, сказать, что время, в течение которого коммутаторы обрабатывают вашу БПДУшку на современных железках, оно ничтожно маленькое. Поэтому, если у вас 5 прыжков между коммутаторами, или 4 прыжка, если у вас hello timer 1 секунда, то вы можете сказать, что за 6 секунд информация от любой точки сети до любой другой точки сети точно дойдет. Поэтому вы можете сказать, что forward delay у вас будет не 15 секунд, а 6. И поэтому, если вдруг у вас будет какой-то порт работать в режиме совместимости

с медленным Spanning 3, он вам будет коммутацию на порту выключать не на 30 секунд, а на 12. Это уже некоторая выгода. Не сказать, чтобы 12 секунд было прям принципиально лучше, чем 30 в современном мире, когда за каждую секунду идет борьба, но, тем не менее, все-таки можно немножко ускорить. Max Age нет смысла особого изменять, потому что, если вдруг вы будете ориентироваться на то, что до 20 секунд вы можете курить бамбук, пока у вас Spanning 3 не просылают БПДУшки, ну, мне кажется, что здесь все будет очень плохо. Но, тем не менее, да, если вдруг у вас случается непрямой отказ, и линк остается живой, а БПДУшки не ходят, то в этом случае можете подкрутить. Так, по поводу того, что хотел рассказать про HelloTimer меньше секунды. Есть нюанс. Как уже было сказано, по стандарту коммутатор не обязан обрабатывать БПДУшки, если вдруг в них написан HelloTimer какой-то кривой с его точки зрения.

То есть он может сказать, что коммутатор не принимает БПДУшки, если вдруг в них написан таймер, который он не умеет понимать. В частности, это будет работать с циской. Например, есть коммутаторы Huawei. Они указывают таймеры какие угодно, и они будут по факту работать с таймерами гранулярностью, по-моему, 0,01 секунды, что ли. То есть вы можете сделать так, что у вас с одной стороны есть коммутатор Huawei, а с другой стороны у вас есть коммутатор Cisco. И, соответственно, у этих коммутаторов есть какие-то BridgeID. Вот, допустим, для определенности скажем, что у нас у Huawei rootbridgeID... Почему rootbridge? Просто BridgeID единичка, у Cisco двоечка. В нормальной ситуации, соответственно, Huawei должен стать рутом, а Cisco должна подчиниться и сказать, окей, Huawei будет рутом. Но что будет происходить, если у нас у Huawei будет выставлен таймер в половину секунды? Он будет отправлять BPDU, в которой скажет Hello, таймер, 1,2 секунда.

Cisco получит такую BPDU и скажет, это не валидная BPDU. Я не обязан обрабатывать BPDU с кривыми таймерами. Поэтому я не считаю это правильной BPDU. Я ее выкидываю. Соответственно, Cisco не получает со своей точки зрения валидных BPDU. И говорит, о, ну тогда я буду считать себя рутом и отправляю BPDU, соответственно, с указанием, что она root. И HelloTimer там будет, например, 2 секунды. Но Huawei не принимает эту BPDU. Он говорит, я не считаю, что эта BPDU хорошая. Она inferior по отношению к моей. Поэтому Huawei посылает свою BPDU с криками «Я диссигнает бридж». Cisco посылает свою BPDU с криками «Я диссигнает бридж». И у вас получается 2 диссигнаета бриджа в сети. Вот. Если у вас, например, 2 провода будут таких, ну там будет у вас петля. Поэтому будьте предельно осторожны. И постарайтесь включать дробные таймеры только в условиях, когда вы точно знаете, что все оборудование поддерживает дробные таймеры. По стандарту не любые железки обязаны поддерживать дробные таймеры.

Хотя дробные таймеры вы можете задать, и некоторое железо будет их поддерживать. Из числа того, что поддерживает их, Arista поддерживает, Huawei поддерживает, D-Link не поддерживает, Cisco не поддерживает. То есть Cisco поддерживает только таймеры целочисленные. Если вы будете на руке задавать HelloTimer кривой, вы с очень большой вероятностью, если у вас гетерогенная среда, получите петлю. Поэтому не делайте этого. Далее. Что у нас тут еще есть? Если у нас есть порты, которые стабильно работают, с ними все в порядке. То есть они либо заблокированы, либо они в forwarding и разблокированы. Разблокированный может быть порт, который мы обсуждали, соответственно, что он либо получает самую вкусную бопадушку из числа тех, которые к нам приходят, либо если у нас есть порт, который мы считаем designated, то мы его сами разблокируем и сами отправляем в него данные. Если у нас есть порты, которые находятся в состояниях listening и learning,

то они находятся в этом состоянии временно. Каждое состояние длится в течение 15 секунд по умолчанию. Или если вы меняете forward delay timer, то будет находиться forward delay timer в течение этого срока. В состоянии listening вы ожидаете, что все коммутаторы в топологии запустят пересчет топологии. То есть вы спустя 15 секунд после того, как вы объявили пересчет топологии, может быть уверены, что все коммутаторы как минимум начали пересчет топологии тоже. А возможно даже уже закончили. Ну, соответственно, поскольку вы не уверены, что точно все коммутаторы начали пересчет топологии до того, как закончится forward delay timer, то ни коммутацию вы не осуществляете, ни learning вы не осуществляете так же. Потому что если вдруг какие-то кадры приходят, пока вы сидите в состоянии listening, возможно, они приходят от узлов, которые еще не запустили смену топологии. Возможно, они, соответственно, приходят с портов, которые потом надо будет заблокировать. Поэтому learning вы не производите. Вы переходите в listening, вы все порты блокируете,

вы влашаете всю твоблицу MAC-адресов, и дальше вы ждете 15 секунд, что все остальные последуют вашему примеру. Некоммутируемые кадры через интерфейсы проходят, но, соответственно, только они и проходят. Spanning-3-шные BPD-ушки вы можете отправлять или принимать. В норме вы отправляете, но если вдруг кто-то пришлет вам более вкусную BPD-ушку, то вы начнете принимать чужие BPD-ушки, сами уже отправлять не будете. После того, как listening заканчивается, вы понимаете, что точно все порты, все узлы в сети завершили начало перехода в измененную топологию. То есть все коммутаторы в сети как минимум запустили состояние listening. Вы, в принципе, готовы коммутировать кадры. То есть вы, в принципе, говорите, у нас все порты на всех свечах выключены или уже даже включены. Но вы не осуществляете коммутацию кадров, потому что на самом деле здесь неправильно, не совсем корректно написано «возможно возникновение петли».

Нет, невозможно возникновение петли. Здесь не честно это говорить. Более правильно сказать, что коммутация не осуществляется, потому что нецелесообразно выполнять коммутацию. Может быть такое, что вы отправляете какие-то кадры с других свечей на наш свеч в состоянии learning, и поэтому вы производите наполнение таблицами акадресов, актуальной информацией. Вы понимаете, что если какие-то кадры приходят в состоянии learning на ваш свеч, то они приходят точно из-под тех портов, тех коммутаторов, которые уже завершили и listening, и learning. Не может быть такое, что в состоянии learning вы будете получать кадры от другого свеча, который еще не перешел в измененную топологию. Нет, он уже перешел, он уже прошел listening, он уже прошел learning, он уже включил forwarding, а вы еще это не сделали со своей стороны. Поэтому вы точно знаете в приходящих кадрах, что маки приходят правильно из-под правильных портов, поэтому вы наполняете таблицу мак-адресов правильными маками, но при этом сами кадры вы еще не отправляете, не потому что возможно возникновение петли, а потому что кто-то еще вероятно сидит в listening.

Может быть такое, что вы запустили listening у себя и начали рассылать информацию о том, что топология изменилась соседям, и соседи, может быть, свой listening запустили позже. У них смещение относительно вашего начала listening, их listening может быть на 15 секунд, на forward delay timer. Поэтому когда вы со своей стороны переходите в learning, кто-то еще может сидеть в listening, и нет смысла посылать им кадры, когда они со своей стороны коммутацию блокируют. Поэтому в learning вы не посылаете кадры никуда, вы их не коммутируете. Но если какие-то кадры к вам приходят, то вы говорите, это кадры от тех, кто уже прошел и listening, и learning, поэтому это кадры точно из-под правильных портов приходят. Ну и, соответственно, если вы используете таймеры по умолчанию, то при блокировке порта вы запускаете первое forward delay timer 15 секунд в listening, потом еще 15 секунд в состоянии learning, и только после этого на порту вы разблокируете коммутацию и переводите порт в forwarding. Если вы будете изменять эти таймеры, то при условии, что вы поставите какие-то дробные таймеры,

вы можете значительно ускорить разблокировку портов. То есть вы можете сказать, что там таймеры выставляем в минимально возможные значения, и тогда там за действительно фракцию секунды, за долю секунды вы получите проход всех этих состояний. То есть можно сказать, что там, например, hello time у нас будет 1 256 секунды, forward delay будет 6 256 долей секунды, и там через 12 256 долей секунды мы, соответственно, будем разблокировать коммутацию на порту. Но, опять же, если вы выставляете дробные таймеры, то вы должны быть уверены, что вообще все узлы в сети поддерживают такие дробные таймеры. Если вдруг в сеть добавится какой-то узел, который такие дробные таймеры не поддерживает, что у вас не случится никакой катастрофы. Поэтому если у вас вся сеть построена на условных Huawei, вы выставите дробные таймеры, то все хорошо. Но если у вас есть сеть, в которой есть Huawei, и когда-нибудь может добавиться циска, в этом случае будет все плохо. Поэтому надо с очень большой осторожностью

изменять таймеры относительно тех, которые по умолчанию есть. И меньше, чем 1 секунду ставить, на самом деле, особо смысла уже нет. Forwarding, blocking, стабильное состояние. В forwarding осуществляется коммутация, осуществляется learning, отправляются, принимаются служебные протоколы, кадры. Ну, то есть те самые CDP, LLDP и прочее. Ну и, соответственно, BPD-ушки либо отправляются, либо принимаются. В состоянии blocking мы не осуществляем коммутацию, мы не ведем MacLearning. Все кадры, которые принимаются на порту, мы отбрасываем без каких-либо изменений. Мы не осуществляем в заблокированные порты коммутацию. То есть когда у нас приходит какой-то кадр, мы направляем его на все порты, кроме некоторых. И вот в число некоторых, безусловно, включаются порты, которые заблокированы в Spanning 3. Кадры некоммутируемых протоколов отправляются и принимаются на этом порту без каких-либо изменений.

То есть Spanning 3 влияет только на логику коммутации. Не на отправку вообще какой-либо информации на порту, а вот именно на логику коммутации. Периодически здесь пробегал термин смена топологии. И это на самом деле вполне определенная вещь. Это не просто такое, что что-то у нас там в сети такое произошло. Это событие, которое генерируется на основании одного из нескольких признаков. Первое – это если вы работаете в медленном Spanning 3, и у вас из-под Designated порта приходит Topology Change Notification. Что такое Designated порт? Это порт, которым вы смотрите в какой-то сегмент, в котором находятся все остальные узлы, которые находятся дальше от рута, чем вы. Поэтому если там есть какие-то коммутаторы, которые находятся дальше от рута, и они получают BPD-ушки от вас, то они на вас смотрят либо рутовым портом, либо альтернейтом. И, соответственно, если там приходит ваша BPD-ушка им, они знают, что это BPD-ушка рутовая, они знают, что это BPD-ушка самая выгодная для них.

Вот они в этом случае, если вдруг будет изменение топологии какое-то у них, они отправят вам Topology Change Notification, и вы со своей стороны поймете, что у вас случилось изменение топологии, и на него будете каким-то образом реагировать. То есть оповестите об этом своих соседей, своего рута и так далее. Либо, если вы раньше рутом не были, а сейчас стали. То есть, например, в ситуации вы получали рутовую BPD-ушку, а сейчас рутовая BPD-ушка у вас протухла, и вы говорите, окей, тогда я буду считать рутом себя. Это тоже смена топологии. Если у вас есть порт, который меняет свое состояние, раньше он был forwarding, а сейчас он стал blocking. То есть у нас раньше был порт, на котором мы отправляли BPD-ушки, а теперь он стал заблокирован, если мы приняли какую-то чужую BPD-ушку и порт со своей стороны заблокировали. Это тоже смена топологии. Мы раньше не знали про то, что у нас каким-то образом можно добраться до рута альтернативным, а теперь знаем. Либо, если у нас есть порты, которые внезапно получают новую роль designated,

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

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

Поэтому, как только у нас генерируется так называемая смена активной топологии, у нас раньше совокупность портов, которыми мы смотрели на какие-то соседние сущности, на клиентов или на соседние свечи, или на что-то еще. Вот она изменилась. У нас изменились порты, которые участвуют в Spanning 3. То мы называем это сменой активной топологии, Active Topology Change, и мы делаем следующее действие. Мы начинаем очищать таблицы MAC-адресов. То есть мы говорим, что у нас смена топологии обязательно сопровождается очисткой таблицы MACов, потому что непонятно, какие порты потом какие роли будут получать после смены топологии. Мы объявляем перевыбор рута. Может быть такое, что рут у нас выберется какой-то новый после того, как топология изменилась. Может быть, выберутся другие рут-порты. Может быть, выберутся другие блок-порты. Поэтому MAC-и у нас те, которые были, они заведомо устарели. Мы начинаем отсылать BPD-ушки на все порты.

То есть мы считаем себя рутом. Мы считаем, что у нас все порты designated. Мы начинаем на всех портах отсылать BPD-ушки. Ну и далее по списку. Так. Если говорить про медленный Spanning 3, который вот 802.1D 90-го года, то работает он следующим образом. Если у нас возникала какая-то смена топологии на одном свече, то отсылалась Topology Change Notification, BPD-ушка в сторону рут-порта, если таковой имелся. И когда такое Topology Change Notification, помните, это BPD-ушка без содержимого, отправлялась на вышестоящий свеч, который ближе к руту находился, приходил ответ. Я тебя понял, я тебя услышал. Отправлялась ответная Configuration BPD-у с указанием флажка Topology Change Acknowledge. Это самый последний флажок в поле флагов. Дальше. Мы получили Topology Change Notification на абонентском порту, на диссигнатором порту, поэтому здесь у нас тоже генерируется Topology Change. Мы отправляем Topology Change Notification в сторону рута

на своем рут-порту, получаем в ответ Topology Change Acknowledge. Дальше вот Topology Change, событие Topology Change, разбегается на все порты, на все свечи в сторону рута, рано или поздно добегает до рута. Понятное дело, что вот это вот время, в течение которого Topology Change идет в сторону рута, оно может быть явно не больше, чем Forward Delay. Дальше. После того, как мы получаем Topology Change события, мы очищаем свои filtering database, то есть мы говорим, что все эти записи в таблице MAC адресов, которые у нас есть, у них же есть какой-то возраст. Мы не просто обнуляем всю таблицу, мы говорим, у этих записей есть возраст, и мы проставляем им возраст, равный Forward Delay. То есть в любом случае, если мы будем потом говорить, что у нас все порты проходят дважды Forward Delay, Listening и Learning, то, соответственно, все MAC, которые там будут, они точно за дважды Forward Delay таймер протухнут. И, соответственно, aging time мы выставляем Forward Delay 1,

поэтому к моменту окончания пересчета топологии таблица MAC у нас обнулится. Ну и, соответственно, дальше. После того, как рут понял, что случилась смена топологии, он начинает рассылать BPD-ушки с флагом Topology Change. Более того, на самом деле, вы рассылаете эти BPD-ушки дальше и вниз по топологии, поэтому любые узлы, которые находятся в сети, любые коммутаторы, они узнают о том, что случилась смена топологии за время не больше Forward Delay таймера. Не просто рут узнает про то, что у нас Forward Delay таймер, через Forward Delay таймер, о том, что Topology Change Нинтификация до него дошла. А вообще все узлы получат Topology Change от рута за время не больше Forward Delay. Рут, получив Topology Change Нинтификация, начинает рассылать Topology Change. Ну и, соответственно, коммутаторы, которые получают Topology Change Нинтификация, тоже начинают рассылать на все свои designated порты Topology Change.

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

медленным Spanning 3. Но за счет чего мы добавили слово Rapid в название? За счет того, что быстрый Spanning 3 не ожидает увидеть конкурентную среду. Он ожидает увидеть Point-to-Point-Link. То есть если мы говорим, что у нас коаксиалы с общей шиной остались в прошлом, что у нас есть два свеча в проводе и больше никого в этом проводе быть не может, то мы можем использовать два механизма, которые нам очень сильно упростят жизнь. Первое сообщение – вопрос-ответ. То есть если мы отправляем указание, что я считаю себя root-ом, и мы можем добавить флажок «ты не против», и мы получаем одно уведомление «я не против», мы можем сказать, что в Point-to-Point канале у нас ровно один сосед. Если кто-то прислал сообщение «я не против того, что ты будешь designated bridge-ом», то это значит, что все узлы в канале согласились, что designated bridge-ом буду я. И они designated bridge-ом уже не будут. То есть они находятся дальше от root-а, чем мы,

они с этим согласны. И мы со своей стороны можем сразу разблокировать такой порт. Если вдруг у них случится какая-то катастрофа, и они скажут, что они считают, что они находятся ближе к root-у, они пришлют BPD-ушку, скажут, не против ли я, что они будут ближе к root-у, чем мы? И, соответственно, я со своей стороны в этом случае тогда соглашусь, что да, действительно, я нахожусь дальше от root-а. Ну, то есть вот эти вот сообщения, запрос-ответ, proposal-agreement, они действительно ускоряют работу. Вы в этом случае не будете ждать hello time, сколько времени отправить сообщение соседу. Вы не будете ждать forward delay time для того, чтобы все соседи точно синхронизировали свое состояние с вами. А вы будете за единицы миллисекунд синхронизировать свое состояние на двух коммутаторах. Вы отправляете proposal, и вам сразу приходит agreement. Сразу – это значит, что вот прям сразу. Если у вас быстрый процессор на соседнем свече, вы ответ получите за время меньше миллисекунды. Дальше.

Вторая штука, которая прям резко ускоряет работу – это появление edge-портов. Edge-порт – это такой порт, которым вы смотрите напрямую на абонента. Если вы смотрите портом напрямую на абонента, то вы можете сказать на своем свече, что не надо на этом интерфейсе проходить полноценное состояние listening, learning, forwarding, если там не приходят соседские BPD-ушки. То есть если у нас есть свеч, и на этом свече есть просто обычный абонент. Вот. Как мог нарисовать абонента. Так нарисовал. Мы посылаем туда BPD-ушку, и мы не принимаем BPD-ушки в ответ, мы не ожидаем BPD-ушки в ответ. То есть если у нас все хорошо, просто там сидит обычный компьютер. Когда у нас поднимается интерфейс, смотрящий на обычного абонента, он, скорее всего, станет designated. Классический ванильный Spanning 3. На это отреагирует смена топологии. Он скажет, у нас изменение активной топологии, у нас появление нового designated порта, давайте устраивать революцию. Логика подсказывает, что в коммутируемом Ethernet,

где у нас везде физическая point-to-point топология, появление нового designated портов на обычных абонентов – это норма. И поэтому, если у вас есть designated порт, на котором вы, как администратор, обещаете, что будет сидеть обычный абонент, вы можете сказать, во-первых, это не смена топологии, если у нас поднялся новый designated порт, который смотрит на абонента. Во-вторых, вы можете сразу включить этот порт, вы можете сказать, мы не будем проводить состояние listening и learning, нет смысла. Мы просто отправляем туда BPD-ушки. Если с той стороны находится свитч, вот вдруг, внезапно, и он не против того, чтобы мы стали designated, методом, он либо ответит нам BPD-ушкой, что я не против, и тогда мы проведем состояние, соответственно, синхронизации, мы возьмем и сделаем такое, что отправим пропозал, получим агримент и разблокируем этот порт очень быстро. Либо, если там медленный испанник 3, который получит нашу BPD-ушку, он может сказать, что он против того, чтобы мы стали designated бриджом, и тогда мы заблокируем такой порт,

ну, не заблокируем, проведем listening learning, включим этот порт в общую топологию, бла-бла-бла, либо он просто на нас будет смотреть рутовым или альтернат-портом, то есть нас это не сильно волнует. Нас волнует, будем ли мы designated или нет. Если мы объявили порт designated, и мы не получаем чужих BPD-ушек на этом порту, то, в принципе, все равно, что с той стороны будет находиться. А вот если мы объявили порт, который смотрит на абонента designated, без проведения предварительной проверки, начали отправлять туда BPD-ушки, и оттуда пришла BPD-ушка, что я хочу, чтобы ты знал, что я лучше root, чем ты, то есть в этом случае designated порт мы объявили, в общем-то, неправомерно получается. То в этой ситуации статус edge порта, с порта счищается, порт переходит в состояние listening, потом learning, потом forwarding. Если у вас меняется edge порт, он становится designated портом, переходит forwarding, то это не вызывает topology change. Это очень быстрая штука, потому что в реальной сети

с коммутаторами у вас нормой будет, то, что абоненты включают свои компьютеры, у вас порт, который смотрит на них, он переходит designated. Медленный Spanning 3 не имел такой штуки. У него предполагалось, что абоненты будут подключаться все к одному и тому же порту, который всегда в API. Так. 802.1d 2004 года, то есть быстрый Spanning 3, получил роли. Роли, на самом деле, мы с вами уже прошли. Это alternate, backup, designated и root. То есть alternate, вы получаете почти самую вкусную боподушку, лучше, чем вы могли сами бы отправить, но все-таки недостаточно хорошую. Root – это вы получаете самую вкусную боподушку, лучше, чем вы сами могли бы отправить и лучше, чем любую другую, которую вы получаете на всех остальных интерфейсах. Backup – это значит, что вы получаете свою собственную боподушку, designated, вы отправляете свою собственную боподушку в интерфейс. Вот эти вот роли,

они указывают на то, почему ваш порт ведет себя так или иначе. Эти роли не напрямую коррелируют с состояниями, которые были в медленном Spanning 3. Вмс – это состояние в медленном Spanning 3 были Blocking – «Мы не осуществляем коммутацию на порту», Phorwarding – «Мы осуществляем коммутацию на порту» Listening – «Мы временно не осуществляем коммутацию, но потом перестанем». И, соответственно, Learning – «Мы временно не осуществляем коммутацию к порту, но хотя бы введем MacLearning, но скоро опять же перейдем в phorwarding». Вот пять состояний, которые были в медленном Spanning Tree, они частично сохранились. Соответственно, в быстром Spanning Tree было принято решение отказаться от вот этих вот пяти разных состояний, которые немножко указывают на то, что мы делаем, и немножко указывают на то, почему мы это делаем. И было принято разнести состояние и роли по раздельным сущностям. Соответственно, состояние в быстром Spanning Tree может быть только три. Discarding, Learning и Farwarding.

Farwarding осуществляем коммутацию, Discarding не осуществляем коммутацию, Learning промежуточное. Пока что не осуществляем, но скоро начнем. Вот. Ну, соответственно, если у вас порт был какой-то в состоянии Disabled в медленном Spanning Tree, то есть Spanning Tree на этом порту заблокировал все, потому что порт выключен, то в этом случае быстрый Spanning Tree имеет специальную особую роль Disabled, и, естественно, на этом порту Discarding мы ничего не обрабатываем, весь трафик сбрасываем, Learning не введен. Если на порту вы получаете BPD-ушку, либо чужую, невкусную, либо свою собственную Backup, то в этом случае у вас в состоянии тоже будет Discarding. Это аналогично тому, что было в состоянии медленного Spanning Tree блокинг. Вот. И, соответственно, пара Alternate Discarding или Backup Discarding соответствует состоянию блокинг. Если у вас порт находился в состоянии Listening, это означало, что вы на этом порту не получаете никаких чужих BPD-ушек, но при этом вы принимаете,

вы отправляете свою BPD-ушку, просто 15 секунд вы не осуществляете коммутацию на этом порту и не ведете Backlurning. Состоянию медленного Spanning Tree и Listening соответствует роль быстрого Spanning Tree Designated Discarding. Если вы находились в медленном Spanning Tree в состоянии Learning, то быстром Spanning Tree соответствует пара Designated Learning. То есть отдельного состояния Listening больше нет, потому что в Listening поведение устройства, поведение порта не отличается от блокировки, от Discarding. Ну и, соответственно, если у вас есть порт, который в Farwarding, то это может быть либо потому, что у вас состояние Farwarding... Это может быть либо потому, что вы Root, либо потому, что вы Designated. И будет пара, соответственно, Root-Farwarding или Designated-Farwarding указывать на то, что вы сейчас делаете и почему вы это делаете. Нужно будет запомнить состояние медленного Spanning Tree и роли и состояние быстрого Spanning Tree на экзамене. На них будут вопросы.

Далее. Когда у нас есть медленный Spanning Tree, то мы помним, что случается при смене топологии. У нас есть несколько причин, почему смена топологии может возникнуть. В их числе либо получение Topology Genesign Notification на Designated порту, либо получение роли Root-порта, либо смена Active Topology, то есть у нас переходит порт в Blocking из Forwarding или из Learning, или у нас порт переходит в Designated внезапно, хотя он таковым раньше не являлся. То есть либо мы заблокировали разблокированный порт, либо разблокировали ранее заблокированный. И после того, как у нас получалась смена топологии, мы наверх отсылали Topology Genesign Notification, и после этого Topology Genesign Обычные сообщения уже рассылали вниз на свои Designated порты. В Быстром Спанинг 3 от Topology Genesign Notification решено было отказаться. То есть если у вас случается смена топологии, то вы просто отправляете Topology Genesign на все порты, и это, соответственно, будет фактически означать, что вы оповещаете всех о том, что у нас случилась смена топологии.

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

В быстром Spanning 3 802.1.2004 года у нас обозначены три типа портов. Первый порт — это обычный порт, на котором у вас есть обычный абонент. То есть это пограничный порт. Мы такой порт сразу переводим в forwarding, Designated forwarding. Но если вдруг мы говорим, что у нас порт Jovey, значит, этот порт никогда не смотрит на соседний свитч. И если там приходит BPD-ушка, либо чужая, либо наша собственная, то есть, например, там случается петля, когда у нас есть свитч, и вот мы говорим, у нас есть провод, который смотрит напрямую на абонента. Но абонент гадкий сказал, окей, у меня есть провод, которым я получаю доступ к сети, я сейчас сделаю вот какую вещь. Я возьму, куплю маленький D-Link DIR300, поставлю его, и, соответственно, подключаюсь к нему в разрыв. Вот этот свитч под контролем администратору сети, а вот этот вот нет, его юзер сам поставил.

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

Альтернативой Edge-овому порту будет порт Point-to-Point, который одним прямым проводом, Point-to-Point проводом, смотрит на соседний свитч. То есть если у вас есть Point-to-Point порт, то в нем можно использовать ускорение Proposal Agreement. И если у вас есть, например, Cisco, то по умолчанию на портах, которые имеют полный дуплекс, Cisco предполагает, что у вас будет Point-to-Point как раз соседства. То есть Cisco ожидает, что на порту полно-дуплексным может жить свитч, но на этом порту можно пытаться использовать ускорение Proposal Agreement. Так, далее. Если у вас есть, соответственно, интерфейс, который будет полно-дуплексный, half-дуплексный, то Cisco по умолчанию назначит такому порту роль, не роль, а тип порта, shared-порт, это порт, который гипотетически может смотреть на несколько соседних коммутаторов. Не обязательно по факту смотрит, он может смотреть на несколько соседних коммутаторов. То есть может быть такое, что у вас есть свитч, и у вас есть, соответственно, толстый желтый коаксиал,

вот вы к нему подключаетесь, говорите, я же не знаю, сколько там этих соседних свитчей будет в этом самом коаксиале. Может быть, их там будет 2, может быть, их там будет 10. Поэтому Proposal Agreement там не используется, и мы фактически в таком Shared доступе будем работать по методам медленного Spalning Tree. То есть может быть такое, что у вас Cisco поддерживает быстрый Spalning Tree, вы ее переключаете в режим быстрого Spalning Tree, но из-за того, что она имеет Half-Duplex интерфейс, на котором смотрит на соседей, она там не использует механизма ускорения. Вот. Так что три типа порта. Shared смотрим на несколько соседних коммутаторов. Point-to-point смотрим не более, чем на один соседний коммутатор. Edge смотрим на ноль соседних коммутаторов. Proposal Agreement будет работать следующим образом. Вы отправляете предложение, что вы будете designated bridge-on. Отправляете вы его только в случае, если знаете, что сосед там ровно один, ну или ноль. И, соответственно, если вдруг вы отправляете сообщение, что я хочу стать designated bridge-on, и сосед говорит, я согласен, чтобы ты стал designated bridge-on, то вы определяете, кто из вас должен стать designated bridge-on, кто из вас может разблокировать свой интерфейс гарантированно за время не forward delay, а порядка 10 миллисекунд.

Ну, то есть 10 миллисекунд – это вполне реальное время. Дальше. Тот, кто хочет стать designated bridge-on, будет отправлять BPD-ушку с установленным флагом proposal. А тот, кто согласен с этим proposal, будет отправлять свою BPD-ушку inferior с флагом agreement, и при этом он указывает в этом флаге, в смысле, в этом флаге, в этой BPD-ушке designated bridge-id вместо sender bridge-id. Так. В быстром Spanning 3 есть такая штука, которая называется синхронизация. Смысл ее заключается в следующем. Там мультик запустился немножко рано. Если вы получаете proposal на порту, который вы понимаете, что должен стать рутовым, то вы говорите, отсекаем все остальные порты от области, в которой у нас работает быстрый Spanning 3. То есть вот у нас есть какая-то топология, есть у нас рут, этот рут прислал proposal.

Мы говорим, окей, этот proposal приходит от того, кого мы будем считать рутом, потому что его root bridge-id самый крутой. То же самое, на самом деле, может произойти в какой-то другой области. То есть вот этот вот коммутатор нижний тоже может сказать, я рут, и вот этот вот switch может ему поверить. Вот он в этом случае скажет, отсекаем всю остальную сеть от нового свежевыбранного рута. Но в любом случае, даже если у нас это будет происходить в нескольких точках сети, как минимум на том свече, который в итоге станет рутовым, это тоже будет происходить. Итоговый рут отправляет свою самую первую боподушку на соседние свечи. Соседние свечи говорят, окей, изолируем область, в которой у нас работали proposal agreementы. Отсекаем эту область и говорим, до тех пор, пока мы не убедимся, что у нас все внутри вот здесь вот в этой сети синхронизировано, мы не разблокируем эти порты. Но при этом мы сообщаем, окей, мы согласны с тем, что вот этот вот порт, он точно не вызовет петлю со всей остальной сетью. То есть коммутация на всех вот этих вот портах выключается, а на порту, на котором был получен proposal, мы отправляем agreement и включаем коммутацию.

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

Мы говорим, что мы отключили всю остальную сеть. На рут порт отправляется agreement. Мы не против того, чтобы ты стал designated bridge. И на designated портах, которые мы только что выключили, мы отправляем proposal, говорим, ребята, не хотите ли по-быстрому включить свои порты? Если у вас где-то в сети есть медленный свитч, он не ответит на ваш proposal, и вы говорите, окей, тогда на этом порту designated discarding, designated learning, designated forwarding, ну, то есть сколько там времени нужно для того, чтобы все это дело определить. 30 секунд по умолчанию. То есть какой-то блок в сети может разблокироваться только спустя 30 секунд или дважды forward delay timer. Но если вы говорите, что вот у нас есть обычный свитч, этот свитч быстрый, у него есть designated порты, которые edge-овые, то есть не point-to-point, не shared, мы говорим, мы получаем какой-то proposal, мы говорим, окей, синхронизация, смотрим на то, есть ли у нас какие-то транзитные designated порты, говорим, нет, у нас ни одного транзитного designated нету,

отправляем сразу agreement, что мы со своей стороны все сделали. И, соответственно, вот этот вот порт включается сразу. И абоненты этого свитча начинают получать доступ ко всей сети сразу. Дальше, если у нас какой-то другой свитч пришлет proposal agreement, мы скажем, окей, смотрим на, опять же, на все наши designated порты транзитные, и с ними, опять же, все хорошо, мы не против того, чтобы разблокировать этот порт. Если вдруг у нас вот этот вот свитч будет не поддерживать быстрый spawning 3, то, соответственно, у нас вот эта вот вся часть отвалится на, опять же, срок 30 секунд. Но если везде в сети у вас все порты размечены правильно, в частности, очень важно разметить и джевые порты, и в частности, очень правильно разметить point-to-point порты, то вот при правильной настройке, при правильной разметке быстрый spawning 3 у вас всю сеть просинхронизирует за время, там, порядка 50 миллисекунд. Так что имеет смысл действительно spawning 3 быстро использовать, если он у вас везде поддерживается. Но для того, чтобы он работал, очень и очень и очень правильно будет разметить правильно порты.

Если вы не размечаете порты, происходит следующее. К вам приходит proposal. Вы говорите, у меня есть порт, порт в API, порт designated. Чего там с той стороны есть? Непонятно. То ли там абонент сидит, то ли там, возможно, свитч какой-то сидит. Вот по умолчанию все порты на цисках получают роль point-to-point. То есть с той стороны, типа, говорит, он один сосед свитч должен быть. Вы отправляете туда proposal. Proposal, никто не отвечает, потому что там по факту компьютер. Вы неправильно разметили порт. Вместо того, чтобы пометить его и джовым, вы пометили его point-to-point. И, как следствие, на ваш proposal никто не отвлекается. И вот эта синхронизация говорит, вот этот кусок сети у нас изолирован, и пользователи по факту не получают доступ к сети. Поэтому 30 секунд вы их курите бамбук. Быстрый Spanning 3 может вам очень сильно ускорить работу, но только при условии того, что вы правильно разметите порты. Так. Теория Spanning 3-шная базовая закончилась.

То есть это мы проговорили про ванильный Spanning 3 802.1D 90-го года и про быстрый Spanning 3, тоже ванильный стандартный Spanning 3. Дальше мы будем работать с конкретными реализациями этого самого Spanning 3, причем на оборудовании ЦИСКа, у которой свое видение этого протокола, и который на самом деле классические ванильные Spanning 3 не особо поддерживает. Но, тем не менее, мы разберемся с тем, какие там есть особенности, и как там все можно будет понастраивать. Предлагаю на сегодня завершать наши студии, завтра поговорить про первый лан Spanning 3 и сделать лабу на то, как выглядит базовая настройка Spanning 3 на ЦИСКах. На сегодня все. Спасибо за внимание.