для чего нужен stp
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Протокол Spanning Tree – самое важное
Протокол Spanning Tree (STP) обеспечивает отсутствие петель в топологии любой сети. Помимо предотвращения петель, STP изолирует угрозу от широковещательного шторма в сетях на втором уровне модели OSI (L2). Разберемся в терминах:
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Какие бывают порты?
Можно смело выделить 3 вида портов в рамках протокола Spanning Tree. А именно:
Статусы портов
Порт коммутатора может находиться в различных статусах, в зависимости от результата сходимости Spanning Tree:
BPDU (Bridge Protocol Data Unit) это фреймы, необходимые для обмена сообщениями между коммутаторами для выбора корневого (root) устройства в рамках механизма протокола STP (Spanning Tree Protocol).
Этапы протокола STP
Выбор корневого коммутатора
Например: 24577.00:00:00:00:00:01 / Приоритет. MAC – адрес
В процессе выбора корневого коммутатора, первым делом сравнивается приоритет. Если у двух коммутаторов одинаковых приоритет, то выбор базируется на MAC – адресе устройства.
Выбор корневого порта
Корневой порт выбирается на основании наименьшей «стоимости» пути к корневому коммутатору. Стоимость пути выражается из стоимости линков, ведущих к корневому коммутатору.
Выбор назначенного порта
Если два порта имеют одинаковую стоимость, сначала учитывается идентификатор устройства (Bridge ID), а затем идентификатор порта (Port ID).
Все остальные порты переходят в альтернативный статус и блокируются.
До запуска алгоритма Spanning Tree:
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Полезно?
Почему?
😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.
😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.
Закольцованные сети, или зачем нам STP
Суть проблемы
Целью жизни коммутатора сетевого (он же свитч) является неустанная пересылка пакетов от отправителя получателю. Для оптимизации работы, свитч содержит т.н. CAM-таблицу, содержащую в себе адреса устройств, пакеты от которых он когда-то получал, и номера физических портов, из которых эти самые пакеты были получены.
Но что делать свитчу, если приходит широковещательный пакет (broadcast)?
Логично предположить, что такие пакеты пересылаются во все порты, кроме того, откуда изначально были получены.
Что, при определённой конфигурации сети, может привести к весьма печальным последствиям…
Предположим, несколько свитчей соединены так, что в системе образуются замкнутые петли.
Что произойдёт, если свитчу 1 из облака придёт широковещательный пакет? Он размножит его и передаст в порты 1, 2 и 3 (из порта 4 пакет пришёл, так что обратно в него отправлен не будет). Свитч 2, получив пакет на 2 порту, отправит его копии в порты 1 и 3. Свитч 3, получив пакет на порту 1, отправит его копии в порты 2 и 3. Свитч 4, получив пакет на 3 порту, отправит его копии в порты 1 и 2. После чего каждая копия, передаваясь от устройства к устройству, будет размножена по этой же схеме всё больше и больше, пока суммарно они не займут всю доступную полосу пропускания (или не забьют мозги устройствам до потери их работоспособности).
Но, в то же время, обойтись совсем без «петель» в сети — никак невозможно, поскольку важнейшим свойством хорошей сети является отказоустойчивость. То есть, между любыми двумя важными узлами сети (компьютер рядового пользователя я тут в расчёт не беру) должно быть более одного физического пути на случай выхода из строя канала или промежуточного устройства. А это значит — петли.
STP спешит на помощь
Проблему вышеописанных «широковещательных штормов» решает запуск на свитчах протокола STP (или одного из его расширений).
Spanning Tree Protocol, или протокол простирающегося древа, приводит сеть к «древовидному» виду — с корнем и растущими из него «ветвями». Один из свитчей становится «корнем» (root bridge), затем все остальные рассчитывают «стоимость» (cost) достижения корня из всех своих портов, имеющих такую возможность (то есть, по сути, закольцованных где-то там, далеко), и отключают все неоптимальные линки. Таким образом, разрывая «петли». Если в дальнейшем в сети произойдёт сбой, и «корень» вдруг окажется недостижим через работающий порт, включится лучший из ранее заблокированных и связь будет восстановлена.
А теперь подробнее
Основной «рабочей лошадкой» STP являются Bridge Protocol Data Units aka BPDU. Это пакеты-«зонды», рассылаемые свитчами, и содержащие в себе:
1) идентификатор корневого свитча (Root ID);
2) идентификатор свитча, сформировавшего пакет (Bridge ID);
3) стоимость пути от второго к первому (Cost);
4) порт, из которого BPDU был исторгнут.
Предположим, сеть только что включили. Свитчи друг о друге ничего не знают. Нужно найти друг друга и выбрать, кто же станет «корнем» дерева. Свитчи дружно начинают сыпать во все порты BPDU, где указывают «корнем» себя любимого (Root ID).
STP работает так, что выйгрывает «выборы корня» свитч с самым низким Bridge ID, который состоит из двух частей: 2-байтный приоритет (по умолчанию 32768) и MAC-адрес свитча. Таким образом, если никаких настроек не производилось, и приоритеты у всех равны, выйграет свитч с самым маленьким MAC-адресом. Есть весьма отличная от нуля вероятность, что это будет самый старый (и, наверно, самый низкопроизводительный) свитч в организации, с закономерным итогом… Не забывайте об этом, друзья. Настраивайте приоритеты!
Итак, свитч с самым низким ID игнорирует принятые BPDU товарищей и продолжает гнуть свою линию — слать раз в 2 секунды свои BPDU, такие же точно, как самый первый. Он — «корень» топологии, он не будет отключать свои порты.
А вот остальные, получив BPDU со значением Root ID меньше, чем свой собственный Bridge ID, понимают, что «корень» — где-то там. Они перестают рассылать свои BPDU. Отныне и впредь, они просто ретранслируют BPDU «корневого» свитча, подставив на место Bridge ID себя, и пересчитав «стоимость» достижения «корня» (добавив к имеющейся в полученном BPDU свою долю).
Значение стоимости зависит исключительно от скорости интерфейса, из которого пришёл BPDU, и может быть посмотрена интересующимися например, здесь.
Порт, из которого был получен корневой BPDU с наилучшей стоимостью, называется root-портом, он всегда работает. Порты, из которых получены корневые BPDU с худшей стоимостью, очевидно, ведут в «петли», от которых и нужно избавиться. Такие линки блокируются с одной стороны тем свитчом, чей Bridge ID ниже. Но блокируются не полностью, нам ведь надо иметь возможность вернуть их к жизни в случае сбоя. BPDU в таких линках продолжают отправляться и приниматься.
Если же Bridge ID в обоих пакетах одинаков (например, свитчи соединены более чем одним кабелем), выйгрывает тот, в котором указан меньший номер отправившего порта (Fa0/1 выйграет у Fa0/2).
Виды портов
В классическом STP, определённом стандартом 802.1d, порты могут быть такими:
1) Root port — ведёт к корню, имеет наименьшую стоимость среди собратьев, включён.
2) Designated port — ведёт не к «корню», а в какой-то сегмент сети, работает.
По понятной причине, у «корневого» свитча нет ни одного root порта. Все его порты — designated.
3) Blocked port — ведёт к корню и имеет нелучшую стоимость пути. Заблокирован для всего трафика, кроме BPDU. С другой стороны на этом линке — работающий designated port.
Состояния и переходы
Но самое, пожалуй, интересное — состояния портов. Выше я делил их всего на 2 — работает или заблокирован. На самом деле, их больше, по той простой причине, что работа STP — штука отнюдь не мгновенная, она требует времени. А создать шторм в сети — дело очень быстрое. Поэтому, «во избежание», так сказать, порты проходят через цепочку состояний в процессе работы.
1) Listening — порт включился (воткнули кабель/дали питание).
Передавать трафик страшно — а вдруг петля? Поэтому трафик не передаётся никакой, кроме BPDU. Ищем корень, прикидываем, какие порты будут работать.
Продолжительность — 15 секунд по умолчанию, диод на свитче моргает оранжевым.
2) Learning
Передавать трафик ещё страшно, но свитч уже принимает пакеты помимо BPDU, запоминает MAC-адреса в CAM-таблицу.
Продолжительность — 15 секунд по умолчанию.
3) Forwarding
Лампочка замигала радостным зелёным цветом, порт работает и передаёт данные.
4) Blocking/Disabled
Ну тут по названию всё ясно. Либо линк пришлось отключить, дабы не создавать петлю, либо порт административно выключен.
Обратите внимание, что минимум 30 секунд проходит с момента включения порта до начала передачи данных. В случае быстро загружающегося компьютера (или воткнутого в порт IP-телефона) это может создать проблему. (Решается включением режима portfast, но это тема для другого разговора.)
В случае сбоя в сети, где-то, где BPDU раньше ходили, они ходить перестают. И Blocked-порты, теперь получающие лучшие BPDU, выждав таймаут (20 секунд), переводятся в режим Designated, проходя цепочку состояний Listening — Learning — Forwarding (+30 секунд).
Таким образом, восстановление работоспособности сети может занимать до 50 секунд. Но, согласитесь, это гораздо лучше, чем неработоспособность после сбоя вообще.
И напоследок
Впоследствии, недостатки STP, о которых я упомянул (медленное восстановление работы сети), и о которых не упомянул, решались расширениями к протоколу.
Рассмотрим их вкратце.
1) RSTP (Rapid, быстрый)
Хранит в памяти кандидата на замену вышедшему из строя Root-порту (второе место по степени «наилучшести»), и способен очень быстро переключиться на него, не ожидая всех таймеров. Не получил 3 BPDU подряд на Root порте? Переключаюсь без лишних размышлений.
2) PVST+ (Per VLAN, по VLANный)
Зачем блокировать весь линк? Напрасная трата ресурсов! А давайте для каждого VLANа рассчитаем свою топологию STP, независимую. Таким образом, для одного VLAN будут одни линки заблокированы, а для другого — другие. Закон соблюдён и польза несомненна. При этом, в отправляемых BPDU номер VLANа хранится… в приоритете. 12 младших бит отданы под номер VLANа, а из 4 старших формируется, собственно, приоритет (имеющий при таком раскладе всего 16 легальных значений, с шагом 4096). Поле «приоритет» по умолчанию для VLAN 3 будет, таким образом, 32768 + 3 = 32771.
Cisco-проприетарный, сочетает свойства первых двух.
PVST+ хорош, спору нет, но что если у нас over 9000 VLANов? Просчёт топологий для каждой из них может сильно загрузить процессор. Да и нужно ли это, если мы не занимаемся тонкой настройкой каждой полученной топологии? MST позволяет сгруппировать VLANы в т.н. instance (наборы), рассчитывая топологию уже для этих, более крупных образований.
В процессе написания
Использовались википедия и остатки знаний курса CCNA в голове.
Принцип работы протокола STP
Причина создания STP
Причиной создания протокола STP стало возникновение петель на коммутаторах. Что такое петля? Определение петли звучит так:
Петля коммутации (Bridging loop, Switching loop) — состояние в сети, при котором происходит бесконечная пересылка фреймов между коммутаторами, подключенными в один и тот же сегмент сети.
Из определения становится ясно, что возникновение петли создает большие проблемы — ведет к перегрузке свитчей и неработоспособности данного сегмента сети. Как возникает петля? На картинке ниже приведена топология, при которой будет возникать петля при отсутствии каких-либо защитных механизмов:
Возникновение петли при следующих условиях:
1. Какой-либо из хостов посылает бродкаст фрейм:
2. Также петля может образоваться и без отправки бродкаст фрейма.
Основы STP
Принцип работы данного протокола построен на том, что все избыточные каналы между коммутаторами логически блокируются и трафик через них не передается. Для построения топологии без избыточных каналов строится дерево (математический граф). Чтобы построить такое дерево вначале необходимо определить корень дерева, из которого и будет строиться граф. Поэтому первым шагом протокола STP является определение корневого коммутатора (Root Switch). Для определения Root Switch-a, коммутаторы обмениваются сообщениями BPDU. В общем, протокол STP использует два типа сообщений: BPDU — содержит информацию о коммутаторах и TCN — уведомляет о изменении топологии. Рассмотрим BPDU более детально. Про TCN более подробно поговорим ниже. При включении STP на коммутаторах, коммутаторы начинают рассылать BPDU сообщения. В данных сообщениях содержится следующая информация:
Фрейм BPDU имеет следующие поля:
Вот вывод информации о Bridge ID с коммутатора Switch1 из первой картинки. Priority — 32769 ( по умолчанию 32768 + Vlan Id), MAC-адреса — Address 5000.0001.0000:
Представим картину, коммутаторы только включились и теперь начинают строить топологию без петель. Как только коммутаторы загрузились, они приступают к рассылке BPDU, где информируют всех, что они являются корнем дерева. В BPDU в качестве Root Bridge ID, коммутаторы указывают собственный Bridge ID. Например, Switch1 отправляет BPDU коммутатору Switch3, а Switch3 отправляет к Switch1. BPDU от Switch1 к Switch3:
BPDU от Switch3 к Switch1:
Как видим из Root Identifier, оба коммутотара друг другу сообщают, что именно он является Root коммутатором.
Выбор корневого коммутатора
Пока топология STP не построена, обычный трафик не передается из-за специальных состояний портов, о которых будет сказано ниже. Итак, Switch3 получается BPDU от Switch1 и изучает данное сообщение. Switch3 смотрит в поле Root Bridge ID и видит, что там указан другой Root Bridge ID, чем в том сообщении, которое отправил сам Switch3. Он сравнивает Root Bridge ID в данном сообщении со своим Root Bridge ID и видит, что хоть Priority одинаковые, но MAC-адрес данного коммутатора (Switch1) лучше (меньше), чем у него. Поэтому Switch3 принимает Root Bridge ID от Switch1 и перестает отправлять свои BPDU, а только слушает BPDU от Switch1. Порт, на котором был получен наилучший BPDU становится Root Port-ом. Switch1 также получив BPDU от Switch3, проводит сравнение, но в этом случае поведение Switch1 не меняется, так как полученный BPDU содержит худший Root Bridge ID, чем у Switch1. Таким образом, между Switch1 и Switch3 был определен корневой коммутатор. По аналогичной схеме происходит выбор корневого коммутатора между Switch1 и Switch2. Порты Gi0/0 на Switch2 и Switch3 становятся Root Port — порт, который ведет к корневому коммутатору. Через данный порт коммутаторы Switch2 и Switch3 принимают BPDU от Root Bridge. Теперь разберемся, что произойдет с каналом между Switch2 и Switch3.
Блокирование избыточных каналов
Как мы видим из топологии, канал между Switch2 и Switch3 должен быть заблокирован для предотвращения образования петель. Как STP справляется с этим?
После того, как выбран Root Bridge, Switch2 и Switch3 перестают отправлять BPDU через Root Port-ы, но BPDU, полученные от Root Bridge, они пересылают через все свои остальные активные порты, при этом изменив в данных BPDU только следующие поля:
А Switch3 от Switch2 получает такой BPDU:
После обмена такими BPDU, Switch2 и Switch3 понимают, что топология избыточна. Почему коммутаторы понимают, что топология избыточна? И Switch2, и Switch3 в своих BPDU сообщают об одном и том же Root Bridge. Это означает, что к Root Bridge, относительно Switch3, существует два пути — через Switch1 и Switch2, а это и есть та самая избыточность против которой мы боремся. Также и для Switch2 два пути — через Switch1 и Switch3. Чтоб избавиться от этой избыточности
необходимо заблокировать канал между Switch3 и Switch2. Как это происходит?
Выбор на каком коммутатоторе заблокировать порт происходит по следующей схеме:
Здесь как оказалось заблокируется порт Gi 0/1 на коммутаторе Sw2. В данном голосовании определяющим становится Root Path Cost. Вернемся к нашей топологии. Так как путь до Root Bridge одинаковый, то в данном выборе побеждает Switch2, так как его priority равны, сравниваются Bridge ID. У Switch2 — 50:00:00:02:00:00, у Switch3 — 50:00:00:03:00:00. У Switch2 MAC-адрес лушче (меньше). После того, как выбор сделан, Switch3 перестает переслать какие-либо пакеты через данный порт — Gi1/0, в том числе и BPDU, а только слушает BPDU от Switch2. Данное состояние порта в STP называется Blocking(BLK). Порт Gi1/0 на Switch2 работает в штатном режиме и пересылает различные пакеты при необходимости, но Switch3 их сразу отбрасывает, слушая только BPDU. Таким образом, на данном примере мы построили топологию без избыточных каналов. Единственный избыточный канал между Switch2 и Switch3 был заблокирован при помощи перевода порта Gi1/0 на Switch3 в специальное состояние блокирования — BLK. Теперь более детально разберем механизмы STP.
Состояния портов
Мы говорили выше, что, например, порт Gi1/0 на Switch3 переходит в специальное состояние блокирования — Blocking. В STP существуют следующие состояния портов:
Blocking — блокирование. В данном состоянии через порт не передаются никакие фреймы. Используются для избежания избыточности топологии.
Listening — прослушивание. Как мы говорили выше, что до того, пока еще не выбран корневой коммутатор, порты находятся в специальном состоянии, где передаются только BPDU, фреймы с данными не передаются и не принимаются в этом случае. Состояние Listening не переходит в следующее даже, если Root Bridge определен. Данное состояние порта длится в течении Forward delay timer, который, по умолчанию, равен 15. Почему всегда надо ждать 15 секунд? Это вызвано осторожностью протокола STP, чтоб случайно не был выбран некорректный Root Bridge. По истечению данного периода, порт переходит в следующее состояние — Learning.
Learning — обучение. В данном состояние порт слушает и отправляет BPDU, но информацию с данными не отправляет. Отличие данного состояния от Listening в том, что фреймы с данными, который приходят на порт изучаются и информация о MAC-адресах заносится в таблицу MAC-адресов коммутатора. Переход в следующее состояние также занимает Forward delay timer.
Forwarding — пересылка. Это обычное состояние порта, в котором отправляются и пакеты BPDU, и фреймы с обычными данными. Таким образом, если мы пройдемся по схеме, когда коммутаторы только загрузились, то получается следующая схема:
Роли портов
Помимо состояний портов, также в STP нужны определить портам их роли. Это делается для того, чтоб на каком порте должен ожидаться BPDU от корневого коммутатора, а через какие порты передавать копии BPDU, полученных от корневого коммутатора. Роли портов следующие:
Root Port — корневой порт коммутатора. При выборе корневого коммутатора также и определяется корневой порт. Это порт через который подключен корневой коммутатор. Например, в нашей топологии порты Gi0/0 на Switch2 и Switch3 являются корневыми портами. Через данные порты Switch2 и Switch3 не отправляют BPDU, а только слушают их от Root Bridge. Возникает вопрос — как выбирается корневой порт? Почему не выбран порт Gi1/0? Через него ведь тоже можно иметь связь с коммутатором? Для определения корневого порта в STP используется метрика, которая указывает в поле BPDU — Root Path Cost (стоимость маршрута до корневого свича). Данная стоимость определяется по скорости канала.
Switch1 в своих BPDU в поле Root Path Cost ставит 0, так как сам является Root Bridge. А вот, когда Switch2, когда отправляет BPDU к Switch3, то изменяет данное поле. Он ставит Root Path Cost равным стоимости канала между собой и Switch1. На картинке BPDU от Switch2 и Switch3 можно увидеть, что в данном поле Root Path Cost равен 4, так как канал между Switch1 и Switch2 равен 1 Gbps. Если количество коммутаторов будет больше, то каждый следующий коммутатор будет суммировать стоимость Root Path Cost. Таблица Root Path Cost.
Designated Port — назначенный порт сегмента. Для каждого сегмента сети должен быть порт, который отвечает за подключение данного сегмента к сети. Условно говоря, под сегментом сети может подразумеваться кабель, который осуществляет подключение данного сегмента. Например, порты Gi0/2 на Switch1, Switch3 подключают отдельные сегменты сети, к которым ведет только данный кабель. Также, например, порты на Root Bridge не могут быть заблокированы и все являются назначенными портами сегмента. После данного пояснения можно дать более строгое определения для назначенных портов:
Designated Port (назначенный) — некорневой порт моста между сегментами сети, принимающий трафик из соответствующего сегмента. В каждом сегменте сети может быть только один назначенный порт. У корневого коммутатора все порты — назначенные.
Также важно заметить, что порт Gi1/0 на Switch2 также является назначенным, несмотря на то, что данный канал связи заблокированным на Switch3. Условно говоря, Switch2 не имеет информации о том, что на другом конце порт заблокирован.
Nondesignated Port — неназначенный порт сегмента. Non-designated Port (неназначенный) — порт, не являющийся корневым, или назначенным. Передача фреймов данных через такой порт запрещена. В нашем примере, порт Gi1/0 является неназначенным.
Disabled Port — порт который находится в выключенном состоянии.
Таймеры и сходимость протокола STP
После того, как STP завершил построение топологии без петель, остается вопрос — Как определять изменения в сети и как реагировать на них? Сообщения BPDU при помощи которых работает STP, рассылаются Root Bridge каждые 2 секунды, по умолчанию. Данный таймер называется Hello Timer. Остальные коммутаторы получив через свой root port данное сообщение пересылают его дальше через все назначенные порты. Выше сказано более подробно какие изменения происходят с BPDU при пересылки его коммутаторов. Если в течении времени, определенным таймером Max Age (по умолчанию — 20 секунд), коммутатор не получил ни одного BPDU от корневого коммутатора, то данное событие трактуется как потеря связи с Root Bridge. Для того, чтобы более корректно описать сходимость протокола необходимо изменить нашу топологию и поставить между коммутаторами хабы. Мы добавили хабы, чтоб при выходе из строя одного из коммутаторов или выхода из строя линка, другие коммутаторы не определяли это по падению линка, а использовали таймеры:
Перед тем, как начать также важно рассказать подробнее о другом типе сообщения STP — TCN. TCN рассылается коммутаторами в случае изменения топологии — как только на каком-либо коммутаторе изменилась топология, например, изменилось состояние интерфейса. TCN отправляется коммутатором только через Root Port. Как только корневой коммутатор получит TCN, он сразу меняет параметр времени хранения MAC-адресов в таблице с 300 секунд до 15 (для чего это делается будет сказано ниже) и в следующем BPDU, Root Switch проставляет флаг — TCA ( Topology Change Acknledgement ), который отправляется коммутатору отправившем TCN для уведовления о том, что TCN был получен. Как только TCN достигает Root Bridge, то он рассылает специальный BPDU, который содержится TCN флаг по всем остальным интерфейсам к другим коммутаторам. На картинке показана структура TCN:
TCN был включен в STP, чтоб некорневые коммутаторы могли уведовлять об изменении в сети. Обычными BPDU они этого делать не могут, так как некорневые коммутаторы не отправляют BPDU. Как можно заметить структура TCN не несет в себе никакой информации о том, что именно и где изменилось, а просто сообщает что где-то что-то изменилось. Теперь перейдем к рассмотрению вопроса о сходимости STP.
Посмотрим, что произойдет если мы отключим интерфейс Gi0/1 на Switch1 и посмотрим при помощи каких механизмов перестроится дерево STP. Switch2 перестанет получать BPDU от Switch1 и не будет получать BPDU от Switch3, так как на Switch3 данный порт заблокирован. У Switch2 уйдет 20 секунд ( Max Age Timer ), чтоб понять потерю связи с Root Bridge. До этого времени, Gi0/0 на Switch2 будет находится в состоянии Forwarding с ролью Root Port. Как только истечет Max Age Timer и Switch2 поймет потерю связи, он будет заново строить дерево STP и как это свойственно STP начнет считать себя Root Bridge. Он отправит новый BPDU, где укажет самого себя в качестве Root Bridge через все активные порты, в том числе и на Switch3. Но таймер Max Age, истекший на Switch2 также истек и на Switch3 для интерфейса Gi1/0. Данный порт уже 20 секунд не получал BPDU и данный порт перейдет в состояние LISTENING и отправит BPDU c указанием в качестве Root Bridge — Switch1. Как только Switch2 примет данный BPDU, он перестанет считать себя Root Bridge и выберет в качестве Root Port — интерфейс Gi1/0. В этот момент Switch2 также отправит TCN через Gi1/0, так как это новый Root Port. Это приведет к тому, что время хранения MAC-адресов на коммутаторах уменьшится с 300 секунд до 15. Но на этом работоспособность сети не восстановится полностью, необходимо подождать пока порт Gi1/0 на Switch3 пройдет состояние Listening, а затем Learning. Это займет время равное двум периодам Forward delay timer — 15 + 15 = 30 секунд. Что мы получаем — при потери связи Switch2 ждет пока истечет таймер Max Age = 20 секунд, заново выберает Root Bridge через другой интерфейс и ждет еще 30 секунд пока ранее заблокированный порт перейдет в состояние Forwarding. Суммарно получаем, что связь между VPC5 и VPC6 прервется на 50 секунд. Как было сказано несколькими предложениями выше при изменение Root Port с Gi0/0 на Gi1/0 на Switch2 был отправлен TCN. Если бы этого не произошло, то все MAC-адреса, изученные через порт Gi 0/0, оставались бы привязаны к Gi0/0. Например, MAC-адрес VPC5 и VPC7 несмотря на то, что STP завершит сходимость через 50 секунд, связь между VPC6 и VPC5, VPC7 не была бы восстановлена, так как все пакеты предназначенные VPC5, VPC7 отправлялись через Gi0/0. Надо было бы ждать не 50 секунд, а 300 секунд пока таблица MAC-адресов перестроится. При помощи TCN, время хранение изменилось с 300 секунд до 15 и пока интерфейс Gi1/0 на Switch3 проходил состояния Listening, а затем Learning и данные о MAC-адресах обновятся.
Также интересен вопрос, что произойдет, если мы заново включим интерфейс Gi0/1 на Switch1? При включение интерфейса Gi0/1, он, как и подобает, перейдет в состояние Listening и начнет рассылать BPDU. Как только Switch2 получит BPDU на порту Gi0/0, то сразу перевыберет свой Root Port, так как тут Cost будет наименьшем и начнет пересылать траффик через интерфейс Gi0/0, но нам необходимо подождать пока интерфейс Gi0/1 пройдет состояния Listening, Learning до Forwarding. И задержка будет уже не 50 секунд, а 30.
В протоколе STP также продуманы различные технологии для оптимизации и безопасности работы протокола STP. Более подробно в данной статье рассматривать их не буду, материалы по поводу них можно найти в избытке на различных сайтах.