Причина создания СТП Причиной создания протокола STP стало возникновение петель на коммутаторах.
Что такое петля? Определение цикла следующее: Мостовая петля, Коммутационная петля — состояние в сети, при котором кадры бесконечно пересылаются между коммутаторами, подключенными к одному и тому же сегменту сети.
Из определения становится понятно, что возникновение петель создает большие проблемы – оно приводит к перегрузке коммутаторов и неработоспособности данного сегмента сети.
Как возникает петля? На рисунке ниже показана топология, в которой возникнет петля при отсутствии каких-либо защитных механизмов:
Цикл возникает при следующих условиях: 1. Любой из хостов отправляет широковещательный кадр:
- Например, VPC5 отправляет пакет с широковещательным адресом назначения.
- Коммутатор1, получив этот пакет, должен отправить его через все порты, кроме порта, с которого этот пакет пришел.
Пакет будет отправлен через порты Gi0/0, Gi1/0.
- Коммутаторы Switch2, Switch3, приняв этот пакет, также должны будут его отправить.
Таким образом Switch2, получив пакет от Switch1, отправит его Switch3, а Switch3 отправит его Switch2.
- Далее Switch2 получает пакет от Switch3 и отправляет его Switch1, а Switch3 получает пакет от Switch2 и также отправляет его Switch1. Таким образом, мы приходим к шагу 1) и он будет продолжаться бесконечно.
Еще усугубляется все тем, что на шаге 4 у Switch1 уже будет два экземпляра кадра, так как он будет получать их как от Switch2, так и от Switch3.
Также образование петли приводит к тому, что таблица MAC-адресов на коммутаторах будет постоянно меняться и MAC-адрес отправителя VPC5 будет постоянно присваиваться то интерфейсу Gi0/0, то Gi1/0 или Gi0/2. (если в этот момент VPC5 отправляет другие пакеты).
Такой цикл приведет к некорректной работе сети и всех коммутаторов.
А отправка широковещательных пакетов хостам - обычное дело, например протокол ARP. 2. Также может образоваться цикл без отправки широковещательного кадра.
- Например, VPC5 отправляет кадр с одноадресным MAC-адресом назначения.
- Возможно, MAC-адрес назначения отсутствует в таблице MAC-адресов коммутатора.
В этом случае коммутатор будет пересылать пакет через все порты, кроме порта, из которого он получил кадр.
И получаем ту же ситуацию, что и с широковещательным кадром.
- Ниже мы рассмотрим протокол STP на коммутаторах Cisco. Они используют STP отдельно для каждого vlan, протокол PVST+.
Влан у нас всего один, поэтому смысл не меняется.
Основы STP
Принцип работы этого протокола основан на том, что все резервные каналы между коммутаторами логически блокируются и трафик через них не передается.Для построения топологии без избыточных каналов строится дерево (математический граф).
Чтобы построить такое дерево, сначала необходимо определить корень дерева, из которого будет построен граф.
Поэтому первым шагом протокола STP является определение корневого коммутатора (Root Switch).
Чтобы определить корневой коммутатор, коммутаторы обмениваются сообщениями BPDU. В целом STP использует два типа сообщений: BPDU — содержит информацию о коммутаторах и TCN — уведомляет об изменениях топологии.
Давайте рассмотрим BPDU более подробно.
Подробнее о TCN мы поговорим ниже.
Когда на коммутаторах включен STP, коммутаторы начинают отправлять сообщения BPDU. Эти сообщения содержат следующую информацию:
Кадр BPDU имеет следующие поля:
- Идентификатор версии протокола STA (2 байта).
Коммутаторы должны поддерживать одну и ту же версию протокола STA.
- Версия протокола STP (1 байт)
- Тип BPDU (1 байт).
Существует 2 типа BPDU — уведомление о конфигурации и реконфигурации.
- Флаги (1 байт)
- Идентификатор корневого коммутатора (8 байт)
- Стоимость маршрута до корневого коммутатора (Root Path Cost)
- Идентификатор отправителя (идентификатор моста) (8 байт)
- Идентификатор порта, с которого был отправлен этот пакет (Port ID) (2 байта)
- Время жизни сообщения (2 байта).
Измеряется с шагом 0,5 с, используется для идентификации устаревших сообщений.
- Максимальное время жизни сообщения (2 байта).
Если время жизни кадра BPDU превышает максимальное, то этот кадр игнорируется коммутаторами.
- Интервал приветствия (2 байта), интервал отправки пакетов BPDU.
- Задержка изменения состояния (2 байта).
Минимальное время перехода в активное состояние
- Идентификатор отправителя (идентификатор моста)
- Идентификатор корневого моста
- Идентификатор порта, с которого был отправлен этот пакет (Идентификатор порта)
- Стоимость маршрута до корневого коммутатора (Root Path Cost)
Коммутатор с наименьшим приоритетом выбирается в качестве корневого коммутатора; если приоритеты равны, то сравниваются MAC-адреса (посимвольно, побеждает тот, у кого наименьшее значение).
Вот вывод информации Bridge ID от Switch1 из первого изображения.
Приоритет — 32769 (по умолчанию 32768 + Vlan Id), MAC-адреса — Адрес 5000.0001.0000:
Представим себе картину: свитчи только что включились и теперь начинают строить топологию без шлейфов.
После загрузки коммутаторы начинают рассылать BPDU, информируя всех о том, что они являются корнем дерева.
В BPDU коммутаторы указывают свой собственный идентификатор моста в качестве идентификатора корневого моста.
Например, Switch1 отправляет BPDU на Switch3, а Switch3 отправляет на Switch1. BPDU от Switch1 к Switch3:
BPDU от Switch3 к Switch1:
Как мы видим из корневого идентификатора, оба коммутатора сообщают друг другу, что это корневой коммутатор.
Выбор корневого коммутатора
Пока топология STP не построена, нормальный трафик не передается из-за особых состояний порта, о которых речь пойдет ниже.Итак, Switch3 получает BPDU от Switch1 и проверяет данное сообщение.
Switch3 смотрит на поле Root Bridge ID и видит, что там указан другой Root Bridge ID, чем в сообщении, которое отправил сам Switch3. Он сравнивает идентификатор корневого моста в этом сообщении со своим идентификатором корневого моста и видит, что хотя приоритет тот же, MAC-адрес этого коммутатора (Switch1) лучше (меньше), чем у него.
Таким образом, Switch3 принимает идентификатор корневого моста от Switch1 и прекращает отправку своих BPDU, а слушает только BPDU от Switch1. Порт, на котором был получен лучший BPDU, становится корневым портом.
Switch1, также получив BPDU от Switch3, производит сравнение, но в этом случае поведение Switch1 не меняется, так как полученный BPDU содержит худший Root Bridge ID, чем у Switch1. Таким образом, между Switch1 и Switch3 определен корневой коммутатор.
По аналогичной схеме корневой свитч выбирается между Switch1 и Switch2. Порты Gi0/0 на Switch2 и Switch3 становятся корневым портом — портом, ведущим к корневому коммутатору.
Через этот порт коммутаторы Switch2 и Switch3 получают BPDU от корневого моста.
Теперь разберемся, что будет с каналом между Switch2 и Switch3.
Блокировка лишних каналов
Как мы видим из топологии, канал между Switch2 и Switch3 должен быть заблокирован, чтобы предотвратить образование петель.Как STP с этим справляется? После выбора корневого моста Switch2 и Switch3 прекращают отправку BPDU через корневые порты, но пересылают BPDU, полученные от корневого моста, через все остальные свои активные порты, изменяя при этом только следующие поля в данных BPDU:
- Sender ID (Bridge ID) – заменен на ваш идентификатор.
- Идентификатор порта, с которого был отправлен этот пакет (Port ID) — меняется на идентификатор порта, с которого будет отправлен BPDU.
- Root Path Cost — рассчитывает стоимость маршрута относительно самого коммутатора.
А Switch3 от Switch2 получает следующий BPDU:
После обмена этими BPDU Switch2 и Switch3 понимают, что топология избыточна.
Почему коммутаторы понимают, что топология избыточна? И Switch2, и Switch3 сообщают об одном и том же корневом мосте в своих BPDU. Это значит, что к Root Bridge, относительно Switch3, есть два пути — через Switch1 и Switch2, и это та самая избыточность, с которой мы боремся.
Также для Switch2 есть два пути — через Switch1 и Switch3. Чтобы избавиться от этой избыточности необходимо заблокировать канал между Switch3 и Switch2. Как это произошло? Выбор на каком свитче заблокировать порт происходит по следующей схеме:
- Меньшая стоимость корневого пути.
- Меньший идентификатор моста.
- Меньший идентификатор порта.
Раньше я думал, что этот выбор аналогичен выбору Root-свитча и удивлялся, что, например, в такой топологии не будет блокироваться порт на свитче с худшим приоритетом:
Здесь, как выяснилось, заблокирован порт Gi 0/1 на коммутаторе Sw2. В этом голосовании стоимость корневого пути становится решающей.
Вернемся к нашей топологии.
Поскольку путь к Корневому мосту один и тот же, в этом выборе выигрывает Switch2, поскольку его приоритеты равны и идентификаторы мостов сравниваются.
Switch2 имеет 50:00:00:02:00:00, Switch3 имеет 50:00:00:03:00:00. Switch2 имеет лучший (меньший) MAC-адрес.
После того, как выбор сделан, Switch3 прекращает отправлять через этот порт — Gi1/0 любые пакеты, включая BPDU, а слушает только BPDU от Switch2. Это состояние порта в STP называется Блокировкой (BLK).
Порт Gi1/0 на Switch2 работает нормально и при необходимости пересылает различные пакеты, но Switch3 сразу их отбрасывает, слушая только BPDU. Таким образом, в этом примере мы построили топологию без резервных каналов.
Единственный резервный канал между Switch2 и Switch3 был заблокирован путем перевода порта Gi1/0 на Switch3 в специальное состояние блокировки — BLK. Теперь давайте рассмотрим механизмы STP более подробно.
Государства порта
Выше мы говорили, что, например, порт Gi1/0 на Switch3 переходит в особое состояние блокировки — Blocking. В STP существуют следующие состояния порта: Блокировка - блокировка.В этом состоянии через порт не передаются никакие кадры.
Используется во избежание избыточности топологии.
Прослушивание — слушаю.
Как мы говорили выше, пока не выбран корневой свитч, порты находятся в особом состоянии, где передаются только BPDU, кадры данных в этом случае не передаются и не принимаются.
Состояние прослушивания не переходит в следующее состояние, даже если определен корневой мост. Это состояние порта длится в течение времени таймера задержки пересылки, который по умолчанию равен 15. Почему вам всегда приходится ждать 15 секунд? Это связано с предостережением протокола STP о том, чтобы случайно не был выбран неправильный корневой мост. По истечении этого срока порт переходит в следующее состояние – Обучение.
Обучение - образование.
В этом состоянии порт прослушивает и отправляет BPDU, но не отправляет данные.
Отличие этого состояния от Listening заключается в том, что изучаются кадры с данными, поступающие в порт, и информация о MAC-адресах заносится в таблицу MAC-адресов коммутатора.
Переход в следующее состояние также использует таймер задержки пересылки.
Пересылка - переадресация.
Это нормальное состояние порта, отправляющего как пакеты BPDU, так и обычные кадры данных.
Таким образом, если пройтись по диаграмме, когда коммутаторы только загрузились, то получим следующую диаграмму:
- Коммутатор переводит все подключенные порты в состояние прослушивания и начинает отправлять BPDU, объявляя себя корневым коммутатором.
В течение этого периода времени коммутатор либо остается корневым коммутатором, если он не получает лучший BPDU, либо выбирает корневой коммутатор.
Это длится 15 секунд.
- Затем он переходит в состояние Learning и изучает MAC-адреса.
15 секунд.
- Определяет, какие порты перевести в состояние Forwarding, а какие в Blocking.
Роли порта
Помимо состояний портов, STP также необходимо определить роли портов.Это сделано для того, чтобы на каком порту следует ожидать BPDU от корневого свитча, и через какие порты должны передаваться копии BPDU, полученные от корневого свитча.
Роли портов следующие: Корневой порт — корневой порт коммутатора.
При выборе корневого коммутатора также определяется корневой порт. Это порт, через который подключен корневой коммутатор.
Например, в нашей топологии порты Gi0/0 на Switch2 и Switch3 являются корневыми портами.
Switch2 и Switch3 не отправляют BPDU через эти порты, а только прослушивают их с корневого моста.
Возникает вопрос - как выбирается корневой порт? Почему порт Gi1/0 не выбран? Через него тоже можно общаться со свитчем? Для определения корневого порта в STP используется метрика, которая указывает в поле BPDU — Root Path Cost (стоимость маршрута до корневого свитча).
Эта стоимость определяется скоростью канала.
Коммутатор 1 в своем BPDU устанавливает поле Root Path Cost в 0, поскольку он сам является корневым мостом.
Но когда Switch2 отправляет BPDU Switch3, он меняет это поле.
Он устанавливает стоимость корневого пути, равную стоимости пути между ним и Switch1. На картинке BPDU от Switch2 и Switch3 вы можете видеть, что в этом поле Root Path Cost равна 4, так как канал между Switch1 и Switch2 равен 1 Гбит/с.
Если количество переключателей больше, то при каждом последующем переключении будет суммироваться стоимость корневого пути.
Таблица стоимости корневого пути.
Назначенный порт — назначенный порт сегмента.
Для каждого сегмента сети должен быть порт, отвечающий за подключение этого сегмента к сети.
Условно говоря, сегмент сети может означать кабель, соединяющий этот сегмент. Например, порты Gi0/2 на Switch1, Switch3 соединяют отдельные сегменты сети, к которым ведет только этот кабель.
Кроме того, например, порты на корневом мосту не могут быть заблокированы и все они являются назначенными портами сегмента.
С этим уточнением можно дать более строгое определение назначенным портам: Назначенный порт — некорневой порт моста между сегментами сети, который получает трафик из соответствующего сегмента.
В каждом сегменте сети может быть только один назначенный порт. Корневой коммутатор имеет все назначенные порты.
Также важно отметить, что порт Gi1/0 на Switch2 также назначен, несмотря на то, что на Switch3 этот канал связи заблокирован.
Условно говоря, Switch2 не имеет информации о том, что порт заблокирован на другом конце.
Неназначенный порт — неназначенный порт сегмента.
Неназначенный порт — порт, не являющийся корневым или назначенным.
Передача кадров данных через этот порт запрещена.
В нашем примере порт Gi1/0 не назначен.
Отключенный порт — порт, находящийся в отключенном состоянии.
Таймеры и конвергенция STP
После того, как STP завершил построение топологии без петель, остается вопрос — как обнаружить изменения в сети и как на них реагировать? Сообщения BPDU, с которыми работает STP, по умолчанию отправляются корневым мостом каждые 2 секунды.Этот таймер называется Hello Timer. Остальные коммутаторы получают это сообщение через свой корневой порт и пересылают его дальше через все назначенные порты.
Выше подробнее сказано, какие изменения происходят с BPDU при его отправке на коммутаторы.
Если за время, определенное таймером Max Age (по умолчанию — 20 секунд), коммутатор не получил ни одного BPDU от корневого коммутатора, то это событие интерпретируется как потеря связи с Root Bridge. Чтобы более корректно описать конвергенцию протокола, необходимо изменить нашу топологию и разместить хабы между свитчами.
Мы добавили хабы, чтобы в случае сбоя одного из свитчей или сбоя линка другие свитчи не обнаруживали это по сбою линка, а использовали таймеры:
Прежде чем мы начнем, важно также поговорить подробнее о другом типе сообщений STP — TCN. TCN пересылается свитчами в случае изменения топологии — как только на каком-либо свитче изменилась топология, например, изменилось состояние интерфейса.
TCN отправляется коммутатором только через корневой порт. Как только корневой свитч получает TCN, он сразу меняет параметр времени хранения MAC-адреса в таблице с 300 секунд на 15 (для чего это делается, будет сказано ниже) и в следующем BPDU Root Switch ставит флаг - TCA (Подтверждение изменения топологии), которое отправляется коммутатору, отправившему TCN, для уведомления о том, что TCN получен.
Как только TCN достигает корневого моста, он отправляет специальный BPDU, содержащий флаг TCN, на все остальные интерфейсы других коммутаторов.
На рисунке представлена структура ТКС:
TCN был включен в STP, чтобы некорневые коммутаторы могли уведомлять об изменениях в сети.
Они не могут сделать это с обычными BPDU, поскольку некорневые коммутаторы не отправляют BPDU. Как видите, структура TCN не содержит никакой информации о том, что именно и где изменилось, а просто сообщает, что где-то что-то изменилось.
Теперь перейдем к рассмотрению вопроса о конвергенции СТП.
Давайте посмотрим, что произойдет, если мы отключим интерфейс Gi0/1 на Switch1, и посмотрим, по каким механизмам перестраивается STP-дерево.
Коммутатор2 прекратит получать BPDU от Коммутатора1 и не будет получать BPDU от Коммутатора3, поскольку этот порт заблокирован на Коммутаторе3. Switch2 потребуется 20 секунд (таймер максимального возраста), чтобы понять потерю соединения с корневым мостом.
До этого времени Gi0/0 на Switch2 будет находиться в состоянии Forwarding с ролью корневого порта.
Как только таймер максимального срока истечет и Switch2 осознает потерю соединения, он перестроит дерево STP и, как обычно, STP начнет считать себя корневым мостом.
Он отправит новый BPDU, где укажет себя как корневой мост через все активные порты, включая Switch3. Но срок действия таймера Max Age, истекшего на Switch2, также истек и на Switch3 для интерфейса Gi1/0. Этот порт не получал BPDU в течение 20 секунд, и этот порт перейдет в состояние ПРОСЛУШИВАНИЕ и отправит BPDU, указывающий Switch1 как корневой мост. Как только Switch2 получит этот BPDU, он больше не будет считать себя корневым мостом и выберет интерфейс Gi1/0 в качестве корневого порта.
На этом этапе Switch2 также отправит TCN через Gi1/0, поскольку это новый корневой порт. Это приведет к тому, что время хранения MAC-адресов на коммутаторах уменьшится с 300 секунд до 15. Но это не восстановит функциональность сети полностью; вам необходимо дождаться, пока порт Gi1/0 на Switch3 перейдет в состояние прослушивания, а затем обучения.
Это займет время, равное двум периодам таймера задержки пересылки — 15 + 15 = 30 секунд. Что мы получаем, так это то, что в случае потери соединения Switch2 ждет, пока истечет таймер Max Age = 20 секунд, повторно выбирает Root Bridge через другой интерфейс и ждет еще 30 секунд, пока ранее заблокированный порт не перейдет в состояние Forwarding. Итого получаем, что соединение между VPC5 и VPC6 будет прервано на 50 секунд. Как указано в нескольких предложениях выше, при изменении корневого порта с 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 проходил состояния «Прослушивание», а затем «Обучение», данные MAC-адреса обновлялись.
Еще один интересный вопрос: что произойдет, если мы снова включим интерфейс Gi0/1 на Switch1? Когда интерфейс Gi0/1 включен, он, как и ожидалось, перейдет в состояние прослушивания и начнет отправлять BPDU. Как только Switch2 получит BPDU на порт Gi0/0, он сразу же перевыберет свой Root Port, так как здесь Cost будет наименьшим и начнет пересылать трафик через интерфейс Gi0/0, но нам нужно дождаться, пока Интерфейс Gi0/1 передает состояния «Прослушивание», «Обучение» и «Пересылка».
И задержка будет уже не 50 секунд, а 30. Протокол STP также включает в себя различные технологии для оптимизации и безопасности работы протокола STP. Я не буду рассматривать их более подробно в этой статье; материалы о них в изобилии можно найти на различных сайтах.
Теги: #Сетевые технологии #коммутация #spanning-tree #stp цикл
-
Каждому 3D-Принтеру Нужны Направляющие
19 Oct, 24 -
История Сотрудника Google №13
19 Oct, 24 -
Встреча С Оперой Во Владивостоке
19 Oct, 24 -
Победители Премии Duke's Choice Awards 2013.
19 Oct, 24 -
Биткойн. Стоит Ли Этому Доверять?
19 Oct, 24