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

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

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


Содержание


Введение

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

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

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

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

Требования

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

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

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

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

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

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

Теоретические основы несогласованности идентификатора порта VLAN и типов

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

Примечание: С точки зрения STP IEEE 802.1D – это не виртуальная локальная сеть, а IEEE 802.1Q – виртуальная локальная сеть, но использующая единую копию STP для всех виртуальный локальных сетей. То есть, если порт блокируется, то он блокируется для всех сетей 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 выглядит подобным “проводу” к PVST + VLAN кроме 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:

/image/gif/paws/24063/pvid_inconsistency_24063a.gif

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

Примечание: Непоследовательное состояние STP обозначается в некоторых выходах команд *- как "неисправное.".”

При обнаружении несовместимости 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 (CatOS), которая используется.

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

%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.

    /image/gif/paws/24063/pvid_inconsistency_24063b.gif

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

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

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

    /image/gif/paws/24063/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) и прочих.

/image/gif/paws/24063/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

!--- Use with 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

!--- Output suppressed.

Doris (enable) show spantree

!--- Use with 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

!--- Output suppressed.

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

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

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

Может случиться, что мост отправляет правильные блоки BPDU, но в "облако" туннелирования они поступают некорректно измененными. В этом случае вы видите, что “незаконный” BPDU, который вводит облако, совместим с конфигурацией других мостов, но тот же BPDU становится противоречивым, когда это выходит из облака (например, BPDU выходит из облака в другой VLAN или становится тэговым или без меток). В таком случае это может помочь проверять, принадлежит ли источник с 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

!--- Use for 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

!--- Output suppressed.

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)

!--- Output suppressed.

Примечание: Если облако является DLSw+, обратитесь к Пониманию и DLSw Настройки и 802.1Q.


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


Document ID: 24063