Каким способом можно исправить сбой протокола связующего дерева

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Траблшутинг STP (Spanning tree protocol)

Часть.2 4 кейса по проблемам с STP

Предыдущая статья этого цикла:

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

Следующая статья этого цикла:

Case #1

На рисунке представлена топология, состоящая из трех коммутаторов, и между коммутаторами у нас есть два канала связи для резервирования. Коммутатор А был выбран в качестве корневого моста для VLAN 1. Когда вы имеете дело со связующим деревом, лучше всего нарисовать небольшую схему сети и записать роли интерфейса для каждого коммутатора (назначенного, не назначенного/альтернативного или заблокированного). Обратите внимание, что одним из каналов связи между коммутатором A и коммутатором C является интерфейс Ethernet (10 Мбит). Все остальные каналы — это FastEthernet.

Мы используем команду show spanning-tree для проверки ролей интерфейса для коммутатора A и коммутатора C. Вы видите, коммутатор C выбрал свой интерфейс Ethernet 0/13 как корневой порт, а интерфейс FastEthernet 0/14 выбран в качестве альтернативного порта. Это не очень хорошая идея. Это означает, что мы будем отправлять весь трафик вниз по линии 10 Мбит, в то время как 100 Мбит не используется вообще. Когда коммутатор должен выбрать корневой порт он выберет его следующим образом:

1. Выбирается интерфейс, который имеет самую низкую стоимость для корневого моста.
3. Если стоимость равная, выбирается наименьший номер интерфейса. Обычно стоимость интерфейса Ethernet выше, чем Fast Ethernet, поэтому он должен выбрать интерфейс FastEthernet.

Почему коммутатор выбрал интерфейс Ethernet 0/13?

Мы видим, что интерфейс Ethernet 0/13 и FastEthernet0/14 имеют одинаковую стоимость. Затем коммутатор С выберет самый низкий номер интерфейса, который является interface Ethernet 0/13.

После проверки конфигурации интерфейса, видно, что кто-то изменил стоимость интерфейса на 19 (по умолчанию для интерфейсов FastEthernet).

Уберем настройки команды cost.

После того, как мы убрали настройки команды cost, видно, что состояние порта изменилось. FastEthernet 0/14 теперь является корневым портом, а стоимость интерфейса Ethernet 0/13 равна 100 (это значение по умолчанию для интерфейсов Ethernet). Задача решена!

Извлеченный урок: убедитесь, что интерфейс, которым вы хотите сделать в качестве корневого порта, имеет наименьшую стоимость пути.

Case #2

Итак, новый сценарий. Все интерфейсы равны (FastEthernet). Коммутатор A является корневым мостом для VLAN 10, и после проверки ролей интерфейса мы находим следующее:

Хм, интересно. Коммутатор A является корневым мостом, а FastEthernet 0/17 был выбран в качестве резервного порта. Это то, что вы видите каждый день. Коммутатор B выбрал корневой порт, а все остальные интерфейсы являются альтернативными портами. Мы ничего не видим на коммутаторе С.

Мы видим, что Коммутатор A и Коммутатор B используют связующее дерево для VLAN 10. Коммутатор C, однако, не использует связующее дерево для VLAN 10. В чем может быть проблема?

Конечно, неплохо проверить, работают ли интерфейсы на коммутаторе C или нет (но, конечно, это то, что вы уже изучили и сделали в первой статье).

Интерфейсы выглядят хорошо. VLAN 10 активна на всех интерфейсах коммутатора C. Это означает, что остовное дерево должно быть активным для VLAN 10.

Давайте еще раз посмотрим на это сообщение. Это говорит о том, что остовное дерево для VLAN 10 не существует. Есть две причины, по которым можно увидеть это сообщение:

• Для VLAN 10 нет активных интерфейсов.
• Spanning-дерево было отключено для VLAN 10.

Мы подтвердили, что VLAN 10 активна на всех интерфейсах коммутатора C, поэтому, может быть, связующее дерево было отключено глобально? SwitchC(config)#spanning-tree vlan 10

Вот так выглядит лучше! Теперь связующее дерево включено для VLAN 10 и работает . проблема решена! Эта проблема может показаться немного странной, но она появляется ее время от времени в реальном мире. Сценарий, который мы рассмотрели раньше, — это событие из реальной жизни, где клиент, которому поставщик беспроводной связи отключил остовное дерево для интерфейсов, которые подключаются к точке беспроводного доступа. Ниже то, что клиент ввел на коммутаторе:

В интерфейсе они набрали no spanning-tree vlan 10 , но как вы видите, что они оказались в режиме глобальной конфигурации. Нет команды для отключения остовного дерева на интерфейсе, подобного этой, поэтому коммутатор думает, что вы ввели глобальную команду для отключения остовного дерева. Коммутатор принимает команду отключения остовного дерева для VLAN 10 и возвращает вас в режим глобальной конфигурации. проблема решена!

Извлеченный урок: проверьте, включено ли связующее дерево.

Case #3

Давайте продолжим по другому сценарию! Та же топология. наш клиент жалуется на плохую работу. Начнем с проверки ролей интерфейсов:

Посмотрите на картинку выше. Видите ли вы, что интерфейс FastEthernet 0/16 на коммутаторе B и коммутаторе C обозначены? На Коммутаторе A все интерфейсы обозначены. Как вы думаете, что произойдет, когда один из наших коммутаторов переадресует трансляцию или должен передать кадр? Правильно! У нас будет цикл . Обычно в этой топологии интерфейсы FastEthernet 0/16 и 0/17 на коммутаторе C должны быть альтернативными портами, поскольку коммутатор C имеет худший ID моста. Так как они оба обозначены, мы предполагаем, что Коммутатор C не получает BPDU на этих интерфейсах.

Так почему же остовное дерево провалилось здесь? Здесь важно помнить, что связующему дереву требуются блоки BPDU, передаваемые между коммутаторами для создания топологии без петель. BPDU могут быть отфильтрованы из-за MAC access-lists, VLAN access-maps или из-за spanning-tree toolkit?

Ни на одном из коммутаторов нет VLAN access maps.

Нет списков доступа.

Нет port security. как насчет команд, связанных с остовным деревом?

Вот что-то есть!Фильтр BPDU был включен на интерфейсах FastEthernet 0/16 и 0/17 коммутатора B. Из-за этого коммутатор C не получает BPDU от коммутатора B.

Удалим настройки фильтра BPDU.

Теперь вы видите, что FastEthernet 0/16 и 0/17 являются альтернативными портами и блокируют трафик. Наша топология теперь без петель. проблема решена!

Извлеченный урок: убедитесь, что блоки BPDU не заблокированы и не отфильтрованы между коммутаторами.

Case #4

Новая топология. Коммутатор A был выбран в качестве корневого моста для VLAN 10. Все интерфейсы являются FastEthernet каналами.

После использования команды show spanning-tree vlan 10 вот, что мы видим. Все интерфейсы одинаковы, но по какой-то причине коммутатор B решил выбрать FastEthernet 0/16 в качестве корневого порта. Разве вы не согласны с тем, что FastEthernet 0/13 должен быть корневым портом? Стоимость доступа к корневому мосту ниже, чем у FastEthernet 0/16.

Используем команду show spanning-tree interface , чтобы проверить информацию о spanning-tree для каждого интерфейса. Как вы можете видеть, существует только связующее дерево для VLAN 1, активное на интерфейсе FastEthernet 0/13 и 0/14.

Есть несколько вещей, которые мы могли бы проверить, чтобы увидеть, что происходит:

Во-первых, всегда полезно проверить, активно ли связующее дерево для определенной VLAN. Можно отключить spanning-tree с помощью команды no spanning-tree vlan X. В этом сценарии связующее дерево активно для VLAN 10, потому что мы можем видеть на FastEthernet 0/16 и 0/17.

Мы знаем, что остовное дерево активно глобально для VLAN 10, но это не значит, что оно активно на всех интерфейсах. Мы можем использовать команду show interfaces switchport, чтобы проверить, работает ли VLAN 10 на интерфейсе FastEthernet 0/13 и 0/14. Это отобразит нам некоторую интересную информацию. Вы видите, что эти интерфейсы оказались в режиме доступа, и они находятся в VLAN 1.

Давайте изменим режим интерфейсов на магистральный, чтобы трафик VLAN 10 мог проходить через эти интерфейсы.

Ну вот, теперь все намного лучше выглядит. Трафик VLAN 10 теперь передается по интерфейсу FastEthernet 0/13 и 0/14, и вы видите, что интерфейс FastEthernet 0/13 теперь выбран в качестве корневого порта. Задача решена!

Извлеченный урок: убедитесь, что VLAN активна на интерфейсе, прежде чем рассматривать проблемы связующего дерева.

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

Источник

Протокол покрывающего дерева (STP)

STP, что означает протокол связующего дерева, — это протокол сетевого уровня, который помогает в построении логической топологии без петель для сетей Ethernet. Многие улучшенные версии STP продолжали поступать на рынок со временем, внося новые улучшения в этот протокол:

• STP / 802.1D (оригинальный STP)
• PVST + (улучшения Cisco для STP, добавление функции для каждой VLAN)
• RSTP / 802.1W (улучшенный STP с гораздо более быстрой конвергенцией)
• Быстрый PVST + (улучшение RSTP в Cisco, добавление для каждой функции VLAN)

Вы можете видеть, что Cisco сделала много улучшений в этой области. Давайте вернемся к основам и рассмотрим причину, почему STP был необходим в первую очередь.

Прежде чем мы рассмотрим потребность в STP, давайте кратко рассмотрим, как работает уровень 2, когда ему нужно узнать адрес конкретного хоста.

Когда коммутатор получает пакет, но у него нет MAC-адреса узла назначения в его таблице, он транслирует сообщения на все узлы, кроме тех, от которых он получает. Если вы хотите узнать больше об этом, пожалуйста, обратитесь к этой статье на ARP.

Сценарий 1: широковещательный шторм

Давайте посмотрим на сценарий ниже:

Допустим, в сети есть три коммутатора, как показано выше. Все переключатели связаны друг с другом. Коммутатор B отправляет широковещательную рассылку, а коммутатор A и коммутатор C принимают ее. Они не находят адрес и повторно транслируют сообщение.

Коммутатор B снова получает ретранслируемое сообщение от коммутатора A и коммутатора C. Думая об этой трансляции как о новой трансляции, коммутатор B снова транслирует те же сообщения, которые уже транслировались ранее. Таким образом, широковещательный шторм имеет место. Это продолжается до тех пор, пока порты не выйдут из строя или не произойдет сбой коммутатора.

Сценарий 2: дубликаты пакетов

Рассмотрим ту же архитектуру сети, которая приведена в сценарии выше. Здесь есть небольшой поворот. На этот раз коммутатор C подключен к хосту назначения, который искал коммутатор B. Что теперь?

Переключатель B будет транслироваться снова. Трансляция также достигает коммутатора C и коммутатора A. Коммутатор C просматривает пакет и доставляет пакет на хост назначения.

Однако на другой параллельной стороне коммутатор A также проверил свою таблицу и не смог найти хост назначения. Таким образом, он также транслировал сообщение, и коммутатор C снова получил тот же пакет. Таким образом, он просматривает пакет и снова доставляет его на хост назначения.

В чем здесь проблема? Можете ли вы угадать, не читая дальше?

Самая большая проблема здесь — двойная доставка и потеря пропускной способности.

Теперь давайте выясним решение для сценария 2. Одним из лучших и самых простых решений было бы отключить коммутатор B от коммутатора C, чтобы не было дублирования пакетов. Потому что, в любом случае, коммутатор A будет транслировать пакет на коммутатор C, если хост назначения не найден в списке коммутатора A. Теперь это выглядит примерно так:

Если вы снова посмотрите на определение, теперь вы узнаете, почему STP был изобретен в первую очередь.

Хотя мы нашли решение, мы, тем не менее, не уверены, что блокировка соединения между B и C была более выгодной, или блокирование того же между коммутатором B и A. Давайте рассмотрим все это подробнее.

Какой порт заблокировать в STP?

STP выполняет ряд простых шагов, которые помогают STP решать многие проблемы, в том числе блокировать порт. Но, перед этим, вот некоторые термины, которые могут быть вам полезны:

Корневой мост

Как и «Корень» в древовидной структуре, Корневой мост является основным коммутатором или мостом на графике, где разные узлы представляют все другие мосты. Корневой мост управляет топологией связующего дерева.

Назначенный мост

Назначенный мост — это коммутатор, ближайший к корневому мосту, через который кадры будут перенаправлены на корневой мост.

Альтернативный мост

Это альтернативный путь к корневому коммутатору, но он отличается от пути к корневому мосту.

Резервный мост

Это резервный путь к сегменту, хотя будет другой существующий путь.

Порты, которые отключены.

Ниже приведены различные состояния, в которых порт коммутатора может находиться в любой данный момент времени:

Порт экспедирования

Порт, который полноценно работает.

Порт обучения

Порт, который не пересылает кадры, но изучает MAC-адреса.

Порт прослушивания

Порт, который не пересылает кадры и не изучает MAC-адреса.

Отбрасывание порта

Порт, который не передает никаких данных.

Давайте посмотрим, как работает STP, и решим, какой коммутатор, мост и порт должны находиться в каком состоянии:

• На первом этапе выбирается корневой мост (способ выбора корневого моста был рассмотрен далее в этой статье).
• Порты в корневом мосту переводятся в состояние пересылки.
• Порты в назначенных мостах, соединяющих корневой мост, называются корневыми портами.
• Оставшиеся ссылки на назначенном мосту выбирают назначенные порты.
• Остальные порты переведены в состояние блокировки.

Вот очень красивый пример из Википедии.

RP: корневой порт
DP: назначенный порт
BP: заблокированный порт

В целом весь процесс может выглядеть проще, но алгоритм работы за сценой сложен. Чем больше сеть, тем больше времени требуется алгоритму, чтобы расставить все по местам.

Операция протокола связующего дерева

Происходит следующий набор операций.

Определение корневого моста

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

Чтобы подтвердить утверждение, все коммутаторы должны транслировать свой идентификатор моста (BID), используя BPDU (блоки данных протокола моста). Общий идентификатор моста составляет 8 байтов, из которых 2 байта зарезервированы для приоритета моста, а остальные 6 байтов зарезервированы для MAC-адреса.

Идентификатор моста представляет собой комбинацию приоритета моста и MAC-адреса. За кулисами BID представляет собой сцепленную версию приоритета моста и MAC-адреса коммутатора / моста. По умолчанию каждый мост будет иметь идентификатор моста 32768, а каждый идентификатор моста будет кратен 4096.

Как определяется корневой мост?

После передачи широковещательного сообщения каждому мосту мост с минимальным значением BID становится корневым мостом. Если в обоих случаях приоритет моста одинаков, победителем будет самый низкий Mac-адрес.

Пример:

Допустим, есть связь между двумя мостами с BID:

Мост A: 32768.df56.6765.7876 и,
Мост B: 32768.df56.6765.7875

Теперь у вас есть вопрос — какой мост станет здесь корневым мостом? Если вы догадались, что это Мост B, значит, вы были правы.

Давайте посмотрим, как эти отдельные коммутаторы реагируют на BPDU:

В тот момент, когда все коммутаторы включены, все коммутаторы, как упоминалось ранее, объявляют, что они являются корневым мостом, отправляя свой идентификатор моста в пакете приветствия.

Переключатель 1:

Когда коммутатор 1 получает приветственные BPDU от коммутатора 2 и коммутатора 3, он сравнивает значения идентификатора моста. В этой ситуации у коммутатора 1 самый низкий BID. Таким образом, коммутатор 1 отбрасывает пакеты приветствия, полученные от остальных коммутаторов, и продолжает объявлять себя корневым мостом.

Переключатель 2:

Здесь коммутатор 2 получает приветственные BPDU от обоих коммутаторов, то есть от коммутатора 1 и коммутатора 3. Давайте посмотрим, как коммутатор 2 реагирует на оба BPDU.

Когда Коммутатор 2 получает пакет от Коммутатора 1, он сравнивает значения BID и, безусловно, приветственный пакет BPDU от Коммутатора 1 заменяет его BID. Таким образом, коммутатор 2 изменяет свой BID на коммутатор 1. Когда он также получает BPDU от коммутатора 3, он будет сравнивать значения и будет продолжать отбрасывать BPDU из коммутатора 3.

Переключатель 3:

Допустим, коммутатор 3 сначала получает BPDU от коммутатора 2. Таким образом, он меняет свой BID на тот, что у коммутатора 2. Но когда он дополнительно получает BPDU от коммутатора 1, он снова меняет его на коммутатор 1.

В этот момент все коммутаторы получили BPDU друг друга и согласились с тем, что коммутатор 1 имеет самое низкое значение BID и, следовательно, является подходящим кандидатом на роль корневого моста сети.

После определения корневого моста коммутатор 2 и коммутатор 3 начинают организовывать свои соответствующие связи в корневые порты и назначенные порты, как обсуждалось в начале статьи.

Но выбор корневого моста — это не конец игры. Это только начало. И игра следует за: —

Определение маршрута с наименьшей стоимостью до корневого моста

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

В теории графов остовное дерево является подмножеством графа. Остовное дерево позволяет покрыть все вершины графа с минимально возможным числом ребер. Следовательно, остовное дерево не имеет петли, и, кроме того, оно также не может быть отключено.

Протокол Spanning Tree использует тот факт, что, как и Spanning Tree из теории графов, этот сетевой протокол может вычислять путь с наименьшей стоимостью от любого узла до корневого моста.

Таким образом, после определения корневого моста каждый узел начинает определять наименьшую стоимость корневого моста, чтобы оптимизировать всю сеть.

В качестве первого шага Root Bridge отправляет поток BPDU всем остальным коммутаторам. Корневая стоимость определяется путем суммирования затрат сегментов на пути, по которому он прошел пакет BPDU для прохождения от корневого моста к узлу.

Стоимость сегмента также зависит от скорости соединения конкретного сегмента. Вот диаграмма того же самого.

Пропускная способность	Затраты
10 Mbit	100
100 Mbit	19
1000 Mbit	4

Иногда эти затраты на соединение возникают в захватывающих ситуациях, связанных с наименьшей стоимостью пути к корневому мосту. Посмотрите на картинку ниже: —

Можете ли вы угадать корневой порт для коммутатора 3 на рисунке выше?

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

Корневой мост -> Переключатель 2 -> Переключатель 4 -> Переключатель 3

Вы можете догадаться, почему? В соответствии с таблицей выше, вот расходы.

Переключатель 3 на Root Bridge напрямую равен 100 из-за его канала 10 Мбит / с. Но если мы вычислим путь, как сказано выше, он будет (19 + 19 +4 = 42).

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

Далее все ссылки, подключенные напротив корневого порта, помечаются как назначенный порт. Также определяются заблокированные порты. Однажды все помечено и исправлено; сеть будет иметь полностью оптимизированную версию протокола связующего дерева.

Там могут быть другие условия. В случае большой сети в стоимости ссылки будет указана связь. В этом случае стоимость сети рассчитывается как часть Advanced STP. Advanced STP также говорит о том, что происходит в случае сбоя соединения.

Источник