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

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

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

Содержание

Введение
Предварительные условия
     Требования
     Используемые компоненты
     Условные обозначения
Теоретические сведения о несовместимости PVID и типов
Поиск и устранение неполадок
Связанные обсуждения сообщества поддержки Cisco
Дополнительные сведения

Введение

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

Существуют следующие типы несовместимости STP.

В данном документе разъясняется способ устранения неполадок, вызванных несовместимостью PVID и типов. Для устранения несовместимости других типов обратитесь к ранее упомянутым документам.

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

Требования

Читатели данного документа должны иметь представление о принципах работы протокола STP.

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

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

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

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

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

Теоретические сведения о несовместимости PVID и типов

Коммутаторы Cisco Catalyst реализуют механизм PVST с помощью магистралей межкоммутаторных соединений (ISL, Inter-Switch Link). С появлением поддержки стандарта IEEE 802.1Q и магистральных соединений ISL потребовался способ реализации принципа взаимодействия между PVST и IEEE 802.1Q с одним связующим деревом для всех виртуальных сетей. Для этого была внедрена функция PVST+.

Примечание. С точки зрения протокола STP, стандарт IEEE 802.1D не учитывает механизм виртуальной локальной сети (VLAN), а стандарт IEEE 802.1Q учитывает его, но он использует единый экземпляр STP для всех сетей VLAN. То есть, если порт блокируется, то он блокируется для всех сетей VLAN на этом порте. То же самое относится к переадресации.

В следующем перечне показано, как механизм PVST+ взаимодействует со стандартом IEEE 802.1Q или 802.1D, если собственной сетью VLAN на магистрали IEEE 802.1Q является VLAN 1.

  • Блоки BPDU по протоколу STP сети VLAN 1 отправляются на МАС-адрес по протоколу STP согласно стандарту IEEE (0180.c200.0000) без тегов.

  • Блоки BPDU по протоколу STP сети VLAN 1 также отправляются на МАС-адрес дерева PVST+ без тегов.

  • Блоки BPDU по протоколу STP не из сети VLAN 1 отправляются на MAC-адрес PVST+ (он также называется MAC-адресом SSTP (протокол общего связующего дерева), – 0100.0ccc.cccd) с тегом соответствующей IEEE 802.1Q VLAN.

Если собственная сеть VLAN на магистрали IEEE 802.1Q не совпадает с VLAN 1, то:

  • Блоки BPDU по протоколу STP сети VLAN 1 отправляются на МАС-адрес PVST+ с тегом соответствующей IEEE 802.1Q VLAN.

  • Блоки BPDU по протоколу STP сети VLAN 1 также отправляются на МАС-адрес по протоколу STP согласно стандарту IEEE в собственной сети VLAN магистрали IEEE 802.1Q без тегов.

  • Блоки BPDU по протоколу STP не из сети VLAN 1 отправляются на МАС-адрес PVST+ с тегом соответствующей IEEE 802.1Q VLAN.

    Примечание. Блоки BPDU по протоколу STP собственной сети VLAN отсылаются без тегов.

Таким образом, протокол STP сети VLAN 1 дерева PVST+ объединяется с протоколом STP согласно стандарту IEEE 802.1D или 802.1Q, в то время как другие виртуальные сети туннелируются через "облако" мостов IEEE 802.1D или 802.1Q. Например, "облако" IEEE 802.1D или 802.1Q выглядит как "проводное соединение" с остальными сетями VLAN дерева PVST+ (кроме 1-ой).

Для правильной работы протокола STP необходимо придерживаться определенных правил при подключении мостов PVST+ к мостам IEEE 802.1D или 802.1Q. Основное правило состоит в том, что мосты PVST+ должны подключаться к мостам IEEE 802.1D или 802.1Q через магистраль IEEE 802.1Q с совместимой собственной сетью VLAN на всех мостах, подключаемых к "облаку" мостов IEEE 802.1Q или IEEE 802.1D.

Блок BPDU дерева PVST+ содержит номер сети VLAN, который позволяет мостам PVST+ проверять, не было ли нарушено предыдущее правило. Когда коммутатор Catalyst обнаруживает неверную конфигурацию, соответствующие порты переводятся в состояние "несовместимость PVID" или "несовместимость типов", что эффективным образом блокирует трафик через соответствующий порт в соответствующей сети VLAN. Эти состояния предотвращают возникновение петель переадресации вследствие неправильной настройки или монтажа.

Чтобы показать, почему необходимо обнаруживать несовместимость, рассмотрим следующую топологию, где на коммутаторах A и C работает протокол STP PVST+, а на коммутаторе B работает протокол STP стандарта 802.1Q.

pvid_inconsistency_24063a.gif

Если BPDU корня дерева в сети VLAN 1 лучше, чем блок корня в сети VLAN 2, то в топологии VLAN 2 порт не блокируется. Блок BPDU из VLAN 2 никогда не выполняет "круг" в топологии; он заменяется блоком BPDU сети VLAN 1 на канале B-C, так как на коммутаторе B работает только один протокол STP, объединенный с протоколом STP сети VLAN 1 PVST+. Так образуется петля переадресации. Однако коммутатор А отправляет блоки BPDU дерева PVST+ сети VLAN 2 (на адрес SSTP, который лавинообразно распространяется коммутатором B) по направлению к коммутатору С. Коммутатор С переведет порт С-В в состояние несовместимости типов, что предотвратит возникновение петли.

Примечание. В выходных данных некоторых команд состояние *-несовместимости протокола STP называется "нарушенным" (broken).

При обнаружении несовместимости STP коммутаторы отправляют в системный журнал следующие сообщения:

%SPANTREE-2-RECV_1Q_NON_TRUNK: Received IEEE 802.1Q BPDU on non trunk
FastEthernet0/1 on vlan 1.
%SPANTREE-2-BLOCK_PORT_TYPE: Blocking FastEthernet0/1 on vlan 1.
Inconsistent port type.

%SPANTREE-2-RX_1QPVIDERR: Rcved pvid_inc BPDU on 1Q port 3/25 vlan 1
%SPANTREE-2-RX_BLKPORTPVID: Block 3/25 on rcving vlan 1 for inc peer vlan 10
%SPANTREE-2-TX_BLKPORTPVID: Block 3/25 on xmtting vlan 10 for inc peer vlan

В данном примере VLAN 1 – это сеть, в которой был принят блок BPDU, а VLAN 10 – сеть, откуда был отправлен этот блок. Когда обнаруживается несовместимость, обе сети блокируются на том порту, откуда был получен блок BPDU.

Примечание. Содержание сообщений может отличаться в зависимости от типа и версии используемой операционной системы Cisco IOS® или Catalyst OS (CatOS).

Примечание. Если порт прекращает получение несовместимых блоков BPDU, состояние *-несовместимости очищается, и протокол STP изменяет состояние порта на основе обычного режима работы STP. В системный журнал отправляется сообщение об этом изменении:

%SPANTREE-SP-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/1 on vlan 1.
Port consistency restored.

Дополнительные сведения о работе PVST+ см. в документе Создание моста между между сетями VLAN IEEE 802.1Q.

Поиск и устранение неполадок

Для просмотра списка несовместимых портов используется команда show spanning-tree inconsistentports в недавно разработанной реализации протокола STP на основе системы Cisco IOS

В большинстве случаев основание для проверки на несовместимость STP данного порта очевидно:

  • Порт доступа получает блок BPDU по протоколу SSTP с тегом IEEE 802.1Q.

    pvid_inconsistency_24063b.gif

    В этом сценарии порт доступа на мосту А получает (от моста В) помеченный блок BPDU дерева PVST+ от протокола STP из сети VLAN, отличной от VLAN 1. Порт на коммутаторе А будет переведен в состояние несовместимости типов.

    Примечание. Необязательно соединять коммутаторы напрямую; их можно соединить через один или несколько коммутаторов IEEE 802.1D или 802.1Q или даже концентраторов, при этом результат будет таким же.

  • Магистральный порт со спецификацией IEEE 802.1Q получает блок BPDU SSTP без тегов. Этот блок имеет тип VLAN, длину, значение (TLV), которое не соответствует сети VLAN, в которой он был получен.

    pvid_inconsistency_24063c.gif

    В этом сценарии порт магистрали на коммутаторе A получает блок BPDU PVST+ от протокола STP сети VLAN 2 с тегом этой сети. Таким образом, порт на коммутаторе A блокируется как в сети VLAN 1, так и VLAN 2.

Если на обоих концах двухточечного соединения располагаются коммутаторы Cisco Catalyst, проверка конфигураций локального и удаленного портов обычно обнаруживает несоответствие конфигураций:

  • Порт настроен для магистрального соединения IEEE 802.1Q на одной стороне, а другая сторона является портом доступа.

  • Магистрали IEEE 802.1Q находятся на обеих сторонах, но собственные сети VLAN являются разными.

В таких случаях для устранения несовместимости STP следует устранить это несоответствие конфигураций.

В некоторых случаях выявить причину может быть не так просто:

  • Блок BPDU принимается из общей среды передачи с несколькими устройствами.

  • Блок BPDU принимается с облака коммутатора, где реализована модель протокола STP по стандарту IEEE 802.1D или 802.1D/Q, в которой коммутаторы PVST+ подключаются к "облаку".

  • Блок BPDU поступает из некоторого туннеля, например: "облака" DLSw+ (Data Link Switch Plus, дополнительный коммутатор для канала передачи данных), протокола туннелирования 2-го уровня (L2), EoMPLS, звеньев виртуального пути (Virtual Path Link, VPL), эмуляции локальных сетей (Local Area Network Emulation, LANE) и прочих.

pvid_inconsistency_24063d.gif

В этом примере коммутатор В настроен неправильно; он вводит блок BPDU протокола SSTP в "облако". Это приводит к тому, что порты на коммутаторах A, C и D становятся несовместимыми по типу. Проблема заключается в том, что устройство, которое отправляет неверный блок BPDU, не подключено напрямую к задействованным коммутаторам. Поэтому при наличии множества устройств в магистрали устранение неполадок во всех из них может занять много времени.

Однако существует систематический подход, предлагаемый для устранения этой проблемы.

  1. Установите для блока BPDU source MAC address и sending bridge ID. Это необходимо выполнить в то время, когда возникает данная неисправность.

  2. Найдите мост, являющийся источником "неверного" блока BPDU. Это можно сделать позднее, необязательно в момент возникновения проблемы.

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

Дополнительные сведения об использовании отладки для выгрузки содержимого памяти блоков BPDU протокола STP см. в разделе Команды для отладки протокола STP документа Устранение неполадок протокола STP на коммутаторах Catalyst под управлением интегрированной системы Cisco IOS (собственный режим).

Ниже приведен пример выходных данных команды отладки, содержащих принятые блоки BPDU.

*Mar 14 19:33:27: STP SW: PROC RX: 0100.0ccc.cccd<-0030.9617.4f08 type/len 0032
*Mar 14 19:33:27:     encap SNAP linktype sstp vlan 10 len 64 on v10 Fa0/14
*Mar 14 19:33:27:     AA AA 03 00000C 010B SSTP
*Mar 14 19:33:27:     CFG P:0000 V:00 T:00 F:00 R:8000 0050.0f2d.4000 00000000
*Mar 14 19:33:27:     B:8000 0050.0f2d.4000 80.99 A:0000 M:1400 H:0200 F:0F00
*Mar 14 19:33:27:     T:0000 L:0002 D:0001

Как только идентификатор отправляющего моста и MAC-адрес источника станут известны, необходимо найти устройство, которому принадлежит этот MAC-адрес. Это может осложняться тем фактом, что коммутаторы обычно не узнают MAC-адреса источника из кадров BPDU. Если задать команду show mac-address-table address mac_адрес_BPDU (для коммутаторов на основе системы Cisco IOS) или show cam mac_адрес (для коммутаторов на основе системы CatOS), то обычно записи не находятся.

Один из способов найти "неверный" MAC-адрес – собрать со всех коммутаторов, подключенных к "облаку", выходные данные команды show spanning-tree (для Cisco IOS) или show spantree (для CatOS). Выходные данные этих команд включают в себя информацию об идентификаторе (ID) каждого моста.

Boris# show spanning-tree
!--- Использование с Cisco IOS.

VLAN0001
  Spanning tree enabled protocol rstp
  Root ID    Priority    0
             Address     0007.4f1c.e847
             Cost        131
             Port        136 (GigabitEthernet3/8)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     00d0.003f.8800
!--- Выходные данные команды подавляются.

Doris (enable) show spantree
!--- Использование с CatOS.

VLAN 1
Spanning tree mode          RAPID-PVST+
Spanning tree type          ieee
Spanning tree enabled
Designated Root             00-07-4f-1c-e8-47
Designated Root Priority    0
Designated Root Cost        123
Designated Root Port        9/7                     
Root Max Age   20 sec   Hello Time 2  sec   Forward Delay 15 sec
Bridge ID MAC ADDR          00-d0-03-ef-4c-00
!--- Выходные данные команды подавлены.

Примечание. В зависимости от модели, версии программы и конфигурации коммутатор может иметь несколько MAC-адресов с идентификатором моста. Однако все адреса обычно будут относиться к определенному диапазону (например: от 0001.1234.5600 до 0001.1234.5640). Если известен один MAC-адрес с идентификатором моста, то можно проверить, попадает ли MAC-адрес отправляющего моста (найденный на 1-ом шаге) в диапазон MAC-адресов данного моста.

Для сбора идентификаторов всех мостов можно также применять инструменты управления сетью.

Как только будет найден мост, который отсылает "неверный" блок BPDU, необходимо будет проверить конфигурацию порта, который подключен к "облаку": убедитесь, что порт является совместимым (магистральным, в отличие от немагистрального порта и порта собственной сети VLAN) с другими коммутаторами, подключенными к тому же облаку.

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

Чтобы определить местоположение коммутатора с MAC-адресом источника блока BPDU, можно применить тот же подход, что и для поиска идентификатора моста, только на этот раз необходимо изучить выходные данные команды show module (для Catalyst 4000, 5000 и 6000). На коммутаторах 2900 XL, 3500 XL, 2950 и 3550 необходимо проверить выходные данные команды show interface, чтобы увидеть MAC-адреса, принадлежащие портам.

Cat4000-IOS# show module
!--- Использование для Catalyst 4000,5000,6000

Mod  Ports Card Type                              Model             Serial No.
----+-----+--------------------------------------+-----------------+-----------
 1      2  1000BaseX (GBIC) Supervisor(active)    WS-X4515          ZZZ00000001
 5     14  1000BaseT (RJ45), 1000BaseX (GBIC)     WS-X4412-2GB-T    ZZZ00000002

 M MAC addresses                    Hw  Fw           Sw               Status
--+--------------------------------+---+------------+----------------+---------
 1 000a.4172.ea40 to 000a.4172.ea41 1.2 12.1(12r)EW  12.1(14)E1, EARL Ok
 5 0001.4230.d800 to 0001.4230.d80d 1.0                               Ok
!--- Выходные данные команды подавляются.

cat3550# show interface | i bia

  Hardware is Gigabit Ethernet, address is 0002.4b28.da80 (bia 0002.4b28.da80)
  Hardware is Gigabit Ethernet, address is 0002.4b28.da83 (bia 0002.4b28.da83)
  Hardware is Gigabit Ethernet, address is 0002.4b28.da86 (bia 0002.4b28.da86)
  Hardware is Gigabit Ethernet, address is 0002.4b28.da88 (bia 0002.4b28.da88)
  Hardware is Gigabit Ethernet, address is 0002.4b28.da89 (bia 0002.4b28.da89)
!--- Выходные данные команды подавляются.

Примечание. В том случае, если облако – это DLSw+, обратитесь к документу Описание и настройка DLSw и 802.1Q.

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

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


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


Document ID: 24063