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

Изменения топологии протокола Spanning Tree Protocol

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


Интерактивно этот документ предлагает анализ конкретного устройства Cisco.


Содержание


Введение

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

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

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

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

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

Требования

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

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

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

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

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

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

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

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

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

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

17a.gif

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

/image/gif/paws/12013/17b.gif

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

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

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

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

Этот раздел объясняет, как мост объявляет изменение топологии на уровне Блока данных протокола моста (BPDU)..

Было уже кратко объяснено, когда мост полагает, что это обнаружило изменение топологии. Точное определение таково:

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

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

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

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

  • Корневой мост "передает" информацию во всю сеть.

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

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

/image/gif/paws/12013/17c.gif

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

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

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

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

17d.gif

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

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

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

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

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

17e.gif

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

Проблема в среде мостового соединения ATM LANE

Этот случай более важен, чем обычное затопление трафика, подразумеваемого быстрым устареванием. На получении изменения топологии для VLAN Коммутатор Catalyst имеет свои блейды эмуляции LAN (LANE), подтверждающие их Таблицу le-arp для соответствующей эмулированной локальной сети (ELAN). Поскольку каждый Вывод LANE в ELAN выполняет в то же время тот же запрос, это может поместить высокое напряжение на Сервер эмуляции LAN (LES), если существует много записей для подтверждения. Проблемы с подключением были замечены в этом сценарии. Если сеть чувствительна к изменению топологии, реальная проблема не является самим изменением топологии, но дизайном сети. Рекомендуется ограничить как можно больше TCN поколение для сохранения ЦПУ LES (по крайней мере). Посмотрите Избегать TCN поколение с разделом команды portfast для получения дополнительной информации о том, как ограничить TCN поколение.

Избегите TCN поколение с командой portfast

Характеристикой PortFast является Cisco составляющее собственность изменение в применении STP. Эта команда применяется к конкретным портам и имеет два следствия:

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

  • Коммутатор никогда не создает TCN-пакетов при включении или выключении порта в режиме PortFast.

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

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

Проследите источник TCN

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

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

После получения с устройства Cisco выходных данных команды show spantree statistics можно использовать инструмент Интерпретатор выходных данных (только для зарегистрированных клиентов), отображающий потенциальные проблемы и способы их устранения. Для использования Output Interpreter (только для зарегистрированных пользователей), вы должны войти как зарегистрированный пользователь, с включенным JavaScript.

Заключение

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

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

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

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


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


Document ID: 12013