Troubleshooting de Inconsistências de PVID e Tipo de Spanning Tree

Introduction

Em redes da Camada 2 (L2), pode haver somente um caminho entre quaisquer dois dispositivos. A redundância é suportada pelo Spanning-Tree Protocol (STP), que detecta e bloqueia caminhos redundantes e, assim, evitando loops de encaminhamento. Determinadas configurações incorretas podem conduzir a uma falha de STP e causar uma queda da rede. Para evitar o tempo de inatividade, algumas melhorias foram implementadas para que o STP detecte certos casos de configuração incorreta e a porta relevante seja colocada em um estado "inconsistente".

Podem existir diferentes tipos de inconsistências STP:

• Inconsistência de loop — Isso é detectado pelo recurso Loop Guard. Para obter mais informações, consulte Aprimoramentos do Spanning-Tree Protocol usando os recursos de proteção de loop e detecção de desvio de BPDU.

• Inconsistência raiz — Isso é detectado pelo recurso Root Guard. Para obter mais informações, consulte Aprimoramento do Protetor de Raiz do Spanning-Tree Protocol.

• Inconsistência de EtherChannel — Isso é detectado pelo recurso de detecção de consistência de EtherChannel. Para obter mais informações, consulte Understanding EtherChannel Inconsistency Detection.

• Inconsistência de ID de VLAN de porta (PVID)—Uma BPDU (Bridge Protocol Data Unit) por árvore de abrangência de VLAN (PVST+) é recebida em uma VLAN diferente da origem: (Incompatibilidade de ID de VLAN da porta ou *PVID_Inc).

• Tipo de inconsistência—Um PVST+ BPDU é recebido em um tronco não 802.1Q.

Esse documento explica como solucionar problemas causados pelas últimas duas inconsistências, PVID e tipo. Consulte os documentos mencionados anteriormente para solucionar problemas de outras inconsistências.

Prerequisites

Requirements

Os leitores deste documento devem ter conhecimento dos conceitos do STP.

Componentes Utilizados

Este documento não é restrito a versões de software ou hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Teoria por trás das inconsistências de PVID e de tipo

Os Cisco Catalyst Switches implementam o PVST utilizando troncos de ISL (Circuito inter-Switches). Com o suporte do entroncamento IEEE 802.1Q e ISL, era necessário um modo de interoperação entre o PVST e o conceito IEEE 802.1Q de uma única árvore de abrangência para todas as VLANs. O recurso PVST+ foi introduzido para tratar desse requisito.

Observação: do ponto de vista do STP, o IEEE 802.1D não reconhece VLAN e o IEEE 802.1Q reconhece VLAN, mas usa uma única instância do STP para todas as VLANs. Ou seja, se a porta estiver bloqueando, ela estará bloqueando todas as VLANs nessa porta. O mesmo vale para o encaminhamento.

Esta lista mostra como o PVST+ interopera com IEEE 802.1Q ou IEEE 802.1D, se a VLAN nativa em um tronco IEEE 802.1Q for VLAN 1:

• As BPDUs STP da VLAN 1 são enviadas para o endereço MAC STP do IEEE (0180.c200.0000), sem marcação.

• As BPDUs do STP da VLAN 1 também são enviadas para o endereço MAC do PVST+, sem marcação.

• As BPDUs STP não-VLAN 1 são enviadas para o endereço MAC PVST+ (também chamado de endereço MAC do Shared Spanning Tree Protocol [SSTP], 0100.0ccc.cccd), marcado com uma marca VLAN IEEE 802.1Q correspondente.

Se a VLAN nativa em um tronco IEEE 802.1Q não for a VLAN 1:

• As BPDUs do STP da VLAN 1 são enviadas ao endereço MAC do PVST+, rotuladas com uma marca de VLAN IEEE 802.1Q correspondente.

• As BPDUs de STP da VLAN 1 também são enviadas para o endereço MAC do STP IEEE na VLAN nativa do tronco IEEE 802.1Q, não rotulado.

• As BPDUs STP não VLAN 1 são enviadas ao endereço MAC PVST+, rotuladas com uma marca de VLAN IEEE 802.1Q correspondente.

  Observação: as BPDUs de STP de VLAN nativa são enviadas sem marcação.

Dessa forma, o STP da VLAN 1 do PVST+ se funde com o STP do IEEE 802.1D ou 802.1Q, enquanto outras VLANs são encapsuladas através da nuvem das bridges IEEE 802.1D ou 802.1Q. Por exemplo, a nuvem IEEE 802.1D ou 802.1Q se parece com um "fio" para as VLANs PVST+ diferentes de 1.

Para que o STP funcione corretamente, observe determinadas regras ao conectar pontes PVST+ às pontes IEEE 802.1D ou 802.1Q. A regra principal é que as bridges PVST+ devem se conectar às bridges IEEE 802.1D ou 802.1Q através de um tronco IEEE 802.1Q com uma VLAN nativa consistente em todas as bridges que se conectam à nuvem das bridges IEEE 802.1Q ou 802.1D.

O PVST+ BPDU contém um número de VLAN que permite que as bridges PVST+ detectem se a regra anterior não é respeitada. Quando um switch Catalyst detecta uma configuração incorreta, as portas correspondentes são colocadas em um estado "inconsistente com PVID" ou "inconsistente com o tipo", que bloqueia efetivamente o tráfego na VLAN correspondente em uma porta correspondente. Esses estados evitam loops de encaminhamento que causam erros de configuração ou cabeamento.

Para ilustrar a necessidade de detecção de inconsistência, considere esta topologia, onde os switches A e C estão executando PVST+ STP e o switch B está executando 802.1Q STP:

Se a BPDU da raiz na VLAN 1 for melhor que a BPDU da raiz na VLAN 2, então não há nenhuma porta de bloqueio na topologia da VLAN 2. A BPDU da VLAN 2 nunca faz um "círculo completo" em torno da topologia; ele é substituído pelo VLAN 1 BPDU no link B-C, porque B executa apenas um STP mesclado com VLAN 1 STP do PVST+. Portanto, há um loop de encaminhamento. Felizmente, o switch A envia BPDUs PVST+ da VLAN 2 (para o endereço SSTP que é inundado pelo switch B) para o switch C. O switch C colocará a porta C-B em um estado inconsistente de tipo, o que impede o loop.

Observação: em algumas saídas de comando, o estado *-STP inconsistente é chamado de "interrompido".

Quando a inconsistência de STP é detectada, os switches enviam estas mensagens de syslog:

%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

Nesse exemplo, a VLAN 1 é onde a BPDU foi recebida e a VLAN 10 é onde a BPDU foi originada. Quando a inconsistência é detectada, ambas as VLANs são bloqueadas na porta onde esta BPDU é recebida

Observação: as mensagens podem variar com base no tipo e na versão do Cisco IOS® Software Release ou do sistema operacional Catalyst OS (CatOS) que está em uso.

Observação: se a porta parar de receber BPDUs inconsistentes, o estado *-inconsistente é limpo e o STP altera o estado da porta com base na operação normal do STP. Uma mensagem do syslog é enviada para indicar a alteração:

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

Para obter mais detalhes sobre a operação do PVST+, consulte Bridging Entre VLANs IEEE 802.1Q.

Troubleshooting

Para ver a lista de portas inconsistentes, a recente implementação STP baseada no Cisco IOS suporta o comando show spanning-tree inconsistentports.

Na maioria dos casos, o motivo para a detecção da inconsistência de STP na porta é aparente:

• A porta de acesso recebe uma BPDU SSTP rotulada com IEEE 802.1Q.

  

  Neste cenário, a porta de acesso na ponte A recebe, da ponte B, um PVST+ BPDU marcado do STP de uma VLAN diferente de 1. A porta em A será colocada no estado inconsistente do tipo.

  Observação: os switches não precisam ser conectados diretamente; se estiverem conectados por meio de um ou mais switches IEEE 802.1D ou IEEE 802.1Q — ou mesmo hubs — o efeito é o mesmo.

• A porta de entroncamento IEEE 802.1Q recebe uma BPDU SSTP não rotulada com um tipo de VLAN, comprimento, valor (TLV) que não corresponde à VLAN onde a BPDU foi recebida.

  

  Neste cenário, a porta de tronco em A recebe um PVST+ BPDU do STP da VLAN 2 com uma marca da VLAN 2. Isso ativa a porta em A para ser bloqueada na VLAN 1 e na VLAN 2.

Se os dispositivos em ambas as extremidades de um link ponto-a-ponto são switches Cisco Catalyst, um exame da configuração de porta local e remota normalmente revela a incompatibilidade de configuração:

• A porta está configurada para entroncamento IEEE 802.1Q em um lado, mas o outro lado é a porta de acesso.

• Os troncos IEEE 802.1Q estão nos dois lados, mas as VLANs nativas são diferentes.

Nesses casos, corrija a incompatibilidade de configuração para resolver a inconsistência do STP.

Em alguns casos, pode não ser tão fácil identificar o motivo:

• Uma BPDU é recebida de uma mídia compartilhada com vários dispositivos.

• Uma BPDU é recebida da nuvem do switch, que implementa um modelo de STP IEEE 802.1D ou 802.1Q enquanto os switches PVST+ estão conectados à nuvem.

• Um BPDU vem por trás de algum túnel (por exemplo, nuvem do Data Link Switch Plus [DLSw+], tunelamento de protocolo L2, EoMPLS, Virtual Path Links [VPLs], Emulação de LAN [LANE] e outros).

Neste exemplo, o switch B está configurado incorretamente e injeta um BPDU SSTP na nuvem. Isso faz com que as portas nos switches A, C e D se tornem inconsistentes com o tipo. O problema é que o dispositivo que origina a BPDU "ofensiva" não está diretamente conectado aos switches afetados. Assim, com muitos dispositivos no tronco, pode ser demorado solucionar problemas de todos eles.

Felizmente, há uma abordagem sistemática para solucionar esse problema:

1. Estabeleça o endereço MAC de origem e o ID da ponte de envio da BPDU. Isso deve ser feito enquanto o problema estiver ocorrendo.

2. Encontre a ponte que origina a BPDU "ofensiva". Isso pode ser feito em algum momento posterior, não necessariamente quando o problema ocorrer.

Na Etapa 1, há normalmente duas opções: use um analisador de pacotes ou habilite a depuração para ver o despejo de BPDUs recebidos.

Para obter mais detalhes sobre o uso de um debug para despejar as BPDUs do STP, consulte a seção Comandos de Depuração do STP de Troubleshooting de STP em Catalyst Switch Executando o Cisco Integrated IOS (Modo Nativo).

Este é um exemplo de saída de depuração que mostra a BPDU recebida:

*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

Depois de saber o endereço MAC origem e o ID da bridge de envio, você precisa encontrar o dispositivo ao qual esse endereço MAC pertence. Isso pode ser complicado pelo fato de que os switches geralmente não aprendem os endereços MAC de uma origem dos quadros de BPDU. Se você executar o comando show mac-address-table address BPDU_mac_address (para switches baseados no Cisco IOS) ou o comando show cam mac_address (para switches baseados em CatOS), geralmente, não é encontrada nenhuma entrada.

Uma maneira de encontrar o endereço MAC "ofensivo" é coletar, de todos os switches conectados à nuvem, a saída do comando show spanning-tree (para o Cisco IOS) ou do comando show spantree (para CatOS). Essas saídas de comando incluem informações sobre o ID de cada ponte.

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.

Observação: dependendo do modelo, da versão do software e da configuração, um switch pode ter vários endereços MAC de ID de bridge. Felizmente, todos os endereços normalmente estarão em um certo intervalo (por exemplo, de 0001.1234.5600 a 0001.1234.5640). Se você souber um endereço MAC de ID de bridge, poderá verificar se o endereço MAC de ID de bridge de envio (encontrado na Etapa 1) está dentro do intervalo de endereços MAC de ID de bridge fornecidos.

Você também pode usar ferramentas de gerenciamento de rede para coletar as IDs de bridge de todas as bridges.

Depois de encontrar a ponte que está enviando a BPDU "ofensiva", você precisa verificar a configuração da porta que está se conectando à nuvem: certifique-se de que seja consistente (entroncamento em vez de não entroncamento e VLAN nativa) com outros switches que estão se conectando à mesma nuvem.

Pode acontecer que a bridge envie BPDUs adequados, mas eles estão sendo modificados incorretamente dentro da nuvem de tunelamento. Nesse caso, você pode ver que a BPDU "ofensiva" que entra na nuvem é consistente com a configuração de outras bridges, mas a mesma BPDU se torna inconsistente quando sai da nuvem (por exemplo, a BPDU sai da nuvem em uma VLAN diferente ou se torna marcada ou não). Nesse caso, pode ajudar a verificar se o endereço MAC origem da BPDU "ofensiva" pertence à mesma bridge que a ID da bridge de envio. Se esse não for o caso, você pode tentar localizar a bridge que possui o endereço MAC de origem da BPDU e verificar sua configuração.

Para localizar o switch que possui o endereço MAC de origem da BPDU, você pode seguir a mesma abordagem usada para localizar o ID da bridge, exceto que agora a saída do comando show module é inspecionada (para Catalyst 4000, 5000 e 6000). Para o Catalyst 2900 XL, 3500 XL, 2950 e 3550, você deve examinar a saída do comando show interface para ver os endereços MAC que pertencem às portas.

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.

Observação: se a nuvem for DLSw+, consulte Entendendo e Configurando DLSw e 802.1Q.

Informações Relacionadas

• Páginas de Suporte de Produtos de LAN
• Página de suporte da switching de LAN
• Suporte Técnico - Cisco Systems