Протокол STP - состояния портов

Итак, коллеги, давайте поговорим про состояние портов, которые есть в Spanning 3. Состояния ввелись в версию протокола Spanning 3 802.1d 90-го года и до сих пор там и остаются. Но немножечко изменилось их количество и изменилось назначение этих состояний в 802.1d 98-го года. Поэтому мы сейчас с вами поговорим про изначальное состояние, а потом поговорим про то, что изменилось в Rapid Spanning 3. Итак, состояние порта в 802.1d 90-го года было 5 штук. Соответственно, этих состояний были Disabled, Blocking, Listening, Learning и Forwarding. Disabled — это стабильное состояние, в котором любая коммутация на порту невозможна. И это происходит до тех пор, пока вы не разрешите, собственно говоря, использование этого порта. 802.1d — это протокол, который описывает, как осуществляется коммутация вообще в целом. И, соответственно, любой бридж, любой коммутатор, который соответствует протоколу 802.1d, он обязан Spanning 3 гонять на всех своих интерфейсах.

Либо ожидать BPDU-шки от соседей, либо отправлять BPDU-шки самостоятельно. Вот если вы не отправляете и не принимаете BPDU-шки, то это возможно только в одном случае, если у вас порт целиком выключен. Spanning 3 на порту не работает и коммутация на порту не осуществляется. Если вы хотите, вы можете включить порт, и тогда вы ее состояние Disabled на Spanning 3 должны будете перевести в какое-то другое состояние. С этим состоянием, с Disabled, все довольно просто, поэтому мы на нем больше останавливаться не будем. Дальше перейдем к другим четырем состояниям, которые, собственно, нас будут интересовать. Самое первое состояние, которое у нас здесь есть, это состояние Blocking. В состоянии Blocking вы обнаружили петлю и с порт заблокировали. Состояние стабильное, продолжается до тех пор, пока у вас не изменится топология. Если у вас есть петля, это означает, что вы на этом порту получаете BPDU-шку, которая лучше, чем та, которую вы могли бы сами отправить. В терминах Rapid Spanning 3 это соответствовало бы роли Alternate Port или Backup Port.

У 802.1.2.1990 года не было ролей, и поэтому было только состояние Blocking. Вот Blocking это по факту состояние порта, при котором мы коммутацию на порту запрещаем, потому что там петля. Если бы роли были в тот момент, тогда это была бы роль либо Alternate Port, либо Backup Port. Коммутация на порту не осуществляется, если у вас состояние Blocking. То есть любые кадры, которые приходят на этом порту, вы игнорируете. Любые кадры, которые могли бы вы отправить на этом порту, вы не отправляете. У вас этот порт просто выключен из коммутации. MacLearning на этом порту тоже нет. То есть в нормальной ситуации, если у вас есть какой-то порт, вы на нем получаете какие-то кадры, и дальше фарвардите их вы дальше или не фарвардите, это уже дело 10. Но вы на нормальном порту, на котором у вас коммутация работает, выполняете MacLearning. Вы в кадрах MAC-адреса источника заносите в таблицу коммутации. На порту, в котором у вас есть блокировка, у вас могут приходить кадры, которые вы будете потом игнорировать.

И вам нет необходимости в таблицу коммутации заносить MAC-адреса из этих кадров. То есть вы в любом случае в этот порт ничего отправлять не будете. Следовательно, нет смысла во входящих кадрах на этом порту запоминать MAC-адреса. Дальше. Состояние фарвардинг. Это стабильное состояние, в котором у вас разрешена коммутация на этом порту. Это состояние соответствует ролям 802.1D 1998 года, Rapid Spanning 3, Root Port или Designated Port. То есть на этом порту у вас идет коммутация, вы нормально кадры принимаете, вы нормально кадры отправляете. У вас на этом порту работает MacLearning. Опять же, состояние фарвардинг стабильное. Оно продолжается сколь угодно долго, до тех пор, пока у вас не случится топология. Либо root не сменится, либо что-то еще не произойдет. Ну то есть что-то должно произойти, чтобы порт перешел из состояния фарвардинга в какое-то другое состояние. Замечу, что из состояния фарвардинга он может перейти либо в Disabled, если вы выключите порт,

либо в Blocking, если у вас на этом порту вдруг придет бы подушка, которая вкуснее, чем та, которую вы сами отправляете. В остальных случаях фарвардинг стабильно работает неограниченно долго. И дальше, наконец, состояние переходное. Listening и Learning. В состоянии Listening вы подозреваете, что у вас, возможно, случилась петля, и вы производите проверку на петлю. Продолжительность, в которой порт находится в состоянии Listening, это будет таймер фарвард дилей. Мы про таймеры с вами еще пока не говорили, но вот пришла как раз пора про них поговорить. Следующий слайд будет буквально про таймеры. Коммутация на Listening порту не осуществляется, MacLearning не осуществляется. То есть это фактически по смыслу, по эффективной работе. Порт как будто заблокированный. Но на самом деле он не заблокирован. Он ждет немножечко для того, чтобы разблокироваться. По эффективной работе Listening и Blocking не отличаются. То есть порты себя ведут одинаково. Но только Blocking, он не ограниченно долго работает, а Listening работает в течение forward delay timer по умолчанию 15 секунд.

В состоянии Listening вы даете время всем остальным коммутаторам в топологии при необходимости заблокировать свои порты, если вдруг вы подозреваете, что у вас есть петля. Если вдруг вы знаете, что топология сменилась, у вас, возможно, появились какие-то новые линки, в которых, возможно, организовалась петля, а вот Listening нужен для того, чтобы все свечи одновременно заблокировали коммутацию на всех своих портах. Timer forward delay, мы про него еще пока, опять же, не говорили, но проговорим. Он указывает, сколько времени BPDU будет распространяться между самыми-самыми-самыми дальними коммутаторами. То есть вот у нас есть какие-то коммутаторы, которые между собой как-то связаны. Forward delay – это время, в течение которого BPDU сначала перейдет от одного свеча ко второму, потом от второго к третьему, к третьему к четвертому. Вот больше, чем определенное время, не может занимать распространение информации от одного свеча до другого. Вот forward delay – это как раз максимальное время, которое потребуется свечу,

для того, чтобы информация от него дошла до всех остальных коммутаторов. В состоянии Listening вы даете время всем остальным коммутаторам заблокировать свои порты. В состоянии Learning – это тоже временное состояние. Вы продолжаете проверку на петлю, вы все еще блокируете коммутацию, но вы включаете MacLearning. И поэтому, собственно, состояние Learning так и называется. Зачем два разных состояния – Listening и Learning? Дело в том, что в состоянии Learning вы ждете, пока другие коммутаторы пройдут свое состояние Listening, и вы не будете отправлять своим соседям кадры, которые они заведомо сбросят. Поэтому два разных состояния – Listening и Learning – нужны для того, чтобы повысить эффективность работы. В состоянии Listening вы просто блокируете все, а в состоянии Learning – если вам кто-то чего-то пришлет, то вы хотя бы запомните, за какими портами находятся соседние узлы. Вы при этом коммутацию тоже не осуществляете, но вы запоминаете, кто за каким портом сидит. Давайте разбираться с таймерами. Самый простой таймер, который есть – это HelloTime.

Это то, как часто боподушки отправляются в каждом интерфейсе. Он 2 секунды по умолчанию, вы можете его переопределить, но на самом деле не так много значений, в которые вы можете переопределить HelloTime. Это значение целочисленное. Оно передается в BPD-ушках в виде именно целого значения. 0 писать как бы нехорошо, отрицательное число писать нельзя, поэтому единственное, что вы туда можете вписать, если вам не нравится значение 2 секунды, это 1 секунду. Ну тоже неплохо на самом деле, что у вас BPD-ушки будут отправляться в 2 раза чаще. Второй таймер – Forward Delay, про него уже говорилось. Это время, в течение которого BPD-ушка гарантированно передает всю информацию между двумя самыми-самыми-самыми дальними коммутаторами, которые друг с другом не связаны, но они связаны через цепочку соседств. И информация от одного соседа передается другому, другому – третьему, третью – четвертую – четвертую – пятую – и так далее. Вот в стандарте прописано, что значение в 15 секунд исходит из того, что у вас HelloTime будет 2 секунды, то есть на каждое соседство у вас прятится до 2 секунд,

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

Этот таймер Forward Delay применяется как минимум в состояниях Listening и Learning, и поэтому если у вас используется медленный Spanning Tree, то на каждом порту перед тем, как разблокировать коммутацию, она у вас будет заблокирована в течение двойного таймера Forward Delay. То есть по умолчанию 30 секунд. Это не единственные таймеры, которые есть в Spanning Tree. В CCNA обычно проходят эти два, но на самом деле таймеров сильно больше. Один таймер, который вы можете настроить, это будет таймер MaxH. Это время, в течение которого коммутатор помнит на каждом интерфейсе самую выгодную BPD-ушку, которую он получил. На самом деле на каждом порту хранится самая выгодная BPD-ушка, которая вообще на этом порту отправлялась или получалась. То есть кто отправляет десигнатор портом своим BPD-ушку, вот ту BPD-ушку порты хранит. Если у вас у самих роль на этом порту десигнатор, то вы на своем порту помните свою собственную BPD-ушку. В состоянии десигнатор... В смысле, не в состоянии, в роли десигнатор особого смысла в этом нету,

потому что вы всегда знаете, какую BPD-ушку вы отправляете. До тех пор, пока у вас все в порядке, вы свою BPD-ушку будете все снова и снова и снова запоминать. Поэтому здесь мы не говорим про то, что мы помним свои отправляемые BPD-ушки. Для нас будет интересна таймер MaxH ситуация, когда мы принимаем BPD-ушки на порту. А это возможно, если у вас роль alternate или backup. Для нас будет интересна ситуация, когда вы принимаете BPD-ушки, а это возможно в случае, когда вы не десигнатор свитч, когда вы на этом порту, соответственно, либо будете root-порт, либо alternate, либо backup. То есть вы принимаете чужие BPD-ушки. Свою не отправляете, потому что нет смысла. Кто-то один вам отправляет вкусную BPD-ушку, а вы ее на порту помните. Так вот, этот таймер MaxH как раз будет нужен для того, чтобы вы в течение некоторого времени BPD-ушку запоминали. Это время не должно быть слишком большим. Дело в том, что если кто-то на порту присылал вам BPD-ушки, это значит, что он находится ближе к root-у, чем вы.

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

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

ну никак не меньше шести секунд. На самом деле больше. Почему больше? На самом деле потому, что в BPD-ушках есть еще секретное поле, которое мы с вами не проходили, но оно там где-то в разделе с таймерами будет храниться. Это поле называется MessageAge. И в этом поле указывается, сколько сегментов от ROOTA информация от этого самого ROOTA уже прошла. То есть когда ROOT отправляет BPD-ушку, он говорит, я ROOT, я прям сразу вот свеженькую, горяченькую BPD-ушку отправляю от самого себя. Это информация из первых рук. Когда второй свитч получает такую BPD-ушку и отправляет к третьему, он указывает в разделе MessageAge, что эта BPD-ушка прошла один прыжок между свитчами. То есть примерно как в RIP, например, указывается стоимость маршрута. Сколько прыжков между роутерами маршрут прошел. Здесь тоже самое. BPD-ушка будет имитировать апдейт RIP и указывать, сколько хопов между свитчами,

в скольких хопах находится ROOTA. Так вот, если вы получаете BPD-ушку, и она находится, например, в пяти прыжках от ROOTA, вы получили BPD-ушку, в которой MessageAge прописано 5 секунд. Вы, соответственно, говорите, что тогда мы будем до вот этого значения MaxAge, по умолчанию, который 20 секунд, считать не с нуля и не с единицы, а со значением MessageAge. То есть если мы получили BPD-ушку, мы говорим, BPD-ушка имеет MessageAge 5 секунд. Вот мы говорим тогда 5 секунд, 6 секунд, 7 секунд, 8 секунд, и мы считаем до 20, до таймера MaxAge. По факту получается, что вы не 20 секунд ждете, а только там 15. Поэтому если вы находитесь в не более чем 7 прыжках между свечами, а 7 прыжков между свечами, это вот как раз наш диаметр поля коммутации, на каждой из них вы будете увеличивать значение MessageAge на единичку,

и дальше у вас получается значение MessageAge, которое приходит на самый-самый-самый дальний коммутатор, оно будет 7 секунд. И вы будете до MaxAge считать, начиная с 7 секунд. Поэтому по факту получается, что когда вы будете на самом-самом-самом дальнем свече от рута, который может быть вплоть до 7 прыжков от рута находиться, будете считать до MaxAge, вы будете до 20 считать не с нуля, не с единицы, а с 7. Поэтому по факту у вас BPD-ушка, которая будет получаться, она протухнет существенно быстрее. Не через 20 секунд, а через примерно 12. Так, это что касается таймера MaxAge. Значение это 20, оно рассчитано, опять же, исходя из определенной логики, исходя из того, что у вас есть поле коммутации диаметра 7 коммутаторов. Задержка при передаче BPD-ушки внутренне будет 1 секунда. Максимум BPD-U Transmission Delay. Это время, которое проходит между тем, как вы сформировали BPD-ушку на интерфейсе,

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

и от HelloTime, а также от свойств вашего оборудования. Исходя из каких-то усредненных значений, стандарт предлагает значения для этих параметров 2 секунды HelloTime, 15 секунд ForwardDelay, 20 секунд MaxAge. Так, что касается состояний Listening и Learning. Вот эти вот состояния, они будут как раз пользоваться таймером ForwardDelay, который по умолчанию 15 секунд. И работать эти состояния будут следующим образом. В состоянии Listening у вас порт будет блокировать любую коммутацию, потому что, возможно, петля. То есть вы подозреваете, что у вас случилась петля, вы со своей стороны порт блокируете, возможно, кто-то еще со своей стороны тоже порты будет блокировать, но это как бы может произойти только через некоторое время, не обязательно сразу. У вас есть время, в течение которого все коммутаторы обязаны отреагировать на то, что вы там что-то им пошлете. Вот у вас есть ForwardDelayTimer, через ForwardDelayTimer все будут знать о том, что у вас что-то произошло, если у вас что-то произошло.

Но если у вас ничего не произошло, то, соответственно, никто не должен будет реагировать. Все зависит от вас. Отправили ли вы сообщение TopologyChange или нет? Если вы не отправили сообщение TopologyChange, то тогда все просто. Это у вас просто какой-то порт, допустим, только что поднялся. Он был в состоянии, допустим, disabled или forwarding. И вы подумали, ну, может, там вдруг случилась петля, надо бы проверить на всякий случай. Вы порт переводите в listening, блокируете любую коммутацию на порту, кадры входящие пристреливаете, исходящие кадры не коммутируете, никакие вообще, за исключением разве только кадров, которые в принципе не коммутируются. То есть если у вас коммутатор в принципе не коммутирует определенный протокол, например, это если там говорить про ЦИСК, CDP или VTP, или там, допустим, стандартный протокол LLDP, эти кадры не коммутируются. То есть их матрица коммутации в принципе никогда не пропускает через себя. Она их всегда терминирует на себе. Так вот, в такой ситуации у вас, что будет делать коммутатор?

Он будет ждать. И ждет он forward delay. Если вы со своей стороны предположили, что у вас может быть петля, то, возможно, вы отправили сообщение topology change, и вы ждете в течение forward delay таймера, что все остальные узнают, что у вас случилась смена topology. До тех пор любые кадры, которые есть на порту, они пристреливаются. Возможно, все остальные свечи еще не поняли, что у вас случилась смена topology. И, возможно, они устроили петлю. Поэтому кадры, которые приходят на интерфейсе, у которых у вас в состоянии listening, они недоверенные. Вы не можете быть уверены на порту, что если у вас в состоянии listening, что кадры точно приходят от правильного интерфейса. Что действительно за этим интерфейсом, за которым вы получили какой-то кадр, находится отправитель его. Возможно, возможно, это случилось, потому что на интерфейсе образовалась петля, и кадры какие-то там, браткастовые туда ушли, а потом к вам пришли из этой петли. То есть там отправителя на самом деле нет. В состоянии listening вы просто ждете, чтобы у вас завершился пересчет топологии. В состоянии learning

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

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

то есть спустя 30 секунд по умолчанию вы на этом порту расслабляете все ограничения и запускаете коммутацию. То есть с настройками по умолчанию после пересчета по логии на порту Spanning 3 будет блокировать коммутацию на этом порту на срок до 30 секунд. Если у вас несколько портов в это состояние lo, значит, на всех портах вы будете блокировать коммутацию на срок до 30 секунд. Собственно, за это Spanning 3 не очень любят. То есть, когда у вас 30 секунд коммутация на свече не осуществляется после, допустим, перезагрузки или после того, как он там на каком-то порту BPD-ушку неправильно получил или правильно не получил. Ну, он, соответственно, все вам здорово заблокирует. А если администратор не умеет работать со Spanning 3, то тогда он будет испытывать проблемы с тем, что у него периодически коммутация на порту, на всех портах на свече, на срок 30 секунд выключается. Ничего хорошего в этом нет. Дальше. Два других состояния, forwarding и blocking, они уже стабильные, то есть у них время, в течение которого порт находится в этих состояниях,

оно будет недетерминированное. В случае с forwarding вы на порту осуществляете коммутацию нормальную, то есть это обычная нормальная работа порта. Кадры уходят с порта, кадры приходят на порт и дальше куда-то направляется в матрицу коммутация. Идет MacLearning, нормальное пополнение таблицы MAC-адресов. Вы отправляете или принимаете BPD-ушки на таком порту. То есть если у вас это root-порт, вы принимаете BPD-ушку, если это у вас десигнает, это порт, вы отправляете BPD-ушки. И равным образом обрабатываются кадры служебных протоколов. Если у вас порт в блоке, то есть вы решили, что на этом порту есть петля, это возможно в состоянии alternate-порт или backup-порт. Коммутация на таком порту не производится. Вы сбрасываете любые кадры, которые приходят к вам, за исключением служебных протоколов. LLDP, VTP, CDP и прочие некоммутируемые протоколы, которые обрабатываются самим свечом и не коммутируются дальше. Они нормально отправляются, принимаются, здесь проблем нет. Речь про блокирование коммутации идет только лишь про тот трафик, который коммутируемый. То есть это не то, что вообще весь трафик на порту блокируется.

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

что есть у классического Spamning 3. На самом деле RAPID Spamning 3 использует почти тот же самый алгоритм. То есть, что там говорить, тот же самый алгоритм Spamning 3 или основного дерева, что и классический Spamning 3. Точно так же выбираются root, точно так же выбираются forwarding-порты, точно так же отправляются, принимаются BPDU-шки. Разница в RAPID Spamning 3 и обычного Spamning 3 заключается в таймерах. То есть, если у нас обычный Spamning 3 работает по таймерам, у него есть HelloTime, и он согласно этому HelloTime отправляет BPDU-шки, то в RAPID Spamning 3 возникают события. У нас пришло событие на одном порту, мы немедленно отреагировали, запустили, допустим, BPDU-шку на другом порту. Это позволяет вам значительно сократить время пересчета топологии. То есть, если у вас произошло событие вида, допустим, один порт получил впустную BPDU-шку, вот мы немедленно можем на других портах отправить другие BPDU-шки. Или, допустим, мы получили BPDU-шку на порту к нам приходящую, вот мы можем там что-то сделать с этим портом немедленно для того, чтобы ускорить работу.

Немедленно ускорить работу, например, можно, отправив встречное сообщение. Классический Spamning 3 ничего встречного не отправляет. То есть, у вас есть самый крутой свитч в сегменте, вот он отправляет BPDU-шки, а все остальные сидят, молчат в тряпочку. В RAPID Spamning 3 за счет того, что в 98-м году уже было понятно, что топологии с общей шиной не осталось, и сегментов, в которых больше двух свитчей уже быть не может, появились сообщения типа запрос-ответ. У вас есть свитч, который думает, что он диссигнейт, он отправляет так называемый proposal, предложение, и свитч, который согласен с тем, что он не будет диссигнейтовать свитчом, отвечает, да, я согласен с тем, что ты диссигнейтед свитч. Он отправляет такое сообщение сразу по факту возникновения события. Классический Spamning 3 ничего не знает про события. У него есть просто BPDU-шки, в котором стреляют раз в две секунды. С одной стороны пришла BPDU-шка две секунды, подождали, отправили. Дальше. Быстрый Spamning 3 получил BPDU-шку, немедленно ответил.

Почему в RAPID Spamning 3 стало это возможно? Ну, именно потому, что произошел отказ от топологии с общей шиной. Если у вас в сегменте там 3, 4, 5 свитчей, они соединены одним большим проводом к аксиальным, вы не можете отправить предложение вида «давай я буду диссигнейтенствовать свитчом». Потому что непонятно, кто вам отвечать должен, когда и что будет, если вы отправите предложение «давайте я буду диссигнейтедствовать свитчом», все остальные одновременно должны будут вам ответить. Вот вы отправили одно сообщение «я буду диссигнейтедом», и получается к вам пришло там 4 сообщения «ок, я не против». А где гарантии, что пятой не должно быть сообщения, которое вы просто не дождались? Если вы используете только point-to-point каналы, что характерно для современных свечей, то в Rapid Sparning 3 вы можете отправить сообщение «Я буду designated», второй свеч ответит вам, и больше никого кроме него нет. Поэтому если вы отправили сообщение в point-to-point канал, и вам кто-то ответил «Окей, я не против», значит вы можете без особых проблем стать designated свечом за этот сегмент.

Никто больше в этом сегменте designated свечом не будет. Как вы помните из одного из предыдущих видео, самое главное — это кто станет designated свечом за сегмент. Если вы решили, кто станет designated свечом за сегмент, вы решили все проблемы в Sparning 3. Быстрый Sparning 3 решает это путем сообщения вопрос-ответ. Медленный Sparning 3 решает это путем «А давайте в течение форвард-делай таймера фигачить раз в две секунды сообщения в канал, и кто-нибудь хотя бы одно сообщение увидит». Ну вот, собственно, как-то так. Так, дальше. Если говорить про Rapid Sparning 3, с настройками по умолчанию, он ведет себя как обычный медленный Sparning 3. То есть если вы указываете, что у вас есть везде Sparning 3, там, где каналы у вас будут point-to-point, то есть по ним четко видно, что это, например, фулл-дуплексный интерфейс, который смотрит на соседний свеч, вы отправили туда запрос, получили ответ, ну да, там с этим интерфейсом все понятно. Это между свечовый линк, и с ним действительно там десигмент этот порт будет выбран довольно быстро.

Но есть порты, которые у вас смотрят на обычных пользователей. И эти порты, они не принимают BPD-ушки. Они отправляют BPD-ушки в сторону пользователей, но нормальные пользователи BPD-ушки Sparning 3 игнорируют. Они вам в ответ ничего не посылают. И на таких портах Sparning 3 будет вести себя в режиме совместимости с классическим медленным Sparning 3. То есть он будет в течение таймера, forward delay, переводить порт, ну, фактически в состоянии listening, потом фактически в состоянии learning. Вот если он за дважды forward delay таймер ничего не обнаружил, никакой BPD-ушки, которая к нему встречная бы пришла, он понимает, окей, я могу быть десигментед портом. И он на таком порту включает forwarding. Это вызывает лютый ботферд со стороны начинающих администраторов, которые видят в Sparning 3 слово rapid и говорят, а чем же он тогда rapid, если он все равно на каждом порту, который смотрит на пользователей, 30 секунд нам блокирует коммутацию. То есть что медленный Sparning 3 30 секунд блокирует коммутацию, что быстрый Sparning 3 30 секунд блокирует коммутацию. В чем быстрота-то? А быстрота заключается в том, что у Rapid Sparning 3 есть edge-порты,

на которых коммутация разрешается сразу после включения такого порта. То есть если вы помечаете порт как edge-овый, вы на этом порту говорите свечу, сразу включая коммутацию, сразу переводите этот порт в состояние нормального фарвардинга. Если вдруг на этом порту будет отправлена BPD-ушка, а потом получена BPD-ушка, то есть мы отправим в этот порт BPD-ушку сразу, мы их всегда отправляем, а вот потом на этом порту будет получена какая-то BPD-ушка, это значит, что с той стороны не согласны с тем, что мы будем десигнать свечу. Более того, с той стороны кто-то, кто отправляет нам BPD-ушки, возможно другой свитч или даже хаб, который закольцован, что-то с ним как-то нехорошо, с этим портом. Короче говоря, на этом порту не конечный юзер, на этом порту другой свитч. Может быть мы сами как свитч из-за того, что это петля, может быть там что-то еще, может просто другой свитч, который бы подушки отправляет, может петля случилась, может петля не случилась. Короче говоря, будем разбираться. Блокируем коммутацию на этом порту, переводим порт в listening-learning состояние. Два вот этих механизма, которые в Rapid Spanning 3 получились,

это сообщение запрос-ответ и появление edge-портов. Они позволяют сократить работу по пересчету топологии в Rapid Spanning 3 до значительно меньших величин по сравнению с классическим Spanning 3. Классический Spanning 3 как минимум на 30 секунд блокирует вам коммутацию с настройками по умолчанию. Rapid Spanning 3, если вы правильно разметили порты, если у вас везде нормальные интерфейсы point-to-point, и Spanning 3 про это знает, он на пересчет топологии будет тратить буквально сотни миллисекунд максимум. В этом заключается как раз его быстрота, что действительно с настройками правильными Rapid Spanning 3 будет работать ощутимо быстрее. У Rapid Spanning 3 или 800.2.1.w есть состояние, и эти состояния немножечко другие по сравнению с 802.1.d 90-го года. Классический Spanning 3 предусматривал 5 состояний. Как вы помните, это были Disabled, Blocking, Listening, Learning, Forwarding. То есть состояние Disabled – это стабильное состояние, при котором у вас коммутация не осуществляется,

порт фактически выключен. Дальше состояние Blocking означает, что вы на порту решили заблокировать коммутацию, потому что там есть петля. То есть это либо типа то, что мы говорили, Alternate Port, либо Backup Port. В состоянии Listening и Learning вы проводили некоторое время, и дальше на порту разрешали коммутацию, соответственно, переводили порт в состояние Forwarding. В Rapid Spanning 3 вот эти вот состояния немножечко подрихтовали. Сказали, на самом деле состояние у Rapid Spanning 3 – это либо коммутировать трафик, либо не коммутировать трафик. Еще промежуточные коммутируем, но не совсем. То есть не коммутируем, но хотя бы маклеринг ведем. Поэтому в Rapid Spanning 3 из пяти состояний сделали три. Сказали, если на порту по факту боевые кадры не ходят, то это состояние Disabled. Если на порту боевые кадры ходят, это Forwarding. А вот если они не ходят, но маклеринг осуществляется, то это состояние Learning. Поэтому состояние 802.1D соответствует состояниям Rapid Spanning 3,

как показано в этой табличке. Disabled – боевой трафик не ходит. Blocking – боевой трафик не ходит. Listening – боевой трафик не ходит. Forwarding – боевой трафик ходит. Learning – боевой трафик не ходит, но маклеринг происходит. Эти состояния друг другу так или иначе соответствуют. Что касается ролей. Роли, как вы помните, мы в предыдущем видео изучали, соответствуют тому, почему порт находится в том или ином состоянии. Роль не отвечает на вопрос, что происходит с портом. Роль отвечает на вопрос, почему так или иначе что-то происходит с портом. Вот роль RSTP Disabled означает точно то же самое, что означало состояние Disabled на медленном Spanning 3. Это значит, что администратор просто выключил порт. Spanning 3 на этом порту не работает, коммутации на этом порту не работает, маклеринга на этом порту нет, БПДушки не отправляются, не принимаются, служебные кадры не отправляются, не принимаются. То есть все очень просто. Порт тупо не работает.

Состояние блокинг медленного Spanning 3 соответствует на самом деле состоянию и растипичному дискардинг, потому что боевой трафик не ходит. Но роли, в которых может быть такое поведение, будет две – Alternate или Backup. Когда мы хотим описать, что у нас какой-то порт находится в состоянии Alternate, мы говорим, вот у нас есть роль Alternate, в которой соответственно соответствует состоянию дискардинга. То есть более правильно сказать, что это у нас Alternate дискардинга. Равным образом Backup. Он тоже всегда будет в состоянии дискардинга. Вы не можете быть в состоянии, не знаю, Learning, и роль у вас будет Backup. Потому что Learning означает, что вы потенциально готовы перевести этот порт в Forwarding. Вы ждете только этого. Если у вас точно уже известно, что BPDU пришла со стороны другого свеча более вкусная, это никак Learning на порту быть не может. И последнее, что у нас есть, это вот про Root и Designated порты. Root Port будет означать, что вы BPDU принимаете на порту,

чьи-то вкусные. Designated Port означает, что вы сами BPDU отправляете вкусные на этом порту. Вы можете это делать, потому что вы нормально, стабильно работаете. Тогда у вас будет роль Root и состояние Forwarding. Или вы, может быть, там, Designated Forwarding. Но если вы находитесь в режиме совместимости с классическим Spanning Tree, у вас роль на порту выбирается по факту того, получаете ли вы или не получаете вкусные BPDU на этом порту. То есть вы можете быть в режиме совместимости с классическим Spanning Tree, вы можете только-только перевести порт в Listening, ну, то, что называлось Listening, на самом деле это Discarding. Но вы на этом порту не получаете никаких вкусных BPDU. Любой свитч начинает с того, что мнит себя Root, и, соответственно, у него все порты будут Designated. Но если на портах не было получено подтверждение, что давай ты будешь Designated портом, то тогда на всех портах у вас работает режим совместимости с классическим Spanning Tree, и начинается все с того, что у вас порт находится в роли Designated,

состояние Discarding 15 секунд. Это эквивалент старому состоянию Listening. Через 15 секунд после того, как свитч не получил никаких BPDU от соседей, он говорит, окей, мы 15 секунд подождали в состоянии эквивалентному Listening, Designated Discarding, теперь мы переходим в состояние Learning. У вас Designated Learning 15 секунд. И спустя еще 15 секунд, соответственно, у вас будет Designated Forwarding. Та же самая история с Root. То есть если вы получаете BPDU от соседа, этот сосед не поддерживает Spanning 3, но он присылает вам вкусную-вкусную BPDU, медленного Spanning 3, а вы быстрый. Вы тогда говорите, окей, мы будем работать в режиме совместимости, я уже сразу могу сказать, что BPDU на этом порту вкусная приходит, этот порт точно будет рутовым, но поскольку сосед медленный, пропозал там, агримент мы ему отправлять не будем, мы будем переходить постепенно через три состояния. Discarding, Learning и Forwarding. То есть начинаем мы с того, что работаем в Root Discarding, потом Root Learning, потом Root Forwarding.

Если у вас есть быстрый Spanning 3 и настроены Point-to-Point связи, то вот это вот Root Discarding, Root Learning, Root Forwarding не нужно. То есть если вам сосед прислал бы BPDU, самую-самую первую, и в которой он говорит, я быстрый Spanning 3, давай я буду Designated, я самый крутой здесь, а вы говорите, да, он действительно крутой, он настолько крутой, что это будет наш RootPort, вы ему сразу отправляете сообщение, я согласен с твоим предложением, вот Agreement, и оба свитча немедленно разблокируют коммутацию. Из Root Discarding они переходят в Root Forwarding. Я надеюсь, что вы разобрались с тем, какие состояния есть в Spanning 3, как в медленном Spanning 3, старом 5 состоянии, так и в новом быстром Spanning 3, Rapid Spanning 3. Их осталось всего три штуки. И спасибо за внимание. Спасибо за внимание.