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

Устранение неполадок сред прозрачного формирования мостов

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


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


Содержание


Цели

Прозрачные мосты были сначала разработаны в Digital Equipment Corporation (DEC) в начале 1980-х и теперь очень популярны в сетях Ethernet/IEEE 802.3.

  • Эта глава сначала определяет прозрачный мост как обучающийся мост, который внедряет протокол STP. Включено всестороннее описание протокола STP.

  • Устройства Сisco, которые внедряют прозрачные мосты, использовали разделяться на две категории: маршрутизаторы, которые выполняют Cisco программное обеспечение IOS� и диапазон Catalyst коммутаторов, которые выполняют определенное программное обеспечение. Это больше не имеет место. Несколько Продуктов Catalyst теперь на основе IOS. Эта глава представляет другие способы мостового соединения, которые доступны на устройствах IOS. Для специфичной для программного обеспечения Catalyst конфигурации и устранения проблем сошлитесь на главу Коммутации LAN.

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

Основы технологии прозрачного режима моста

Прозрачные мосты называются так потому, что их присутствие и функционирование прозрачно для сетевых хостов. Когда прозрачные мосты включены, они изучают топологию сети анализом адреса источника входящих кадров от всех подключенных сетей. Если, например, мост видит, что кадр поступает в Линию 1 от Хоста A, мост приходит к заключению, что Хост A может быть достигнут через сеть, связанную с Линией 1. Посредством этого процесса прозрачные мосты создают внутреннюю таблицу моста, такую как та в Таблице 20-1.

Таблица 20-1: Таблица прозрачного режима моста

Адрес сетевого узла Номер сети
0000.0000.0001 1
0000.b07e.ee0e 7
? -
0050.50e1.9b80 4
0060.b0d9.2e3d 2
0000.0c8c.7088 1
? -

Мост использует таблицу моста в качестве основы для переадресации трафика. Когда кадр принят на одном из интерфейсов моста, мост ищет адрес назначения (DA) кадра в его внутренней таблице. Если таблица сопоставлена между адресом назначения (DA) и каким-либо из портов моста (кроме того, на котором кадр был принят), кадр передан к указанному порту. Если никакая карта не найдена, кадр лавинно разослан ко всем портам исходящих соединений. Широковещательные сообщения и многоадресные сообщения также лавинно рассылаются таким образом.

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

Замкнутые петли

Когда существуют разнообразные пути мостов и локальных сетей (LAN) между любыми двумя LAN в объединении нескольких локальных сетей, без моста к протоколу мостовой передачи отказывает алгоритм прозрачного моста. Рисунок 20-1 иллюстрирует такую замкнутую петлю.

/image/gif/paws/10543/Image13.gif

Рисунок 20-1: неточная переадресация и обучение в средах прозрачного режима моста

Предположим, что Хост A передает кадр к Хосту B. Оба моста принимают кадр и правильно приходят к заключению, что Хостом A является Сеть on 2. К сожалению, после того, как Хост B получает две копии кадра Хоста A, оба моста снова принимают кадр в своей Сети 1 интерфейс, потому что все хосты получают все сообщения на широковещательных LAN. В некоторых случаях мосты тогда изменят свои внутренние таблицы, чтобы указать, что Хостом A является Сеть on 1. Если это верно, когда ответы Хоста B на кадр Хоста A, оба моста получают и впоследствии отбрасывают ответы, потому что их таблицы показывают, что назначение (Хост A) находится на том же сегменте сети как источник кадра.

В дополнение к проблемам основного подключения, таким как описанная та, быстрое увеличение широковещательных сообщений в сетях с петлями представляет потенциально серьезная сетевая проблема. В отношении рисунка 20-1 предположите, что исходный кадр Хоста A является широковещанием. Оба моста передают кадры бесконечно, используют всю доступную пропускную способность сети и блокируют передачу других пакетов на обоих сегментах.

Топология с петлями такой как тот показанный на рисунке 20-1 может быть полезной, а также потенциально вредной. Петля подразумевает существование разнообразных путей через объединение нескольких локальных сетей. Сеть с разнообразными путями из источника назначению имеет то, что называют улучшенной топологической гибкостью, которая увеличивает полный допуск сбоя сети.

Алгоритм связующего дерева

Алгоритм связующего дерева (STA) был разработан DEC, ключевым поставщиком Ethernet, для сохранения преимуществ петель все же устраняют их проблемы. Алгоритм DEC был впоследствии пересмотрен комитетом по IEEE 802 и публикован в спецификации IEEE 802.1d. Алгоритмы DEC и IEEE 802.1d не являются ни одинаковыми, ни совместимыми.

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

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

Рисунок 20-2 иллюстрирует, как STA устраняет петли. STA посылает каждому мосту запрос на назначение уникального идентификатора. Как правило, этот идентификатор является одним из Адресов для управления доступом к среде (MAC) моста плюс индикация приоритета. Каждому порту в каждом мосте также назначают уникальное (в том мосте) идентификатор (как правило, его собственный MAC-адрес). Наконец, каждый порт моста привязан к стоимости пути. Стоимость пути представляет стоимость передачи кадра на LAN через тот порт. На рисунке 20-2 на стоимости пути обращают внимание на линиях, которые происходят от каждого моста. Затраты маршрута обычно задаются по умолчанию, но могут быть заданы вручную администратором сети.

/image/gif/paws/10543/Image14.gif

Рисунок 20-2: Прозрачная сеть с мостами (до STA)

Первым действием в вычислении связующего дерева является выбор основного моста, являющегося мостом с наименьшим значением идентификатора. На рисунке 20-2 корневой мост является Мостом 1. Затем, корневой порт на всех других мостах определен. Корневой порт моста является портом, через который корневой мост может быть достигнут с наименее составной стоимостью пути. Значение наименьшей агрегированной стоимости пути к корню называется стоимостью корневого пути.

Наконец, назначенные мосты и их назначенные порты определены. Назначенный мост является мостом на каждой LAN, которая предоставляет минимальную стоимость корневого пути. Назначенный мост LAN является единственным мостом, позволенным передать кадры к и от LAN, для которой это - назначенный мост. Назначенный порт LAN является портом, который подключает его с назначенным мостом.

В некоторых случаях двум или больше мостам можно было стоить того же корневого пути. Например, на рисунке 20-2, Мосты 4 и 5 могут оба достигнуть Моста 1 (корневой мост) со стоимостью пути 10. В этом случае идентификаторы моста используются снова, на этот раз, для определения назначенных мостов. LAN V портов Моста 4 выбрана по LAN V портов Моста 5.

С этим процессом все кроме одного из мостов, непосредственно связанных с каждой LAN, устранены, который удаляет все петли с двумя LAN. STA также устраняет петли, которые включают больше чем две LAN, и все же сохраняют подключение. Рисунок 20-3 показывает результаты приложения STA к сети, показанной на рисунке 20-2. Рисунок 20-2 показывает древовидную топологию более ясно. Сравнение этого рисунка к рисунку 20-3 показывает, что STA разместил порты в LAN V и в Мосте 3 и в Мосте 5 в режиме ожидания.

/image/gif/paws/10543/Image15.gif

Рисунок 20-3: Сеть на основе прозрачного моста (после STA)

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

Соединяет обменные сообщения настройки через определенные промежутки времени (как правило, одна - четыре секунды). Если мост отказывает (который вызывает изменение топологии), соседние мосты скоро обнаруживают отсутствие сообщений настройки и инициируют перерасчет связующего дерева.

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

Формат фрейма

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

В таблице 20?2 отображается формат сообщения конфигурации IEEE 802.1d.

Таблица 20-2: Конфигурация прозрачных мостовых соединений

Идентификатор протокола Version Тип сообщения Флаги Идентификатор корня Стоимость пути к корню Идентификатор моста Идентификатор порта Возраст сообщения Максимальный возраст Время приветствия Forward delay
2 байта 1 байт 1 байт 1 байт 8 байт 4 байта 8 байт 2 байта 2 байта 2 байта 2 байта 2 байта

Поля сообщения

Сообщения конфигурации прозрачного соединения состоят из 35 байтов. Это поля сообщения:

  • Идентификатор протокола: Содержит значение 0.

  • Version : Содержит значение 0.

  • Тип сообщения: Содержит значение 0.

  • Флаг: однобайтовое поле, которого только первые два бита используются. Бит изменения топологии (TC) свидетельствует об изменении топологии. Бит подтверждения изменения топологии (TCA) устанавливается с целью подтверждения получения сообщения настройки с установленным битом TC.

  • Идентификатор корня: Определяет корневой мост и перечисляет его 2 приоритета байта, придерживавшиеся его шестибайтовым ID.

  • Стоимость пути к корню: Содержит стоимость пути из моста, который передает сообщение настройки к корневому мосту.

  • Идентификатор моста: Определяет приоритет и ID моста, который передает сообщение.

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

  • Возраст сообщения: Задает время работы (астрономическое), так как root передал сообщение настройки, на котором основывается сообщение текущей конфигурации.

  • Максимальный возраст: Когда сообщение текущей конфигурации должно быть удалено, указывает.

  • Время приветствия: Предоставляет период времени между сообщениями настройки корневого моста.

  • Forward delay: Предоставляет мосты периода времени, должен ждать перед переходом к новому состоянию после изменения топологии. Если последовательно-параллельные переключения слишком скоро, не все соединения сети могут быть готовы изменить свое состояние, и петли могут закончиться.

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

  • Идентификатор протокола: Содержит значение 0.

  • Version : Содержит значение 0.

  • Тип сообщения: Содержит значение 128.

Другие способы мостового соединения IOS

Маршрутизаторы Cisco имеют три других способа внедрить мостовое соединение: Поведение по умолчанию, Оптимальная производительность маршрутизации и использования мостов (CRB) и Integrated routing and bridging (IRB).

Поведение по умолчанию

Прежде чем IRB и функции CRB были доступны, вы только смогли соединить или направить протокол на не основе платформы. Т.е. если команда ip route использовалась, например, IP routing был сделан на всех интерфейсах. В этой ситуации IP не мог быть соединен ни на одном из интерфейсов маршрутизатора.

Concurrent Routing and Bridging (CRB)

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

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

/image/gif/paws/10543/Image16.gif

Рисунок 20-4: Concurrent Routing and Bridging (CRB)

Concurrent Routing and Bridging (IRB)

IRB предоставляет возможность направить между bridge-group и маршрутизируемым интерфейсом с понятием под названием Виртуальный интерфейс мостовой группы (BVI). Поскольку мостовое соединение происходит на канальном уровне и направляющий на сетевом уровне, у них есть другие модели конфигурации протокола. Относительно IP-адресов: например, интерфейсы мостовой группы принадлежат к одной сети и у них групповой IP-адрес сети, но каждый в отдельности маршрутизируемый интерфейс представляет выделенную сеть со своим собственным IP-адресом.

Концепция BVI была создана для разрешения этим интерфейсам обмениваться пакетами для данного протокола. Концептуально, как показано в данном примере, маршрутизатор Cisco похож на маршрутизатор, связанный с одним или более bridge-group:

/image/gif/paws/10543/Image17.gif

Рисунок 20-5: Concurrent Routing and Bridging (IRB)

BVI – это виртуальный интерфейс маршрутизатора, который действует как обычный маршрутизируемый интерфейс. BVI представляет соответствующего bridge-group маршрутизируемым интерфейсам в маршрутизаторе. Номер интерфейса BVI является количеством bridge-group, представленного этим виртуальным интерфейсом. Номер является связью между этим интерфейсом BVI и группой моста.

Данный пример иллюстрирует, как принцип BVI применяется к Модульному коммутатору с функциями маршрутизатора (RSM) в Коммутаторе Catalyst:

Image18.gif

Рисунок 20-6: Модуль коммутации маршрутов (RSM) для коммутатора Catalyst.

Устранение неполадок прозрачного соединения

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

Примечание: Проблемы, связанные с маршрутизацией от источника (SRB), трансляционным соединением и прозрачным соединением маршрут-источник (SRT), рассматриваются в главе 10: "Поиск и устранение неполадок на платформе IBM."."

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

Они должны быть доступными:

  • Карта топологии сети с мостовыми подключениями

  • Местоположение корневого моста

  • Местоположение избыточного соединения (и блокированные порты)

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

Эти разделы описывают наиболее распространенные проблемы сети в прозрачных сетях с мостовыми подключениями:

Прозрачное соединение: Нет возможности подключения

Признак: Клиент не может соединиться с хостами по прозрачно сеть с мостовыми подключениями.

Таблица 20-3 выделяет проблемы, которые могут вызвать этот признак и предлагают решения.

Таблица 20-3: Прозрачное соединение: Нет возможности подключения

Возможные причины Предлагаемые действия
Аппаратные средства или проблема сред
  1. Используйте команду EXEC show bridge, чтобы посмотреть, есть ли проблемы с возможностью подключения. Если так, выходные данные не покажут адресов MAC[1] в таблице моста.
  2. Используйте команду show interfaces EXEC, чтобы определить, работают ли интерфейс и линейный протокол.
  3. Если интерфейс не работает, устраните неполадки аппаратных средств или сред. Обратитесь к главе 3, "Устранение неполадок оборудования и процесса загрузки"."
  4. Если line protocol is down, проверьте физическое соединение между интерфейсом и сетью. Удостоверьтесь, что соединение безопасно и что не повреждены кабели.
Если протокол линии связи произошел, но счетчики входящего и исходящего пакета не инкрементно увеличиваются, проверьте среды и разместите подключение. См. раздел об устранении неполадок носителя, который посвящен типам сетевых носителей.
Хост не работает
  1. Для проверки наличия в таблице мостовых соединений MAC-адресов подключенных оконечных узлов выполните команду show bridge для соответствующего моста. Таблица мостовых соединений содержит начальные и конечные MAC-адреса хостов и заполняется при прохождении пакетов из исходного или конечного пункта через мост.
  2. Если какие-либо ожидаемые конечные узлы отсутствуют, проверьте статус узлов, чтобы проверить, что они связаны и должным образом настроены.
  3. Повторно инициализируйте или реконфигурируйте конечные узлы по мере необходимости и вновь исследуйте таблицу моста с командой show bridge.
Мостовое соединение пути сломано
  1. Определите путь, который пакеты должны взять между конечными узлами. Если существует маршрутизатор на этом пути, разделите устранение проблем на две части: 1 маршрутизатор Узла и Узел маршрутизатора 2.
  2. Соединитесь с каждым мостом на пути и проверьте статус портов, используемых на пути между конечными узлами (как описано в "Аппаратных средствах или проблемном элементе таблицы" сред.
  3. Используйте команду show bridge, чтобы удостовериться, что MAC-адрес узлов изучен на правильных портах. В противном случае на топологии связующего дерева может быть нестабильность. Посмотрите Таблицу 20-2, "Прозрачный режим моста: Неустойчивое связующее дерево."
  4. Проверьте состояние портов с командой show span. Если порты, которые могут передать трафик между конечными узлами, не находятся в состоянии пересылки, топология дерева могла неожиданно измениться. См. таблицу 20-4, "Прозрачный мост для неустойчивого связующего дерева"."
Неверно - настроенные фильтры мостового соединения
  1. Используйте команду show running-config privileged EXEC, чтобы определить, настроены ли мостовые фильтры.
  2. Отключите мостовые фильтры на подозрительных интерфейсах и определите, восстановлено ли подключение.
  3. Если подключение не восстановлено, фильтр не является проблемой. Если подключение восстановлено после того, как фильтры демонтированы, один, или более плохие фильтры являются причиной неполадок подключения.
  4. Если или множественные фильтры существуют или фильтры, которые используют списки доступа с нескольками операторов, существуют, применяют каждый фильтр индивидуально для определения проблемного фильтра. Проверьте конфигурацию для ввод/вывода LSAP [2] и Фильтров TYPE, которые могут использоваться одновременно для блокирования других протоколов. Например, LSAP (F0F0) может использоваться для блокирования NetBIOS, и ТИП (6004) может использоваться для блокирования передачи данных локальной области.
  5. Модифицируйте любые фильтры или списки доступа тот блочный трафик. Продолжите тестировать фильтры, пока все фильтры не включены, и соединения все еще работают.
Полные очереди ввод/вывода Чрезмерная групповая адресация или широковещательный трафик могут заставить очереди ввод/вывода переполняться, который приводит к отброшенным пакетам.
  1. Используйте команду show interfaces для поиска отбрасываний ввод/вывода. Отбрасывания предлагают избыточный трафик по средам. Если текущий номер пакетов на входной очереди последовательно в или выше 80% текущего размера входной очереди, размер входной очереди должен быть настроен для размещения скорости передачи пакетов. Даже если текущий номер пакетов на входной очереди никогда, кажется, не приближается к размеру входной очереди, пакеты пакетов могут все еще переполнить очереди.
  2. Уменьшите широковещание и многоадресный трафик на подключенных сетях с использованием фильтров мостового соединения, или сегментируйте сеть с большим количеством межсетевых устройств.
  3. Если соединение является последовательным соединением, пропускной способностью увеличения, примените очереди с приоритетами, увеличьте размер удержания очереди или модифицируйте объем системного буфера. Для получения дополнительной информации сошлитесь на Главу 15, "Устраняя неполадки Проблем последовательного канала".

[1]MAC = управление доступом к передающей среде

[2]LSAP = Точка доступа служб каналов

Прозрачное соединение: Неустойчивое связующее дерево

Признак: Кратковременная потеря возможности подключения между узлами. Затронуты одновременно несколько узлов.

Таблица 20-4 выделяет проблемы, которые могут вызвать этот признак и предлагают решения.

Таблица 20-4: Прозрачное соединение: Неустойчивое связующее дерево

Возможные причины Предлагаемые действия
Колебания связи
  1. Используйте команду show span, чтобы видеть, увеличивается ли постоянно количество изменений топологии.
  2. Если так, проверьте ссылку между мостами с командой show interface. Если эта команда не показывает колебания связи между двумя мостами, используйте привилегированную исполнительную команду spantree отладки на мостах.
Это регистрирует все изменения, отнесенные к связующему дереву. В устойчивой топологии не может быть никого. Единственные ссылки на дорожку - те, которые подключают устройства моста вместе. Переход на ссылке на конечную станцию не должен оказывать влияние на сеть.

Примечание: Поскольку выходным данным отладки назначают, высокий приоритет в Процессе ЦПУ, для использования события command spantree отладки может представить неприменимую систему. Поэтому используйте команды отладки только для устренения определенных проблем или когда на сеансах для устренения проблем со штатом службы технической поддержки Сisco. Кроме того, лучше использовать команды отладки в течение периодов низкого сетевого трафика и меньшего количества пользователей. Если вы отлаживаете в течение этих периодов, это уменьшает вероятность, которая увеличилась, служебные процессы команды отладки будут влиять на системное использование.

Корневой мост продолжает изменять / множественное требование мостов быть root
  1. Проверьте непротиворечивость информации о корневом мосте на всем протяжении сети с мостовыми подключениями с командами show span на других мостах.
  2. Если существует несколько мостов, которые утверждают, что были root, удостоверьтесь, что вы выполняете тот же протокол STP на каждом мосту (см., что Алгоритм связующего дерева не соответствует" элементу таблицы в Таблице 20-6).
  3. Используйте мост приоритет <group> команда <number> на корневом мосту, чтобы вынудить требуемый мост стать root. Чем ниже приоритет, тем с большей вероятностью это для моста для становления root.
  4. Проверьте диаметр сети. Со стандартным установленным связующим деревом между двумя хостами никогда не должно быть больше чем семи переходов моста.
Hellos, которым не обмениваются
  1. Проверьте, чтобы видеть, связываются ли мосты друг с другом. Используйте анализатор сети, или debug spantree tree дал команде EXEC привилегию, чтобы видеть, структурирует ли связующее дерево привет, обменены.

    Примечание: Поскольку выходным данным отладки назначают, высокий приоритет в Процессе ЦПУ, для использования события command spantree отладки может представить неприменимую систему. Поэтому используйте команды отладки только для устренения определенных проблем или когда на сеансах для устренения проблем со штатом службы технической поддержки Сisco. Кроме того, лучше использовать команды отладки в течение периодов низкого сетевого трафика и меньшего количества пользователей. Если вы отлаживаете в течение этих периодов, это уменьшает вероятность, которая увеличилась, служебные процессы команды отладки будут влиять на системное использование.

  2. Если hellos не обмениваются, проверьте физические соединения и конфигурацию ПО на мостах.

Прозрачное соединение: Непредвиденное завершение сеансов

Признак: Соединения в прозрачно среда мостовых соединений успешно установлена, но сеансы иногда завершаются резко.

Таблица 20-5 выделяет проблемы, которые могут вызвать этот признак и предлагают решения.

Таблица 20-5: Прозрачное соединение: Непредвиденное завершение сеансов

Возможные причины Предлагаемые действия
Избыточные повторные передачи
  1. Используйте анализатор сети для поиска повторных передач хоста.
  2. Если вы видите повторные передачи на низкоскоростных последовательных линиях, увеличиваете таймеры передачи на хосте. Для получения информации о том, как настроить хосты, сошлитесь на документацию поставщика. Для получения информации о том, как устранить неполадки последовательных линий, сошлитесь на Главу 15, "Устраняя неполадки Проблем последовательного канала". Если вы видите повторные передачи на средах высокоскоростной локальной сети, проверьте для пакетов, переданных и полученных в заказе или отброшенных любым промежуточным устройством (таких как мост или коммутатор). Устраните неполадки среды LAN подходящим методом. Для получения дополнительной информации сошлитесь на главу о том, как устранить неполадки сред, который покрывает тип носителя, используемый в сети.
  3. Используйте анализатор сети, чтобы определить, снижается ли число ретрансляций.
Избыточная задержка по последовательному соединению Пропускная способность увеличения, примените постановку в очередь с установлением приоритетa, увеличьте размер удержания очереди или модифицируйте объем системного буфера. Для получения дополнительной информации сошлитесь на Главу 15, "Устраняя неполадки Проблем последовательного канала".

Прозрачное соединение: Цикличное выполнение и широковещательные штормы происходят

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

Примечание: Зацикливания пакетов, как правило, вызываются ошибками проектирования сети или проблемами аппаратных средств.

Таблица 20-6 выделяет проблемы, которые могут вызвать этот признак и предлагают решения.

Замкнутые петли являются наихудшим случаем в сети с мостовыми подключениями, так как он потенциально повлияет на каждого пользователя. В случае крайней необходимости лучший способ восстановить подключение быстро состоит в том, чтобы вручную отключить все интерфейсы, которые предоставляют путь с избыточным резервом в сети. К сожалению, в этом случае впоследствии будет очень сложно определить замкнутую петлю. Если возможно, попробуйте действия Таблицы 20-6 заранее.

Таблица 20-6: Прозрачное соединение: Цикличное выполнение и широковещательные штормы происходят

Возможные причины Предлагаемые действия
Никакое связующее дерево не внедрено
  1. Исследуйте схему топологии объединения нескольких локальных сетей для проверки для возможных петель.
  2. Устраните любые петли, которые существуют или удостоверяются, что соответствующие ссылки находятся в режиме резервирования.
  3. Если широковещательные штормы и зацикливания пакетов сохраняются, используйте команду EXEC show interfaces для получения статистики количества входящего и исходящего пакета. Если эти счетчики инкрементно увеличиваются на аномально высокой скорости (относительно загрузок обычного трафика), петля, вероятно, все еще присутствует в сети.
  4. Внедрите алгоритм связующего дерева для предотвращения петель.
Несоответствие алгоритма связующего дерева
  1. Используйте команду EXEC show span на каждом мосту для определения, какой алгоритм связующего дерева используется.
  2. Удостоверьтесь, что все мосты выполняют тот же алгоритм связующего дерева (или DEC или IEEE) [1]. Может быть необходимо использовать и DEC и алгоритмы связующего дерева IEEE в сети для некоторых очень определенных конфигураций (общим образом, те, которые включают IRB). Если несоответствие в протоколе STP не предназначено, реконфигурируйте мосты как соответствующие так, чтобы все мосты использовали тот же алгоритм связующего дерева.

Примечание: DEC и алгоритмы связующего дерева IEEE являются несовместимыми.

Неправильно настроены множественные домены соединения
  1. Команда show span EXEC используется на мостах, чтобы убедиться в том, что все номера группы домена соответствуют заданным доменам с мостовым соединением.
  2. Если группы составного домена настроены для моста, гарантируют, что все спецификации домена назначены правильно. Используйте <group> моста домен <Номер домена> команда глобальной кофигурации для создания любых необходимых изменений.
  3. Удостоверьтесь, что никакие петли не существуют между доменами соединения. Междоменная среда мостовой передачи не предоставляет предотвращение петель на основе связующего дерева. Каждый домен имеет свое собственное связующее дерево, которое независимо от связующего дерева в других доменах.
Ошибка соединения (однонаправленное соединение), несогласованность дуплексных параметров, высокий уровень ошибки на порту. Петли происходят, когда порт, который должен перемещения блока к состоянию пересылки. Порт должен получить BPDU от соседнего моста для пребывания в состоянии блокировки. Любая ошибка, которая приводит к потерянным BPDU, может тогда быть причиной замкнутой петли.
  1. Определите блокирующие порты от схемы сети.
  2. Проверьте статус портов, которые должны заблокироваться в сети с мостовыми подключениями с show interface и командами EXEC show bridge.
  3. Если вы находите возможно блокированный порт, который в настоящее время передает или собирается передать (т.е. в изучении или слушать состояние), вы нашли фактический источник проблемы. Проверьте, чтобы видеть, получает ли этот порт BPDU. В противном случае существует, вероятно, проблема на ссылке, связанной с этим портом. Затем проверьте ошибки канала, настройки дуплекса и т.п.).
Если порт все еще получает BPDU, переходит к мосту, что вы ожидаете быть назначенными для этой LAN. Затем проверьте все каналы на пути к корню. Вы обнаружите неисправность на одном из этих каналов (при условии, что первоначальная схема сети была правильной).

[1]IEEE = Институт инженеров по электротехнике и электронике

Перед вызовом специалистов центра технической помощи Cisco Systems

Когда сеть стабильна, соберите столько информации, сколько вы можете о ее топологии.

Как минимум соберите эти данные:

  • Физическая топология сети

  • Ожидаемое местоположение корневого моста (и резервный корневой мост)

  • Местоположение блокированных портов

Дополнительные источники

Книги:

  • Соединения, мосты и маршрутизаторы, Рэдия Перлман, Аддисон-Уэсли

  • Коммутация Cisco LAN, K.Clark, K.Hamilton, Cisco Press

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

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


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


Document ID: 10543