Устранение неполадок протокола STP на коммутаторах Catalyst с ПО Cisco IOS System Содержание Введение Предварительные условия Требования Используемые компоненты Соглашения Причины сбоя STP Устранение неполадок, связанных с закольцовыванием Устранение неполадок лавинной маршрутизации, вызванных изменениями топологии Устранение неполадок, связанных с временем схождения Команды отладки STP Защита сети от закольцовывания Дополнительные сведения Введение В данном документе приведены инструкции по использованию ПО Cisco IOS® для устранения неполадок, связанных с протоколом связующего дерева (STP; Spanning-Tree Protocol).

Существуют особые команды, которые применимы только к коммутаторам Catalyst 6500/6000, однако большинство принципов можно использовать в любых коммутаторах Cisco Catalyst с ПО Cisco IOS. Существует три самые распространенные проблемы протокола STP:

закольцовывание чрезмерный поток пакетов вследствие высокой скорости изменений топологии (TC; Topology Changes) STP проблемы, связанные с временем схождения Поскольку в мостовом соединении отсутствует механизм отслеживания, передается ли определенный пакет несколько раз (например, время жизни (TTL) IP-пакета используется для сбрасывания трафика, циркулирующего в сети слишком долго), между устройствами, расположенными в одном домене 2 уровня, может существовать только один путь. Назначением STP является преобразование избыточной физической топологии в древовидную топологию при помощи блокирования избыточных портов, основанном на STP-алгоритме.

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

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

Page 1

Требования Cisco рекомендует ознакомиться с содержанием следующих разделов: Типы связующих деревьев и их настройка. Дополнительные сведения см. в документе Настройка STP и IEEE 802.1s MST. Функции связующих деревьев и их настройка. Дополнительные сведения см. в документе Настройка функций STP. Используемые компоненты Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения. Catalyst 6500 с модулем управления Supervisor Engine 2 Программное обеспечение Cisco IOS версии 12.1(13)E Данные для документа были получены в специально созданных лабораторных условиях.

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

Например, если A непосредственно подключено к B, A будет принимать пакеты от B, а B будет принимать пакеты от A до тех пор, пока между ними установлено соединение. Каждый мост, поддерживающий протокол STP, имеет возможность постоянно принимать, обрабатывать и отправлять блоки данных протокола моста (BPDU; Bridge Protocol Data Units) STP, так же известные как STP-пакеты. Не смотря на то, что приведенные выше требования являются логическими и очевидными, существуют ситуации, когда они не удовлетворяются. Большинство этих ситуаций включает в себя аппаратные проблемы, однако, ошибки программного обеспечения могут также приводить к отказам STP.

Отказы оборудования, неверная конфигурация или плохая укладка кабеля являются причиной большинства ошибок протокола STP, в то время как ошибки ПО несильно влияют на работу протокола. Сбои в работе протокола STP могут произойти из-за лишних дополнительных подключений между коммутаторами. Такие подключения могут вывести из строя VLAN. Для решения этой проблемы необходимо удалить все нежелательные подключения между коммутаторами. Когда одно из этих требований не выполняется, один или более мостов не смогут получать и обрабатывать пакеты BPDU. Это означает, что мост (или мосты) не сможет обнаружить топологию сети. Без данных о правильной топологии коммутатор не сможет блокировать петли.

Таким образом, лавинный трафик будет циркулировать в циклической топологии, снижая пропускную способность, что приведет к выходу сети из строя. Причины, по которым коммутаторы не принимают BPDU-пакеты: плохой приемопередатчик или конвертеры интерфейса Gigabit (GBIC), неисправный кабель, а также аппаратные ошибки порта, линейной платы или управляющего модуля. Самой распространенной причиной сбоя протокола STP является однонаправленное соединение между мостами. В таком случае, один мост отправляет BPDU- пакеты, но нисходящий их не получает. Обработка протоколом STP также может быть прервана из-за перегрузки ЦП (более 99 %), потому что коммутатор не сможет обрабатывать полученные BPDU-пакеты.

Повреждение BPDU-пакетов во время передачи от одного моста другому также может привести к ненормальному поведению STP.

Page 2

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

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

Идентификация петли. 1. При появлении закольцовывания в сети появляются следующие признаки: Потеря связи к, от и через затронутые области Повышенная нагрузка на ЦП маршрутизаторов, подключенных к затронутым сегментам сети или VLAN, что может привести к возникновению различных симптомов, например, переброскам соседа по протоколу маршрутизации или переброскам активного маршрутизатора по протоколу маршрутизации в режиме "горячего" резерва (HSRP).

Высокий коэффициент использования канала (часто 100%) Высокая нагрузка на объединительную плату (по сравнению с обычной нагрузкой) Сообщения системного журнала, которые указывают на зацикливание пакета в сети (например, сообщения дублированного IP адреса HSRP) Сообщение системного журнала, которые указывает на постоянное изменение адресов или появление сообщений о переброске MAC-адресов Возросшее количество отброшенных исходящих пакетов во многих интерфейсах Примечание. По отдельности, каждый из этих признаков может указывать на разные проблемы (или проявляться при их отсутствии).

Однако, когда одновременно наблюдается несколько таких признаков, скорее всего в сети образовалась петля передачи данных. Примечание. Самый быстрый способ убедиться в этом – проверить загруженность трафиком объединительной платы коммутатора: cat# show catalyst6000 traffic-meter traffic meter = 13% Never cleared peak = 14% reached at 12:08:57 CET Fri Oct 4 2002 Примечание. В настоящее время данная команда не поддерживается коммутатором Catalyst 4000 с ПО Cisco IOS.

Page 3

Если текущий уровень трафика существенно превышает норму или базовый уровень не известен, необходимо проверить, был ли пиковый уровень достигнут недавно и близок ли он к текущему уровню трафика. Например, пиковый уровень трафика составляет 15% и был достигнут 2 минуты назад, а уровень текущего трафика – 14%. Это означает, что коммутатор работает в необычно высокой загрузке. Если уровень нагрузки по потоку сообщений является нормальным, возможно, это значит, что либо петля отсутствует, либо устройство не затронуто этой петлей. Однако оно может находиться в "медленной петле". Обнаружение топологии (области действия) петли. 2.

Если причиной выхода из строя сети является закольцовывание, то в первую очередь необходимо остановить зацикливание и восстановить работу сети. Чтобы остановить зацикливание, необходимо выяснить, какие порты находятся в петле: найти порты с наибольшей загрузкой канала (количеством пакетов в секунду). Команда show interface ПО Cisco IOS отображает загрузку каждого интерфейса. Для отображения только имени интерфейса и сведений о загрузке (для быстрого анализа) можно использовать фильтр вывода регулярных выражений ПО Cisco IOS. Введите команду show interface | include line|\/sec для отображения количества пакетов, передаваемых в секунду, и имени интерфейса:

cat# show interface | include line|\/sec GigabitEthernet2/1 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/2 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/3 is up, line protocol is up 5 minute input rate 99765230 bits/sec, 24912 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/4 is up, line protocol is up 5 minute input rate 1000 bits/sec, 27 packets/sec 5 minute output rate 101002134 bits/sec, 25043 packets/sec GigabitEthernet2/5 is administratively down, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/6 is administratively down, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/7 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/8 is up, line protocol is up 5 minute input rate 2000 bits/sec, 41 packets/sec 5 minute output rate 99552940 bits/sec, 24892 packets/sec Особое внимание необходимо уделить интерфейсам с наибольшей загрузкой канала.

В данном примере интерфейсы g2/3, g2/4 и g2/8 возможно попали в петлю. Остановка зацикливания. 3. Чтобы остановить зацикливание, необходимо отключить или отсоединить соответствующие порты. Очень важно не только остановить зацикливание, а также найти и устранить причину его возникновения. Остановить зацикливание достаточно несложно. Примечание. Для того, чтобы устранить причину проблемы, необходимо не отключать все порты одновременно, а отключать их поочередно. Как правило, целесообразнее выключать порты в точке агрегирования, которая входит в петлю, такой как распределяющий или основной коммутатор.

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

Отключение таких перегружающих портов лишь немного снизит загрузку объединительной платы, но не остановит зацикливание. В представленном ниже примере топологии петля установилась между коммутаторами А, В и D, поэтому каналы AB, AD и BD

Page 4