STP в Cisco IOS

Что касается Cisco, в Cisco Spanning Tree есть. Он поддерживается как в виде фирменного Cisco PVST, PVST+, скорее даже, так и в виде ускоренного RPVST, так и в виде MST. Причём, если вы запускаете любой из этих видов, то на самом деле все эти протоколы в той или иной степени будут обратно совместимы и с классическим Spanning Tree. Давайте разбираться. Во-первых, PVST, PVST+ и RPVST. Мы уже смотрели на то, что эти аббревиатуры обозначают, но PVST — это фирменный Cisco протокол на основе медленного Spanning Tree, у которого BPDU, которые будут отправляться, будут отправляться не за всю физическую топологию, а только за часть этой самой топологии, соответствующую определённому VLAN. Соответственно, каждая BPDU будет промаркирована, в каком VLAN она отправляется. PVST просто поддерживал только ISL VLAN,

PVST+ поддерживает и 802.1Q VLAN. Быстрый PVST, или RPVST, или Rapid PVST+ — это фирменный протокол, который поддерживает те же самые ускорения, которые появились в быстром Spanning Tree, там механизмы proposal-agreement, там edge-порты, и это всё, чем отличается медленный Spanning Tree от быстрого. В любом случае, что PVST+, что RPVST будет строить не одно большое дерево за всю физическую топологию и в линках выключать те порты, которые не содержатся в кратчайшем дереве до рута. У нас будут строиться по отдельному дереву за каждый отдельный VLAN, если мы используем эти фирменные протоколы. Если, например, мы хотим, чтобы у нас работало два VLAN, то нам нужно будет строить два дерева. Если у нас будет три VLAN, будут строиться три дерева. И в каждом дереве мы будем отправлять свои BPDU.

Если у нас в каком-то порту трафик определённого VLAN передаётся, то там будут бегать BPDU каждого отдельного дерева. Для того чтобы всё это работало, нам потребуется новое указание, в каком VLAN мы отправляем BPDU. И более того, нам мало будет указывать, что BPDU, которая отправляется нашим свичом, отправляется в каком-то одном VLAN. Нам придётся для каждого виртуального коммутатора, который у нас есть на железном свиче, иметь отдельный Bridge ID. Смотрите, в чём проблема. Если у нас есть наш коммутатор, и у нас есть в нём 10-й VLAN и 20-й VLAN, который мы сделали, у нас есть два access-порта. Один access-порт и другой access-порт. Соответственно, один связан с 10-м VLAN, другой с 20-м. Если мы возьмём и замкнём два этих порта просто прямым проводом, мы не должны получить один порт designated, другой порт backup. Мы должны получить именно два порта,

которые будут просто forwarding traffic. Нам нужно будет различать эту и эту сущность, у них должны быть разные Bridge ID. В этом случае получится, что у нас BPDU, которая отправляется одним портом и другим портом, они будут иметь разные sender Bridge ID. Для того чтобы это всё происходило, нам нужно будет каким-то образом сделать так, чтобы вместо одного Bridge ID, который у нас был в классическом Spanning Tree, на устройстве появилось много разных Bridge ID, по одному на каждый виртуальный коммутатор. Если у вас на железке есть один MAC-адрес, то нам будет сложно это сделать. Если у вас гипотетически было бы много MAC-адресов на устройстве, например, 10, или 20, или 50, и вам требовалось бы не больше 10, или 20, или 50 этих самых VLAN создавать, вы могли бы на каждый отдельный виртуальный коммутатор назначить отдельный MAC-адрес. Когда-то давным-давно так и можно было сделать.

У вас на устройстве было, например, 64 MAC-адреса, и вы могли взять эти 64 MAC-адреса раздать на виртуальные коммутаторы. Один MAC-адрес на один виртуальный коммутатор, на один VLAN, другой MAC-адрес на другой VLAN. И первые свичи именно так и делали. Но современные свичи, как правило, имеют только один MAC-адрес, и поэтому нам нужно как-то из одного MAC получить целую пачку Bridge ID и назначить по отдельному Bridge ID на каждый отдельный виртуальный коммутатор. Поэтому играть нам придётся старшими 16 битами. В нормальном Spanning Tree туда вписывается Bridge Priority. Мы можем сделать так, чтобы у нас получились 16 разных, допустим, не 16, а 2, 3, 4, 10 разных Bridge ID, просто указав, что в один мы будем вписывать, допустим, 8.0.0.1, в другой 8.0.0.2, в третий 8.0.0.3 приоритеты. Если мы хотим сделать так, чтобы у нас получились разные Bridge ID,

у них у всех будет одинаковый MAC, но у них будут разные битики Bridge Priority, тем самым мы сможем сделать отдельный Bridge ID для каждого виртуального коммутатора. Мы можем рассматривать эту левую 16-битную часть как единый монолитный кусочек, просто мы должны будем убедиться, что каждому отдельному виртуальному коммутатору Bridge ID мы назначаем такой, который не повторяется с другими коммутаторами. Мы можем это сделать вручную, но это будет очень неудобно, и главное, что это будет порождать ошибки. В какой-то момент времени мы не уследим и назначим двум разным виртуальным коммутаторам один и тот же Bridge ID, и всю эту идею Spanning Tree может гипотетически нам поломать. Для того чтобы ничего не поломать, Cisco автоматизирует этот процесс за нас. Она говорит: из 16 бит, которые у нас отводятся на Bridge Priority, по факту мы можем гипотетически сотворить от нуля до 65 535 разных приоритетов.

Приоритет в Spanning Tree означает, что коммутатор с большей или меньшей вероятностью станет рутом. Тот коммутатор, у которого самый маленький приоритет, станет рутом. Тот коммутатор, у которого приоритет самый большой, с меньшей вероятностью станет рутом. Но 65 536 разных приоритетов — это ультра дофига. Это означает, что у вас коммутаторов должно быть как минимум 65 535 в одной сети, чтобы каждому отдельному коммутатору можно было назначить отдельный приоритет. Но представьте себе, что это означало бы в реальности. Мало того, что это адский объём работы, это само собой разумеется, это означало бы, что вы хотите раздать приоритеты в явном виде. Сказать: сначала один коммутатор должен быть рутом, потом, если он отказывает, второй коммутатор должен стать рутом. Именно конкретный этот второй. Никакой другой из 65 тысяч коммутаторов. Потом, если он откажет, третий. Потом, если откажет, четвёртый. И вы в явном виде указываете очерёдность наследования рутов. В случае если первые 10 тысяч коммутаторов сдохнут,

тогда рутом должен стать не какой-нибудь совершенно произвольный коммутатор, а конкретный 10 001-й. В реальности этого не нужно. В реальности, если вы строите сеть по топологии Cisco Enterprise Architecture, где у нас есть, допустим, два core-свича, к ним подключаются пары distribution-свичей в distribution-блоках, и в каждом distribution-блоке у нас есть пачка access-свичей, и они там как-то между собой строят эти самые треугольники. И у нас, соответственно, здесь тоже так всё выглядит. Здесь тоже пачка access-свичей. В таком раскладе мы хотим, чтобы у нас корневыми свичами были два этих самых core-свича, чтобы они находились в самом центре сети. Если один отвалится, то чтобы второй стал рутом, но не должен в нормальной ситуации рутом становиться какой-то свич, который находится где-то очень далеко. Это не нужно просто по

соображениям логики: если мы хотим, чтобы у нас сеть работала корректно, то рутом должен становиться кто-то в центре. Если у вас рутом будет становиться кто-то на границе сети, то все коммутаторы будут пытаться кратчайшие маршруты построить до этого самого свича, и они будут разблокировать порты, которые на него смотрят наилучшим образом. Но представьте себе, что у нас будет, если, например, есть два distribution-свича, и у нас есть там какой-то access-свич. Эти линки, скорее всего, допустим, гигабитные. Гигабит здесь и гигабит здесь. Между двумя distribution-свичами у нас, скорее всего, два линка по 10 гигабит, то есть в итоге 20 гигабит между двумя коммутаторами distribution получается. Distribution, distribution, access. Если access-свич у нас будет объявлен рутом, соответственно, у него будут порты designated, designated. У левого distribution-свича это будет root-порт. У правого distribution-свича это тоже будет root-порт. Эти порты

останутся разблокированы. Оба порта по гигабиту. А этот 20-гигабитный линк кто-то из distribution-свичей должен будет заблокировать, если у вас рутом будет выбран access-свич. Естественно, что это неправильно. Естественно, что чем ближе к центру сети, тем более скоростные у вас линки будут, и тем более скоростные линки останутся разблокированными, а медленные линки будут блокироваться. В такой ситуации, если у нас вот это будет, например, рутом, то заблокирован будет этот порт, скорее всего. И получается, что у нас 20-гигабитный линк остался разблокирован, он работает, а гигабитный линк один работает, один заблокирован. То, что Spanning Tree и должен сделать. Если вы хотите, чтобы у вас реальная сеть работала, то вы хотите, чтобы рутами выбирались какие-то свичи, которые находятся ближе к центру сети. Это core-свичи, как правило, если они у вас есть. Если нет, distribution-свичи. Если у вас core-свичей 2, вы скажете: один должен быть рутом с большей вероятностью,

другой с меньшей вероятностью, но всё равно запасной рут, называемый standby. А все остальные — это если и рут сдох, и standby сдох, у нас сеть в любом случае разделилась на отдельные части, и отдельно приоритеты внутри каждого отдельного distribution-блока раздавать уже смысла особого нет. Но если вдруг у вас, допустим, есть ещё какие-то связи между distribution-свичами, у вас там кольцо из distribution-свичей параллельно есть, вы решили заложиться под то, что core-свичи могут сдохнуть. В этом случае вы можете сказать: окей, давайте назначим, допустим, какой-нибудь из core-свичей. На core-свичи мы говорим: у нас есть один приоритет, на запасной core говорим другой приоритет, а на всех distribution-свичах мы говорим третий приоритет, неважно, кто из них уже будет выбран рутом. Если у нас ядро сети развалилось, мы находимся в таком деградированном состоянии, что там уже неважно, какие линки заблокировать, по большому счёту. Пусть хоть что-то будет работать. Но больше чем три приоритета по факту

в боевой сети не нужно. Ладно, ещё четвёртый приоритет, приоритет по умолчанию для всех остальных. 65 535 разных приоритетов дают нам возможность в предположении, что мы по одному приоритету на каждый свич назначаем отдельно, сделать сеть из 65 тысяч свичей, каждый свич получит отдельный уникальный приоритет. При этом в реальности отдельный уникальный приоритет назначать смысла нет. Есть смысл назначать приоритет на пачке свичей, которые будут более-менее однородные. Ладно, рут свитч. Самый маленький приоритет — запасной рут свитч. Почти самый маленький приоритет — запасной рут. Это два основных приоритета, с которыми мы работаем. На все остальные свитчи мы, как правило, не назначаем какие-то специальные приоритеты. Если с дохлой ядрой сети сеть разваливается на отдельные компоненты, там уже не до жира. Поэтому, по факту, нам для выставления приоритета вполне достаточно 4 бит. И они могут быть самые старшие биты.

И мы туда вкладываем число от 0 до 15. Это даёт нам 16 разных приоритетов. И в принципе для подавляющего большинства сетей этого более чем достаточно. А оставшиеся 12 бит мы можем специально использовать для того, чтобы вписывать туда какое-то уникальное значение, характерное для конкретного виртуального коммутатора. Если нам нужно сделать несколько bridge ID для нескольких виртуальных коммутаторов, для нескольких VLAN, очень удобно будет как раз сюда, в эти самые 12 оставшихся бит, вписывать номер VLAN. Они по размеру как раз совпадают. Важное замечание. Вы не обязаны туда вписывать номер VLAN. Вы должны будете туда вписать что-то уникальное для каждого VLAN. Чтобы у нас не получилось так, что два разных виртуальных коммутатора, соответствующих разным VLAN, получили одинаковый bridge ID. Но при этом удобно вписывать туда номер VLAN. Дальше. Если у нас есть вот такая сеть, два коммутатора,

они связаны между собой одним проводом, но этот провод транковый. И у нас есть два VLAN, 10-й и 20-й. Здесь 10-й и 20-й. И здесь тоже 10-й и 20-й. И мы хотим сказать, что у нас в этом проводе, в транковом, бегают кадры и одного, и другого VLAN. На самом деле нужно построить два дерева в этом транке. Провод один, а BPDU-шек в нём будет передаваться две. По одной за каждое дерево. И в этом случае мы говорим: в 10-м VLAN мы хотим назначить рутом левый коммутатор, и мы ему назначаем приоритет меньше, чем дефолтный. И приоритет у него может быть, например, 6.0.0. Откуда взялась шестёрка? Это как раз значение поменьше, чем у дефолтного приоритета. Дефолтный приоритет состоит из единицы, 0, 0, 0. И дальше 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0. Это дефолтный приоритет,

который 32 768. И соответственно, мы говорим, это шестнадцатеричное число 8, 0, 0, 0. Если мы хотим сделать приоритет поменьше, то мы говорим: давайте вот сюда, в эти 4 битика, пишем какое-то число, чтобы итоговый результат получился меньше, чем 8, 0, 0, 0. Например, шестёрку. То есть 0, 1, 1, 0. Четыре таких битика. А дальше вот сюда мы впишем номер VLAN. Если у нас 10-й VLAN, значит 0, 0, 0, 0, 0, 0, 0. Так, маловато, да? 1, да, маловато. 1, 0, 1, 0. Вот так. И у нас получается... Здесь будет число 10. Вот тут VLAN 10. И у нас получается такое 6, 0, 0, 0 шестнадцатеричное. И дальше плюс MAC-адрес. В другом VLAN другой виртуальный коммутатор за 20-й VLAN у нас получает, например, дефолтный стартовый приоритет,

стартовые биты 1, 0, 0, 0 в первых четырёх битах. И дальше номер VLAN 0, 1, 4. 0, 1, 4 шестнадцатеричное — это 20 десятичное. То есть это как раз номер VLAN вписывается и сюда, и вот сюда. И у нас получается один и тот же коммутатор представляет собой два разных виртуальных коммутатора, у каждого из которых отдельный свой уникальный Bridge ID. Внутрь Bridge ID вписывается номер VLAN, но мы ориентируемся не на это. Мы ориентируемся на то, что виртуальный коммутатор — это просто какая-то сущность, у которой должен быть уникальный Bridge ID. И мы получили как раз его уникальным. На другом свитче, вот на этом, у нас тоже есть 10-й виртуальный коммутатор и 20-й. И то же самое. На 10-й виртуальный коммутатор мы назначаем дефолтный приоритет, 8, дальше 00A — это число 10, и MAC-адрес, единственный уникальный MAC-адрес, который у нас есть на свитче. На 20-м VLAN мы назначаем приоритет поменьше, 6, и дальше номер VLAN 20-й, то есть 14 шестнадцатеричное —

это 20 десятичное. И опять же, наш уникальный MAC-адрес. К чему это приводит? К тому, что в 10-м VLAN у нас root здесь, а в 20-м VLAN у нас root вот здесь. И получается, что в 10-м VLAN вот этот порт у нас будет designated, а этот порт у нас будет root port. В 20-м VLAN вот этот порт будет designated, а вот этот порт будет root port. То есть в каждом дереве мы отдельно для одного и того же порта, например, GigabitEthernet 0/0, вычислили отдельно его роль и состояние в каждом дереве, в каждом VLAN. Так, настройки по умолчанию на Cisco следующие. Во-первых, Spanning Tree на любом коммутаторе Cisco работает по умолчанию. Вы взяли новые свитчи из коробки, принесли, достали, смонтировали в стойку, включили — Spanning Tree там уже работает. Он работает в режиме PVST+ или Rapid PVST.

До IOS 15.2.4, если вдруг вам очень сильно интересно, по умолчанию использовался PVST+, то есть медленный Spanning Tree. Вы доставали Cisco, например, 3560, 3750, и у вас там на старом IOS действительно работал PVST, медленный Spanning Tree. Вы его могли переключить в быстрый, но по умолчанию работал медленный. Начиная с IOS 15.2 по умолчанию работает быстрый Spanning Tree, то есть переключать его специально в быстрый режим не нужно. Плюс к тому таймеры используются стандартные. 2 секунды Hello Time, 15 секунд Forward Delay, 20 секунд Max Age. Плюс к тому используется схема с Extended System ID. Это как раз то самое: мы берём, откусываем 12 наименее значимых бит от Bridge Priority и вписываем туда номер VLAN. На старых Cisco можно увидеть отсутствие схемы Extended System ID. Это на тех моделях, где используется много MAC-адресов.

Вы могли на каждый отдельный виртуальный коммутатор повесить просто отдельный MAC-адрес. И таким образом получить уникальный Bridge ID для каждого VLAN. Но на современных свитчах всегда используется схема с Extended System ID, и отключить её вы не можете. И ещё одна штука, которая здесь не написана, но вопрос такой был — это про стоимости портов. Стоимости портов для Spanning Tree, вот этого PVST-шного, будут по 802.1D 1998 года. Переводим на мнемоническую нашу запоминалку: 119.4.2. Эту штуку надо запомнить. Как я уже говорил, 119.4.2: 100 — это стоимость для 10 мегабит, 19 — это стоимость для 100 мегабит. 4 — это стоимость для гигабита, и 2 — это стоимость для 10 гигабит. Если вы будете переключать в MST, там будут стоимости другие.

Там будут стоимости 2004 года, то есть 20 терабит, делённое на скорость интерфейса. Но если вы используете по умолчанию Rapid PVST или PVST+, то там 119.4.2. Так, дальше. Про Bridge Priority: вы можете задать приоритет. Тот самый приоритет, который влияет на то, кто станет в итоге root-ом. Задаёте вы число, которое будет записываться в десятичном виде. Например, priority 24 576. Хотя на самом деле вы не можете произвольное число задать, но задаётся оно сразу большое. То самое число, которое будет вписываться в 16 бит всего Bridge Priority. Но при этом мы понимаем, что из всех 16 бит 12 бит будут откусаны под Extended System ID. И по факту мы распоряжаемся только старшими четырьмя битами. И поэтому, когда мы задаём число в Bridge Priority, мы задаём число, которое будет состоять из четырёх бит,

которые мы действительно хотим задать, и дальше из пачки нулей, которые потом будут заменены номером VLAN. Это просто такой немножко кривой способ задания четырёх битиков. Поэтому мы задаём число, которое в двоичном виде состоит из четырёх бит, которые мы хотим задать, и дальше 12 бит нулей. Таких чисел ровно 16 штук. Начиная с 0, 0, 0, 0 и дальше куча нулей, до 1, 1, 1, 1 и дальше куча нулей. Возможные варианты вам система предложит, если вы ошибётесь с вводом. Команда по назначению этого самого приоритета будет иметь вид... В глобальном конфиге, простите, да, Spanning Tree. Дальше вы указываете дерево, с которым вы работаете. Вот это VLAN 1 — это не про VLAN на самом деле, это дерево Spanning Tree. В каком дереве вы работаете? Дерево в PVST формируется за каждый отдельный VLAN, поэтому запутаться здесь очень легко. Вы указываете priority, и если хотите, можете вопросик нажать.

Если хотите, можете какое-то число ввести. Система в любом случае, если вы пытаетесь ввести число, которое не кратно 4096, выдаст вам напоминание, что если вы хотите ввести здесь что-то, то вы должны ввести число, которое будет состоять из первых 4 бит, какие хотите, а дальше из 12 нулей. Если число заканчивается на 12 двоичных нулей, то это значит число делится нацело на 4096. Это либо 0, либо 4096, либо 8192, либо 12288, и так далее. Сейчас все зачитывать не буду. По умолчанию у нас будет число, у которого здесь 1, 0, 0, 0 и дальше куча нулей. Это 32 768. Если вы хотите, можете ввести его вручную. Spanning Tree, VLAN 1, priority 32 768. Это и так значение по умолчанию, чего его вводить. Если вы хотите ввести что-то нестандартное, то вы указываете Spanning Tree, VLAN 1, priority, что-то там. VLAN 1 — это то, с каким деревом вы работаете.

И это «что-то там» должно быть в этом списке. Нюанс заключается в том, что вот это значение по умолчанию, поэтому если вы хотите для конкретного коммутатора изменить приоритет, то вы, скорее всего, захотите выставить какой-то приоритет из верхней строчки. То есть либо 0, либо 4096, либо 8192, и так далее. И если мы говорим про Cisco, то мы говорим про то, что у нас коммутаторы, по идее, должны выстраиваться в красивую модель, где у нас два коммутатора distribution или ядра должны равнозначно плюс-минус становиться рутами, а все остальные коммутаторы к ним подключены плюс-минус вот таким образом. И здесь у нас какая-то быстрая связь. Так вот, один из этих коммутаторов должен становиться рутом с большей вероятностью. Давайте мы его обозначим root. Другой коммутатор будет становиться запасным рутом, как бы secondary root, а все остальные должны иметь приоритет хуже,

чем у текущего рута и у запасного рута. И у них приоритет 8.0.0.0. Соответственно, у этого коммутатора самое большое значение, которое мы можем поставить, которое тем не менее меньше, чем вот это шестнадцатеричное, 32 768 десятичное, — это вот такое число. 28 672. И 28 672 — это как раз рекомендованное значение для запасного рута, резервного корневого коммутатора. Тот самый рут, который должен стать рутом, если вдруг текущий основной рут возьмёт и сдохнет. Чтобы не кто-то случайно выбрался, а чтобы именно он выбрался. При этом, если мы это значение резервируем для запасного рута, то соответственно основной рут должен иметь приоритет ещё меньше. И вот классический пример, классическое резервируемое значение для рута — 24 576. Вот эта штука — это значение по умолчанию, это шестнадцатеричное число 8000. Вот эта штука — это значение на единичку меньше в старших 4 битах,

это 7000. И вот эта штука — это соответственно... Ой, наоборот. Нет, нет, всё правильно. Вот это 6000, а вот это 7000. То есть для корневого коммутатора 24 576 — это дефолтное значение минус 2, и для запасного рута дефолтное значение минус 1 — это 7000. Если вы хотите, вы можете выставить в принципе любые значения, которые вам больше понравятся. Предполагайте, что в любом случае кто-то с вот таким приоритетом у вас в сети обязательно окажется. Поэтому если вы хотите, чтобы коммутатор с дефолтным значением заведомо рутом не стал, то текущему руту вы должны выставить значение меньше, чем у него. И запасному руту тоже должны выставить значение меньше, чем у него. Дальше. Как посмотреть на то, кто в итоге выбрался рутом? Есть команда show spanning-tree, и дальше вы указываете, за какое дерево вы хотите показать диагностику.

У нас PVST, который работает по умолчанию, строит сразу много деревьев. По одному за каждый VLAN, который у вас есть в базе и в котором есть хотя бы какой-то порт. Поэтому если мы хотим посмотреть, допустим, дерево за VLAN 1, мы заказываем show spanning-tree vlan 1. И здесь показывается всякое разное, что будет иметь отношение к этому самому дереву. Во-первых, показывается вот эта штука. Это указывает на то, какой конкретно протокол у нас сейчас запущен. Вообще говоря, на Cisco Spanning Tree режим меняется целиком глобально на всём устройстве. Мы не можем сказать, что у нас в отдельном дереве будет строиться медленный Spanning Tree, а в отдельном — быстрый. Так сделать нельзя. Поэтому мы на всей железке целиком меняем режим. Либо медленный Spanning Tree, либо быстрый, либо MST. И Spanning Tree enabled protocol RSTP означает, что у нас быстрый Spanning Tree используется. Если вдруг вам здесь показывается IEEE, вот это, это значит, что это медленный Spanning Tree. Он на самом деле не IEEE.

Это означает, что у вас PVST+. Если у вас показывается RSTP, то это Rapid PVST. Не сказать, чтобы было понятно, почему так сделано, но можно просто запомнить. Дальше. Показывается блок про то, кого вы считаете рутом в этом дереве, какие у него таймеры. И дальше показывается блок про то, кто вы и какие настроены таймеры у вас, но не обязательно, что вы их используете. Этот блок про рута и этот блок про вас. Нижний. Назовем его bridge. Показывается, какой приоритет у рута. Когда вы знаете, кто будет являться рутом, вы знаете это потому, что к вам приходят BPDU-шки о том, кого соседи считают рутом. И может быть такое, что рут — это не вы. Если вы видите, что рутом является кто-то другой, то вы видите просто его приоритет.

К вам приходит BPDU-шка, и у неё левые 16 бит — это биты приоритета. Вы не знаете, откуда конкретно сосед выставил эти биты приоритета. Может, ему администратор выставил вручную, может, там что-то ещё произошло. Может быть, используется схема с Extended System ID. Поэтому вы видите этот приоритет как единый монолитный 16-битный блок. Дальше показывается MAC-адрес рута. Затем следующая строчка. Если вы сами рут, показывается this bridge is the root. Если вы не рут, показывается, какой у вас рут-порт и какое расстояние до рута используется. В нашем случае мы сами рут, показывается, что мы рут. Если мы будем не рутом, будет показано, что до рута лучше всего дойти по интерфейсу GigabitEthernet 0/0, и расстояние до рута будет, допустим, 20. Ну и наконец показываются таймеры от рута, которые приходят. Мы их знаем, потому что все коммутаторы, помимо того, кого они считают рутом, передают то, как настроены таймеры у рута.

И таймеры по умолчанию: здесь мы видим 2 секунды, 15 секунд, и max age — это то время, в течение которого мы будем помнить BPDU-шку, которая недавно приходила, 20 секунд. Но если вы сами являетесь рутом, то вам всё равно здесь показывают непонятно откуда взявшееся число 24 577. При этом про себя, в блоке про самого себя, вы уже точно знаете, откуда взялся ваш приоритет 24 577. Это приоритет — старшие 4 бита, и дальше младшие 12 бит. Используется схема с Extended System ID, и туда вписано число 1, обозначающее номер вашего VLAN. Поскольку работаем мы с деревом за первым VLAN. Дальше показывается ваш собственный MAC-адрес. Показываются HelloTime, MaxAge и ForwardDelay, которые настроены на вас. Вы их не используете, но вы ожидаете, что рут упадёт. Тогда вы объявите рутом самого себя

и начнёте использовать уже их. AgingTime — это время, в течение которого устаревают штатно записи в таблице MAC-адресов. Когда вы выучиваете какой-то MAC на порту, он у вас заносится в табличку MAC-адресов, но он устаревает через 300 секунд. Через 300 секунд штатно — это 5 минут. Если вы не получаете от MAC-адреса никакие кадры на порту в течение 5 минут, то запись из таблицы MAC-адресов удаляется штатно. Она может быть удалена нештатно. Если у нас где-то в топологии происходит какая-то беда, смена топологии будет объявляться, в этом случае все записи из таблицы MAC-адресов получают указание, что они должны быть удалены как можно скорее. И в течение таймера 15 секунд у нас все записи из таблицы MAC-адресов будут удалены. Если у вас используется Rapid Spanning Tree, то там просто все записи удаляются моментально. Дальше. Этот блок показывает,

какие интерфейсы входят в ваше дерево VLAN 1. То есть какие интерфейсы подключены к виртуальному коммутатору. И показывается здесь, что у нас есть GigabitEthernet 0/0, GigabitEthernet 0/1, 0/2 и 0/3. Здесь показываются и access-порты, и транки. Но на каждом интерфейсе показывается его роль в дереве за VLAN 1. В нашем случае, поскольку мы root, у нас все порты designated в состоянии forwarding. То есть порты нормально коммутируют трафик, они разблокированы. Роль показывает, почему порт находится в том или ином состоянии. А состояние — это что конкретно порт делает. Forwarding означает, что порт нормально коммутирует трафик, а designated означает, что он нормально коммутирует трафик, потому что он находится ближе всего к root, чем какие-либо другие коммутаторы в этом сегменте. Затем показывается напротив каждого порта его стоимость. Здесь стоимость 4, что намекает на то,

что у нас гигабитные интерфейсы получают стоимость 4 по формуле 100, 19, 4, 2. 100 для 10-мегабитного интерфейса, 19 для 100-мегабитного интерфейса, 4 для гигабитного интерфейса, 2 для 10-гигабитного интерфейса. В нашем случае гигабитные интерфейсы — стоимость 4. Дальше. Напротив каждого порта показывается его тип. P2P значит, что это point-to-point link, смотрящий либо на соседний свитч, либо на конечного пользователя. Заранее неизвестно, есть ли там соседний свитч или нет. По умолчанию Cisco предполагает, что соседний свитч там может быть. Поэтому все порты, которые у вас будут на Cisco, они будут обязательно проходить через designated discarding, designated learning, designated forwarding. То есть 30 секунд у вас порт будет недоступен, как только вы его поднимаете. И смена топологии,

как следствие, тоже будет вызывать неприятности. Поэтому если вы хотите, чтобы у вас на порту не вызывалась смена топологии, когда он переходит в up, вы захотите наверняка этот порт объявить как edge-порт. Или, если говорить термином Cisco, это будет PortFast-порт. Мы про него сейчас дальше поговорим. PortFast. И номер порта показывается в этой колонке. Мы про номера портов сейчас не будем говорить. На курсе по свитчингу детально это обсудим. Что касается курса ICND2. Не предполагается, что вы в рамках этого курса начнёте управлять Spanning Tree как эксперт. Количество действий, которые у вас на экзамене будут проверяться, примерно соответствует тому уровню, который от вас потребуется в реальной жизни при настройке Spanning Tree. От вас не потребуется, скорее всего, играть со стоимостями в реальной жизни. Потому что стоимости, которые Cisco назначает штатно, вполне нормальные. Если только у вас не гетерогенная среда, в которой вы используете

смешанное оборудование в странных режимах, типа PVST от HP, PVST от Huawei, от Arista и от Cisco, скорее всего, вам не нужно будет ни играть со стоимостями, ни играть таймерами. Он работает и работает. Пить-есть не просит. Но единственное, что от вас потребуется безусловно в абсолютно любой сети — это, по крайней мере, правильно, корректно назначить рута. И делается это либо с помощью выставления приоритета вручную, либо, если вам очень сильно лень, вы можете воспользоваться макросом. Очень удобные макросы в Cisco есть, которые назначают приоритет текущему свитчу, на котором вы выполняете эту команду, автоматически и, главное, хорошо. Что я имею в виду под словом «хорошо»? Макрос, который будет назначать вас рутом, будет иметь вид spanning-tree, дальше указываете, в каком дереве вы хотите назначить себя рутом, дальше root primary. Этот макрос гарантированно делает вас рутом. Ну, при наличии технической возможности.

Если у всех коммутаторов текущий приоритет будет 32 768, и у вас тоже 32 768, и у текущего рута в этом дереве VLAN 1 тоже будет приоритет 32 768 — это значит, что вы как администратор забили полный болт на настройку Spanning Tree, и вот сейчас вы проснулись и захотели настроить этот самый Spanning Tree так, чтобы стало хорошо. В этом случае вам, как коммутатору, который сейчас должен стать рутом, автоматически выставляется приоритет 24 576. Тем самым у всех будет приоритет 32 768, а у вас будет приоритет 24 576. Как раз то, что и хотелось. Если у текущего рута приоритет другой, вам выставляется приоритет либо такой же, как у текущего рута, если ваш MAC-адрес меньше, чем у него, либо приоритет на единичку, то есть на 4096 в терминах Cisco, меньше, чем у него, если ваш MAC-адрес больше.

То есть у вас bridge ID гарантированно станет меньше, чем у текущего рута, минимально меньше, так чтобы только-только стать рутом впритирочку. Если у текущего рута приоритет, например, будет 5000, и MAC-адрес 00:00:00:00:00:01, то вам выставится приоритет 4000, и у вас MAC-адрес будет какой-то другой, то есть явно уже не 00:01. Если же у текущего рута приоритет будет 5000, и MAC-адрес F0:00:01, а у вас MAC-адрес будет, скорее всего, меньше, то вам приоритет поставят такой же, как у него, и дальше MAC-адрес какой-то будет, он меньше, чем у него, поэтому это автоматически сделает вас рутом. Эта штука довольно прикольно работает, и она гарантирована, если только у текущего рута приоритет не 0 000, и MAC-адрес не 0 0001, если вы имеете в виду,

если есть такая техническая возможность сделать вас рутом, то она вас делает рутом. Вы при этом, естественно, устраиваете смену топологии, но после смены топологии все понимают, что рут — это вы. Есть еще один макрос, Spanning 3, дальше указываете дерево, root secondary, например, Spanning 3, VLAN 1, root secondary. Этот макрос выставляет вас резервным рутом, но он при этом не делает ничего специального, никаких вычислений, как делает Spanning 3 root primary, он не смотрит на текущий приоритет рута, он вам жестко прибивает гвоздями приоритет 28672. В той логике, что у всех нормальных свичей приоритет дефолтный — 8000, шестнадцатеричные. Если вам выставить приоритет 7000, то в этом случае вы будете с большей вероятностью рутом, чем просто обычный средний свич, но вы не перехватываете роль у текущего рута. Это не гарантирует вам, что при отказе текущего рута вы обязательно

станете запасным рутом. Может быть такое, что вам дастся приоритет 28672, то есть 7000, шестнадцатеричные, а у текущего рута приоритет 5000. А кроме него есть еще другой свич с приоритетом 6000. А кроме него есть еще какой-то другой с 6000-м приоритетом и другим MAC-адресом. Поэтому это означает, что вы с большей вероятностью станете рутом, чем тот, у которого вообще не настроены никакие приоритеты на свиче, но при этом не гарантирует вам, что при отказе текущего рута именно root-secondary точно станет рутом. Это никто не обещает. Так, про port fast. Я уже сказал, что на циске по умолчанию все порты имеют тип point-to-point. И на этом типе point-to-point вы ожидаете увидеть на всех портах соседние свичи. Как следствие, у вас любой порт, который добавляется в топологию, вызывает ее смену. Это неприятно. Поэтому, чтобы у нас не вызывалась

смена топологии на порту, есть механизм, который называется port-fast. И этот механизм переводит любой порт в designated forwarding сразу, не дожидаясь истечения двух таймеров forward delay. Этот механизм был придуман циской. Изначально он являлся частью механизма, который назывался Cisco Spanning 3 Toolkit, который резко ускорял работу медленного Spanning 3. Но потом он вошел в быстрый Spanning 3 и в 802.1W. Соответственно, это стандартная часть. Любой свич, который умеет сегодня работать с быстрым Spanning 3, он умеет работать и с этой логикой вида: давайте мы пообещаем железке, что на ее порту у нас никогда не будет приходить BPDU. Если на порту действительно не приходят BPDU, то новый порт, который у нас появляется со статусом port fast, он сразу переходит в designated forwarding, не дожидаясь designated discarding, designated learning.

BPDU на таком порту отправляются сразу, но при этом, естественно, они не ожидаются. Если у нас приходит BPDU на таком порту, а она приходит superior, естественно, другие не бывают, то мы делаем то же самое, что сделали бы с любым другим портом. Мы бы заблокировали этот порт, не заблокировали, а перевели в designated discarding, ну или в alternate discarding и запустили бы пересчет топологии. Дальше. Вы не должны включать эту штуку на портах, которые штатно смотрят на соседей. Это либо на портах, которые смотрят на обычных абонентов, либо на транке до сервера. Вы не должны включать эту штуку на динамических портах. Если у вас порт имеет switchport mode dynamic desirable, switchport mode dynamic auto, то это несовместимо с port fast. Вы должны будете жестко прибить гвоздями switchport mode access, или, если очень сильно хочется, switchport mode trunk,

если это у вас на свиче порт, который смотрит на сервер, куда вы хотите подать кучу виртуалок. Включается либо на уровне отдельного интерфейса командой spanning-tree portfast edge. Но это неудобно делать, если у нас много интерфейсов. Мы, конечно, можем interface range взять, пробежаться по всем интерфейсам, макросам, и сказать, давайте на всех них повесим spanning-tree portfast edge. Но намного прикольнее воспользоваться такой фиговиной. Вы указываете в глобальном конфиге, не в настройке интерфейса, а в глобальном конфиге, команду spanning-tree portfast edge default. И тогда все порты, которые у вас по факту работают в access, они получат статус port fast. Очень удобная вещь. Настоятельно рекомендуется к использованию. Вы объявляете, что у вас все порты, которые не транки, они будут работать в forwarding сразу. Рекомендуется к использованию эта команда. Дальше. Что еще здесь у нас будет?

На старых свичах слова edge не было. Те свичи, которые штатно работали с PVST, команда spanning-tree portfast edge не содержала слова edge. Она содержала только spanning-tree portfast. Связано это было с тем, что сам механизм port fast изначально был придуман циской, и изначально входил в механизм Cisco Spanning Tree Toolkit. Соответственно, никакого edge там не было, потому что это был свой фирменный механизм port fast, и он там сочетался с такими механизмами, как uplink fast, backbone fast. Это всякие разные ускорялки для медленного Spanning Tree. И одна из них была port fast. Потом, когда этот механизм вошел в быстрый Spanning Tree, он там стал называться edge port. И для того, чтобы подчеркнуть, что это edge, конечно, стандартный, но все-таки наследие циски, циска стала называть этот механизм port fast edge. И команда, соответственно, называется spanning-tree portfast edge. Port fast edge — это новое название того,

что раньше называлось просто port fast. Поэтому на старых IOS слова edge нету, есть spanning-tree portfast. На новых IOS spanning-tree portfast edge. Но если вы попытаетесь ввести просто команду spanning-tree portfast, она тоже ее сожрет. И та же команда, которая включает spanning-tree автоматически на всех access-интерфейсах, она раньше называлась spanning-tree portfast default. На новых IOS spanning-tree portfast edge default. Если вы попытаетесь выполнить старую команду на новом IOS, система ее примет. Она в справке не будет показывать, что можно ввести spanning-tree portfast default. Она будет от вас требовать ввести edge. Но на самом деле сработает, даже если вы введете так. Если вы включаете port fast, вы тем самым говорите: я, как администратор, обещаю, что на определенном порту никогда не будут приходить BPDU. Но если BPDU начинают приходить, получается, что администратор наврал. И это очень странно, когда администратор говорит, я обещаю,

а потом он, получается, врет. Как-то нехорошо. Обычно то, что на абонентском порту у нас начинают приходить BPDU без ведома администратора, свидетельствует либо о том, что администратор брехло, либо о том, что на порту у нас завелась какая-то нездоровая активность. Либо абонент начинает присылать BPDU, потому что он пытается прикинуться свичом, либо он взял в тот порт, в котором мы на него смотрим, воткнул свой собственный свич. В любом случае это какая-то нездоровая фигня. Поэтому обычно port fast сочетается с фирменной цисковской технологией, которая, впрочем, у других вендоров тоже есть, которая называется BPDU guard. Этот механизм указывает, что если на порту приходит BPDU, то такой порт нафиг расстреливается. Просто выключается, и все. Очень здорово сочетается с port fast. Когда мы говорим, что у нас на порту работает port fast, мы говорим: этот порт, не дожидаясь того, что на порту в течение 30 секунд не будут приходить BPDU, сразу переходит в forwarding. И рядышком с ним работает BPDU guard, который говорит: а если BPDU все-таки приходит,

то порт расстреливается. Коммутация выключается, причем, если мы говорим про BPDU guard, он не на уровне Spanning Tree работает, он работает на уровне самой железки, он натурально выключает порт. Порт получает так называемый статус err-disabled. Это не про то, что Spanning Tree блокирует порт, как следствие — пересчет топологии и все такое. Это просто выключение порта без указания, что у нас там что-то произошло. Рекомендуется сочетать на портах конечных абонентов механизм port fast и BPDU guard. Включается либо на уровне отдельного интерфейса командой spanning-tree bpduguard enable, либо на уровне всей железки целиком — команда spanning-tree portfast edge bpduguard default. В принципе, неплохой идеей будет включить на portfast-интерфейсах на всех предприятиях, подчеркну — предприятиях, этот механизм. Но имейте в виду, что если вдруг BPDU guard на порту сработает, то он вам этот порт переведет в err-disabled,

и коммутация на этом порту не будет работать вообще. Для того чтобы порт из err-disabled выгнать, надо будет либо shutdown / no shutdown ему сделать, но при этом надо будет убедиться, что с той стороны BPDU больше не приходят, потому что иначе у вас порт опять упадет в err-disabled. Либо настроить автоматическое очищение статуса err-disabled на порту по какому-то периоду, например, 5 минут. В любом случае, если администратор пообещал, что на порту активности не будет, а по факту она там есть, это какая-то нездоровая фигня, и лучше, почти всегда лучше порт пристрелить, и дальше уже ставить паяльник на разогрев и идти разбираться, что случилось. Так, давайте попробуем все это дело пощупать. Давайте попробуем сейчас на наших свичах посмотреть, что у нас со Spanning Tree происходит, и плюс к тому, если я правильно помню, с предыдущего занятия у нас на свичах есть некоторое количество VLAN-ов, которые мы создали.

У нас есть первый VLAN, и у нас есть какой-то кривой VLAN, который мы делали, там 101, 102, 108. В принципе, нам этого будет достаточно. Переводим наши свичи в привилегированный режим и смотрим show spanning-tree VLAN 1. Мы точно знаем, что у нас есть первый VLAN, мы точно знаем, что у нас наши свичи работают в режиме PVST, поэтому деревья они строят именно за VLAN. И наш свич сейчас знает кое-что про топологию Spanning 3. Spanning 3 Enabled Protocol EEEE. Вот он намекает на то, что у нас работает сейчас медленный фирменный цисковский Spanning 3. Вот это вот не EEE802.1D, это 802.1D основой был для протокола PVST+. И вот именно он на самом деле у нас работает. Показывается, что мы знаем про рута в дерево первого вилана. Мы знаем, что у него приоритет был 32769.

Мы знаем, что у него MAC-адрес был вот такой. Мы знаем, что добраться до него от моего свеча стоит 200 копеечек. И мы знаем, что рутовый порт у него, соответственно, вот до него как лучше всего добраться через Ethernet 0.1 порт. Таймеры вот такие вот. Дальше мы знаем кое-что про самого себя. Мы знаем, что у нас приоритет тоже 32769, но мы не стали рутом, потому что мы MAC-адресом не вышли. MAC-адрес у нас какой-то вот другой. И явно он больше, чем вот этот MAC-адрес. в отличие от рута, который себе хапнул приоритет 32769 каким-то непонятным образом, наверное, по блату, свой Bridge Priority мы точно знаем, откуда взялся. То есть каждую его копеечку мы заработали своим трудом. И, соответственно, это приоритет 32768, левые 4 бита, если хотите, и, соответственно, все остальные 12 бит это единичка, номер Вилана. Учитывая, что у нас номер Вилана 1, в общем, все честно, все действительно как и предполагалось.

Таймеры, которые у нас настроены, никто не трогал, и они вот такие вот по умолчанию. И затем показываются интерфейсы, которыми мы в первом Вилане работаем со Spanning 3. Ethernet-ы все, которые есть, они все с первым Виланом умеют работать. Показывается, что Ethernet 0.0 это интерфейс, которым наш свитч смотрит на роутер, он designated. Показывается Ethernet 0.1 это порт, который мы смотрим на центральный свитч, он рутовый, мы оттуда принимаем BPD-ушку вкуснее, чем мы могли бы сами отправлять. Поэтому он, тот, кто другой нам отправляет BPD-ушку, находится ближе к руту, чем мы. И вот мы говорим, мы на одном порту Ethernet 0.1 получаем вкусную BPD-ушку, и на другом порту Ethernet 0.3 получаем вкусную BPD-ушку. Но один из портов мы объявляем рутовым, а другой порт мы объявляем alternate. На рутовом порту у нас forwarding, на alternate порту у нас блокировка, ну, то есть discarding, это такое обозначение alternate discarding. Все порты 10-мегабитные

имеют стоимость 100. Дальше. На цисках по умолчанию работает механизм, который позволяет угадывать тип порта, и вот все вот эти вот ускорялки, характерные для быстрого Spanning 3, включаются, когда у вас интерфейс работает в полном дуплексе. Все наши интерфейсы на свитчах полнодуплексные, поэтому тип здесь угадывается point-to-point. Еще есть вариант, если у вас half-дуплекс используется, там тип среды shared, сохран показывается, это означает, что у вас все ускорялки Spanning 3, быстрого Spanning 3, они выключены. То есть там никаких у вас пропозалов, агриментов не будет, все будет по-честному, по-медленному. Давайте попробуем чего-нибудь поделать. То есть прикольно, конечно, что у нас есть диагностика какая-то, но все-таки мы же пришли сюда конфигурировать, и давайте мы возьмем и посмотрим, что мы можем настроить в Spanning 3. Я сейчас вспомню, что у меня был VLAN, который я настраивал. Это был VLAN 108, а у вас там VLAN 101, 102 и так далее. И я хочу сделать так,

чтобы в моем вот этом 108 VLAN именно я стал рутом. И причем я стал не просто рутом, а я стал рутом с основаниями на то, чтобы у меня приоритет при работе с Spanning 3 в этом VLAN был бы правильный. Поэтому команда, которую я буду использовать, практически единственная команда, которую в этом модуле мы прошли, это назначение приоритета. Spanning 3 VLAN дальше, какой у меня там VLAN 108 был. Вы тоже у себя делаете, одно с другими VLAN-ами. И priority. Если я сейчас введу какой-нибудь приоритет, который не кратен 4096, ну не знаю, приоритет 1 поставлю. Система будет ругаться, говорить, что так не бывает, надо, чтобы заканчивалось на 12 битвах нулей. Ну, да, окей. Не нравится, так не нравится. И давайте поставим приоритет, ну не знаю, вот такой вот, 16384. Имеем право. Команда срабатывает. Spanning 3 у нас перестраивается,

то есть у нас топология изменяется. Но за счет того, что скорее всего в этом VLAN рутом раньше был я сам, то порты, скорее всего, У нас не переходят через состояние discarding до learning. Они как были в forwarding, они так и останутся. Потому что смена приоритета на текущем root — это не смена топологии, как ни странно. Если root у нас не меняется, ничего не происходит. Давайте теперь посмотрим на show spanning-tree VLAN 108. У нас наш VLAN 108 дерево. Показывается, что это по-прежнему медленный spanning-tree. Показывается, что действительно у нас есть root, и это действительно мы. Мы про root знаем, что это мы. Показывается, что приоритет у текущего root не 16384, а 16492. Но поскольку в этом блоке обычно рассказывается

про root, система не показывает, откуда взялось это 16492. Показывается просто, что приоритет у root вот такой. В то же время в блоке про нас, уже 16492 — наши собственные рассказываются, откуда они взялись. Приоритет — левые 4 бита 16384, 0100, и extended system ID 108, это номер VLAN. Действительно, номер VLAN у нас 108. И мы для того, чтобы подчеркнуть, что у нас на двух виртуальных коммутаторах разные bridge ID используются — на одном у нас будет bridge ID с extended system ID единичка, на другом будет extended system ID со 108. И мы можем приоритетами играть как угодно, не опасаясь, что у нас bridge ID пересекутся на разных коммутаторах. В любом случае, вписывая сюда номер VLAN, получится, что пересечение невозможно. Дальше показывает MAC-адрес. Он у нас всего один, мы не можем его менять. Таймеры, которые у нас используются,

мы не трогаем. И все интерфейсы, которые входят в обслуживание VLAN 108, и access-интерфейсы, и транки, они здесь перечислены. И все порты, поскольку мы root, designated forwarding. И стоимость у них 100. Мы стоимость будем принимать во внимание только если мы будем получать BPDU. Поэтому на самом root стоимости не сильно кому-то интересны, но тем не менее стоимости по-прежнему по умолчанию 119.4.2. Что нужно будет сделать на реальной сети, если мы на уровне CCNA хотим работать со spanning-tree? Во-первых, правильно назначить корневой коммутатор. Скорее всего, даже не просто правильно назначить корневой коммутатор, а правильно назначить и корневой root, и запасной root. Для этого мы можем воспользоваться макросом. Он возьмёт и сразу правильно назначит приоритет. spanning-tree VLAN 108 root. Если я здесь

сделаю primary, он посмотрит на текущего root. Если это не мы, то сделает нам приоритет такой, чтобы мы стали root. Поскольку мы сейчас уже root, этот макрос не сделает ничего. Если я сделаю root secondary, то он мне приоритет поменяет на такой, который будет на единичку лучше, чем дефолтный. То есть 28672. Do show spanning-tree VLAN 108. Вот он. Гвоздями прибил 28780. Это 28672 плюс extended system ID 108. Удобно на том коммутаторе, который у вас, например, distribution, один из distribution switch, сказать spanning-tree VLAN root primary, а на другом — spanning-tree VLAN чего-то root secondary. И у вас на этих двух distribution switch как раз правильные приоритеты проставятся. На одном будет 28672 плюс номер VLAN, на другом 24576 плюс номер VLAN. И так отдельно в каждом VLAN это можно будет сделать.

В принципе, если у вас пачка VLAN сразу есть, вы можете воспользоваться тем, что здесь можно указать сразу диапазон VLAN. Вы можете сказать со 108 по 116 VLAN root primary. Одновременно на все VLAN сделается всё это скопом. Довольно удобно, если у вас эти VLAN идут диапазонами. Почему не надо на все VLAN одинаково делать root primary, вообще все, которые у вас есть? Почему есть смысл на часть VLAN делать root primary, а на часть — root secondary? Дело в том, что если у нас используется, допустим, access switch, от которого идут провода до двух distribution switch — мы не хотим, чтобы у нас штатно в access были заблокированы все VLAN в одном trunk, и разблокированы все VLAN в другом trunk. Мы чаще всего хотим сделать так, чтобы часть VLAN входила по одному trunk, часть VLAN по другому. Поэтому мы как раз в реальной топологии будем говорить, давайте левую половину VLAN сделаем

root левый switch, правую половину VLAN сделаем root правый switch. И тогда у нас левая VLAN работает по факту тоже два порта, типа балансировка. Ну и поэтому да, вот удобно сказать, что какие-то VLAN, которые мы делаем, у них root будет один, а для других VLAN root будет другой. И это будет выглядеть как то, что там Sparling 3 VLAN 108 116 root primary, Sparling 3 VLAN 117 129 root secondary на одном switch. А на другом switch с точностью наоборот. Для VLAN, которые мы на одном switch делали root primary, там делаем root secondary. Ну, я думаю, идею вы поняли. Так, и, собственно говоря, второе действие, которое нужно будет сделать, если у вас EOS старый. Вот у меня EOS старый, и поэтому Sparling 3 у меня по умолчанию работает в медленном режиме, мне его нужно перевести в быстрый. Modia rapid pvst. Эта вот команда, она переведет switch в быстрый режим, то есть включает

те ускорения, которые характерны для 802.1w или 802.1w 2004 года. И после этого та же самая команда showsparing3 VLAN 108 покажет нам, что у нас произошли какие-то изменения. Вот видите, порты вроде бы designated, но при этом blocking. Я сейчас еще раз покажу через некоторое время. Designated learning и designated forwarding. Сейчас будет. Где же? 15 секунд в designated learning все порты висят. Вот 15 секунд прошло, перешло в designated forwarding. То есть, несмотря на то, что у нас используется быстрый spanning 3 свитч, все равно за счет того, что у нас не обнаружены по факту ускорители, которые можно было бы поддержать, все равно свитч по факту работает в медленном режиме. Мы включили быстрый spanning 3, вот здесь никто не спорит, быстрый spanning 3, но из-за того, что на пропозал наш никто не отреагировал, на абонентских портах

некому реагировать, на портах, которые смотрят на центральный свитч, там точно так же работает медленный spanning 3, он не реагирует на пропозал и не присылает агрименты. По факту, мы 30 секунд с момента включения быстрого spanning 3 наблюдали картинку, что наша топология не работоспособна. После того, как все порты из designated discarding перешли в designated learning и потом designated forwarding порты включились, трафик начал ходить. Если мы хотим сделать так, чтобы у нас порты разблокировались сразу после включения, например, свитча, после смены топологии, мы должны будем дать команду либо в настройке конкретного интерфейса, либо spanning 3 port fast edge default. Система предупреждает, что с осторожностью надо пользоваться port fast, потому что херено что там случится, если особенно вы смотрите портами в аксессовом режиме на другие свечи неуправляемые или на хабы или вообще там

непонятно на что, потому что, ну, как бы там возможно временные какие-то проблемы, которые у вас возникнут. Да, понятное дело, через некоторое время spanning 3 отработает это, но в течение первых там двух секунд, когда у нас отправляются по подушки, как часто отправляются по подушки, вот там возможно кратковременная петля. Ну, и для того, чтобы защититься окончательно, spanning 3 port fast port fast bpdu так, я что, промахнулся, spanning 3 bpdu guard default, простите, bpdu spanning 3 port fast стедж забыл, bpdu guard default. Вот, эта команда указывает на то, что все порты, которые получили статус port fast, они, конечно же, могут переходить в disegnate forwarding

сразу, но при этом на получение bpdu, наш switch отреагирует, ну, крайне негативно. Он пристрелит такой порт. Как бы мне вам показать, что действительно это происходит. Давайте я возьму, вот какую штуку сделаю. Так, у меня есть интерфейс Ethernet 0.3, и на этот Ethernet 0.3 приходят BPDU от соседа. Сейчас этот порт транковый, потому что там прописана команда — do show run interface Ethernet 0.3. Там прописана команда switchport mode dynamic desirable. Я её оттуда уберу. Скажу, что не надо нам dynamic desirable, надо нам dynamic auto. И выключу этот порт. Shutdown. И включу этот порт заново. No shutdown. После того как порт включается, порт переходит в access. На порту вешается BPDU guard. Приходит BPDU от соседа и приводит это к такой штуке. У нас получена BPDU на абонентском порту. BPDU guard срабатывает.

Говорит: получена BPDU на порту Ethernet 0.3, там, где работает BPDU guard. Выключаем порт. Соответственно, у нас порт переходит в состояние err-disabled. На нём канальный уровень выключается. Что интересно, физика на нём работает. Лампочка на нём горит. Возможно, горит рыженьким, но тем не менее горит. Но логический уровень на этом интерфейсе будет выключен. И, соответственно, show interface Ethernet 0.3 нам покажет, что интерфейс находится в состоянии err-disabled. Мы его можем выключить-включить после того, как разберёмся с проблемой, и состояние err-disabled на нём будет счищено. Payconft. Что бы нам сделать такое? Давайте его обратно в DTP переведём. Switchport mode dynamic desirable. Так, интерфейс Ethernet 0.3. Shutdown.

Казалось бы, он уже выключен, но нет, его надо shutdown и после этого no shutdown. Порт переводится в административный down, порт поднимается. И если мне сейчас повезёт, и DTP отработает раньше, до того как порт будет пристрелен BPDU guard'ом, судя по всему, мне повезло. Соответственно, порт согласовал trunk, перешёл в транковый режим, не получил portfast, не получил BPDU guard на порту и корректно, нормально работает. Вот эти команды, которые мы с вами прошли — это назначение приоритета, возможно, с помощью макросов, это переключение в быстрый режим и назначение portfast на портах — это всё, что нужно сделать для того, чтобы Spanning Tree у вас работал хорошо. Если у вас это так в вашей компании, то, соответственно, вы защищены от петель. Защищайтесь от петель, потому что это не вопрос того, когда в сети возникнет петля, это вопрос того, произойдёт ли это в ближайшее время или нет. Наиболее частый случай возникновения петли — это неумышленное возникновение петли,

когда у вас есть пользователь, он видит, что, например, где-то болтается патч-корд, он видит в стене две розетки, он берёт, подходит к этой розетке, включает патч-корд просто в две розетки одновременно. На вопрос, зачем ты это сделал, он говорит: ну он болтался просто так. Или, например, у вас есть IP-телефон, у него есть два разъёма: один для подключения к свитчу, другой для подключения компьютера к телефону, для того чтобы на рабочее место у вас тянулось не два провода, а один, чтобы компьютер не подключать отдельным проводом к розетке в стене. Есть люди, которые видят две дырки в телефоне и говорят: у нас есть две дырки в телефоне, у нас есть две розетки в стене, давайте мы двумя проводами подключим к розетке в стене, может, так в два раза лучше будет работать, очевидно же. Но тем самым они, естественно, устраивают петлю, потому что внутри IP-телефона там маленький свитчик есть. И приводит это, понятное дело, к весьма весёлым последствиям: может быть, загрузка этого телефона не позволит в стопроцентную нагрузку уложить ваши транзитные свитчи, но при этом база MAC-адресов у вас будет флапать.

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

пожалуй, хватит. Я надеюсь, что вам было интересно, и на этом предлагаю тему со Spanning Tree закончить. Субтитры создавал DimaTorzok