Коммутация LAN : Протокол STP

Изменения топологии протокола связующего дерева

28 июля 2008 - Перевод, выполненный профессиональным переводчиком
Другие версии: PDF-версия:pdf | Машинный перевод (28 июля 2013) | Английский (10 октября 2005) | Отзыв

Интерактивный документ: В данном документе содержится анализ конкретного устройства Cisco.


Содержание

Введение
Предварительные условия
     Требования
     Используемые компоненты
     Условные обозначения
Назначение механизма изменения топологии
Принципы функционирования
     Оповещение корневого моста
     Широковещание о событии в сети
Что делать при больших изменениях топологии сети?
     Лавинная адресация пакетов
     Проблема в среде мостового соединения ATM LANE
     Как избежать генерации TCN с помощью команды «portfast»
     Отслеживание источника TCN
Заключение
Связанные обсуждения сообщества поддержки Cisco
Дополнительная информация

Введение

Если ведется отслеживание операций Spanning Tree Protocol (STP), то увеличение значений счетчиков изменения топологии в журнале статистики может вызвать обеспокоенность персонала. Изменения топологии - обычное явление для STP. Однако большое число подобных изменений может повлиять на производительность сети. В данном документе объясняется, что целью топологии является:

  • Изменение механизма в отдельном связующем дереве сети VLAN (PVST) и средах применения PVST+.

  • Определение причины инициирования события изменения топологии сети.

  • Решение проблем, связанных с механизмом изменения топологии.

Предварительные условия

Требования

Для данного документа нет особых требований.

Используемые компоненты

Данный документ не имеет жесткой привязки к устройству или какой-либо версии ПО.

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

Условные обозначения

Дополнительные сведения о применяемых в документе обозначениях см. в разделе Условные обозначения, используемые в технической документации Cisco.

Назначение механизма изменения топологии

На основе изучения информации в кадрах мост создает таблицу, в которой устанавливается привязка порта к адресам MAC (управление доступом к среде) хост-машин, достижимых через данный порт. Эта таблица используется для пересылки кадров непосредственно в порт назначения. По этой причине лавинные передачи предотвращаются.

Время устаревания для этой таблицы по умолчанию - 300 секунд (пять минут). Запись о хосте исчезает из таблицы, созданной мостом, только после пятиминутного молчания хоста. Ниже приведен пример, в котором объясняется, почему может потребоваться более короткое время устаревания:

Предполагается, что в данной сети мост B1 блокирует соединение с мостом B4. A и B — станции с установленным соединением. Трафик, передаваемый из A в B, направляется в B1, B2, B3 и затем - в B4. В схеме показана таблица MAC-адресов, записанных четырьмя мостами, для данной ситуации:

17a.gif

Теперь допустим, что соединение между B2 и B3 не установлено. Связь между A и B будет прервана по крайне мере до тех пор, пока B1 не переведет свои порты в режим переадресации к B4 (максимальное время – 50 секунд при параметрах по умолчанию). Однако в случае посылки кадра станцией A станции B (а в B1 продолжает существовать точка входа, ведущая в B2), пакет отправляется в черную дыру. То же самое происходит, если станция B пытается связаться со станцией A. Связь теряется на 5 минут, пока не истечет время устаревания записей MAC-адресов для А и В.

17b.gif

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

В разделе "Принципы функционирования" объясняется, как это реализовано на практике. После оповещения каждый мост превращает время устаревания в задержку переадресации (forward_delay) (по умолчанию 15 секунд) на определенный период (max_age + forward_delay). Более целесообразно вместо отчистки таблицы сократить время устаревания, так как активные в этот момент хосты, эффективно передающие трафик, из таблицы не удаляются.

В данном примере мост B2 или B3 отправит сообщение об изменении топологии сети, как только определит, что соединение прервано. Получив это сообщение, все мосты сократят время устаревания до 15 секунд. Если в течение пятнадцати секунд B1 не получит ни одного пакета от B через порт, ведущий к B2, точка входа в данном порту станции B устаревает. То же самое происходит и с записью для A в порту, ведущем к В3 и В4. Далее после перевода соединения между B1 и B4 в режим переадресации начинается немедленная передача трафика по соединению через переобученные порты.

Принципы функционирования

В данном разделе описано, каким образом мост оповещает об изменении топологии на уровне пакета BPDU (Bridge Protocol Data Unit; Информационный пакет протокола STP). .

Этот вопрос уже был затронут при рассмотрении ситуации, когда мост определяет изменения в топологии сети. Вот точное определение:

  • Когда передающий порт становится недоступным (например, блокируется).

  • Когда порт переходит в состояние переадресации, и у моста имеется выделенный порт. (Это означает, что мост не является автономным.)

Процесс отправки уведомления на все мосты в сети состоит из двух шагов:

  • Мост уведомляет корневой мост связующего дерева.

  • Корневой мост передает эту информацию по всей сети в режиме широковещания.

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

При нормальной работе алгоритма STP мост продолжает получать информацию о конфигурации пакетов BPDU от корневого моста через свой корневой порт. Однако посылка пакетов BPDU к корневому мосту не производится. Для этой операции предусмотрен специальный пакет BPDU, называемый уведомлением об изменении топологии BPDU (topology change notification, TCN). Поэтому, если мост должен сообщить об изменении топологии, он начинает отправлять TCN-пакеты в свой корневой порт. Выделенный мост получает TCN-пакет, подтверждает его и создает другой пакет для собственного корневого порта. Этот процесс продолжается, пока TCN-пакет не попадет на корневой мост.

17c.gif

Уведомление TCN – это упрощенный пакет BPDU, не содержащий информации, посылаемой мостом через каждый интервал времени, определяемый параметром hello_time, в секундах (это локально настраиваемый интервал hello_time, а не интервал hello_time, заданный в конфигурации пакетов BPDU). Выделенный мост подтверждает TCN путем немедленной отправки BPDU стандартной конфигурации с заданным битом подтверждения изменения топологии (TCA). Мост, сообщающий об изменении топологии, не прекращает передачу пакетов TCN до тех пор, пока выделенный мост не подтвердит его получение. Тем не менее, выделенный порт посылает ответ на TCN, даже если он не получает конфигурацию BPDU от корневого моста.

Широковещание о событии в сети

После получения уведомления о том, в сети произошло изменение топологии, корневой мост начинает отправлять пакеты BPDU конфигурации с установленным битом изменения топологии (TC). Каждый мост ретранслирует эти пакеты BPDU в сеть с данным установленным битом. В результате все мосты уведомляются об изменении топологии и заменяют время устаревания на время задержки переадресации (forward_delay). Мосты получают пакеты BPDU с изменениями топологии и на переадресуемые, и на блокируемые порты.

Бит TC установлен на поддержку корневым мостом интервала времени max_age + forward_delay, что равно 20+15=35 секунд по умолчанию.

17d.gif

Что делать при больших изменениях топологии сети?

Пакеты TCN могут послужить причиной возникновения некоторых проблем. Они рассматриваются в сведениях об ограничении изменений топологии и поиске их причин.

Если от устройства Cisco получены выходные данные команды show-tech support, то в этом случае можно использовать инструмент Интерпретатор выходных данных (только для зарегистрированных клиентов), который отображает потенциальные проблемы и предлагает способы их решения. Для работы с Интерпретатором выходных данных (только для зарегистрированных клиентов) необходимо выполнить регистрацию в системе в качестве зарегистрированного пользователя и включить поддержку JavaScript.

Лавинная адресация пакетов

Чем больше число хостов в сети, тем выше вероятность изменения топологии. Например, напрямую подключенные хосты вызывают изменения топологии при перезапуске. В очень больших (и плоских) сетях,целевая точка может быть достигнута вне зависимости от постоянных изменений топологии сети. Это равносильно установке времени устаревания, равного пятнадцати секундам, что ведет к возрастанию уровня лавинной маршрутизации. При создании резервной копии на сервере, клиент оказался бы в неприятной ситуации.

17e.gif

Устаревание записи для устройства, получающего резервную копию, привело к отказу, потому что оно привело к интенсивному трафику, который повлиял на всех пользователей. Обратитесь к разделу Как избежать генерации TCN с помощью команды «portfast»" для получения информации о предотвращении генерации TCN.

Проблема в среде мостовых соединений ATM LANE

Данный случай представляет собой более серьезную ситуацию, чем обычная лавинная маршрутизация, вызванная коротким временем устаревания. В подтверждение топологических изменений сети VLAN, коммутатор Catalyst заставляет блейд-серверы, обеспечивающие эмуляцию LAN (LANE), повторно подтверждать таблицу LE-arp для соответствующей эмулируемой LAN (ELAN). Каждый блейд-сервер LANE в эмулируемой LAN (ELAN) отсылает один и тот же запрос в одно и то же время, что может вызвать перегрузку сервера эмуляции LAN (LAN Emulation Server, LES), если входов, требующих повторного подтверждения, слишком много. В данном сценарии наблюдаются проблемы с возможностью установления соединения. Если сеть чувствительна к изменениям топологии, проблема кроется не в изменениях топологии как таковых, а в проектировании сети. В этом случае рекомендуется ограничить генерацию TCN насколько это возможно, чтобы по крайней мере сохранить работоспособность ЦП сервера эмуляции LAN (LES). Обратитесь к разделу Как избежать генерации TCN с помощью команды «portfast» для получения информации о предотвращении генерации TCN.

Как избежать генерации TCN c помощью команды «portfast»

Функция portfast является проприетарным изменением Cisco в реализации STP. Эта команда применяется к определенным портам и имеет два следствия:

  • Активизированные порты переводятся напрямую в режим переадресации STP, при этом этапы прослушивания и обучения пропускаются. Протокол STP продолжает работать в портах с включенной поддержкой PortFast.

  • Коммутатор не генерирует пакет TCN, если порт, настроенный в режим portfast, включается или отключается.

Следует включать режим portfast в портах, к которым подключены хосты, способные устанавливать или отключать соединения (типично для оконечных станций, которые часто включаются и выключаются пользователями). Данная функция не является обязательной для серверных портов. Режим portfast не следует включать в портах, подключенных к концентраторам или другим мостам. Порт, который напрямую переключается в режим переадресации в избыточном соединении, может быть причиной временных мостовых петель.

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

Отслеживание источника TCN

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

Большинство мостов только подсчитывают количество входящих и исходящих TCN. Catalyst 4500/4000, 5500/5000 и 6500/6000 могут отображать порт и ID моста, от которого поступило последнее изменение топологии. Изменение топологии можно отследить по нисходящему потоку данных, начиная от корневого моста и вплоть до моста, инициировавшего изменение. Дополнительные сведения см. в выходных данных команды show spantree statistics.

Если от устройства Cisco получены выходные данные команды show failover, то в этом случае можно использовать инструмент Интерпретатор выходных данных (только для зарегистрированных клиентов), который отображает потенциальные проблемы и предлагает способы их решения. Для работы с Интерпретатором выходных данных (только для зарегистрированных клиентов) необходимо выполнить регистрацию в системе в качестве зарегистрированного пользователя и включить поддержку JavaScript.

Заключение

Важно учесть, что TCN-пакет не запускает повторного вычисления STP. Это опасение связано с тем, что TCN-пакеты часто ассоциируются с нестабильными средами STP. TCN-пакеты — не причина, а следствие нестабильности. TCN-пакеты влияют только на время устаревания данных о топологии сети. Они не изменяют топологию и не создают петель.

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

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 12013