Switches de LAN : Spanning Tree Protocol

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

1 Julho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (1 Setembro 2005) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
Teoria de Apoio sobre Inconsistências de PVID e de Tipo
Troubleshooting
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Nas redes da Camada 2 (L2), só pode haver um caminho entre dois dispositivos. Há suporte para a redundância com o STP (Spanning-Tree Protocol), o qual detecta e bloqueia caminhos redundantes evitando, dessa maneira, loops de encaminhamento. Certas configurações erradas podem resultar em falha do STP e queda da rede. Para evitar que haja um tempo de inatividade, algumas melhorias foram implementadas, de modo que o STP detecte certos casos de erro de configuração e a porta relevante seja colocada no estado “inconsistent”.

Podem existir diferentes tipos de inconsistências de STP:

Este documento explica como fazer o troubleshooting da causa das duas últimas inconsistências, de PVID e de tipo. Consulte os documentos mencionados anteriormente para fazer o troubleshooting de outras inconsistências.

Pré-requisitos

Requisitos

Os leitores deste documento devem ter conhecimento de conceitos de STP.

Componentes Utilizados

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

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração padrão. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documentos, consulte as Convenções de Dicas Técnicas da Cisco.

Teoria de Apoio sobre Inconsistências de PVID e de Tipo

Os Cisco Catalyst Switches implementam o PVST utilizando troncos ISL (Inter-Switch Link). Com o suporte ao entroncamento IEEE 802.1Q e ISL, tornou-se necessário uma forma de permitir a interoperação entre o PVST e o conceito do IEEE 802.1Q de spanning tree única para todas as VLANs. O recurso PVST+ foi introduzido para atender a essa necessidade.

Nota: Do ponto de vista do STP, o IEEE 802.1D não reconhece VLANs e o IEEE 802.1Q as reconhece, porém, ele utiliza uma única instância do STP para todas as VLANs. Ou seja, se a porta for de bloqueio, este se aplicará a todas as VLANs nessa porta. O mesmo se aplica ao encaminhamento.

Esta lista mostra como o PVST+ interoperará com o IEEE 802.1Q ou o IEEE 802.1D se a VLAN Nativa em um tronco IEEE 802.1Q for a VLAN 1:

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

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

  • As BPDUs STP não pertencentes à VLAN 1 serão enviadas ao endereço MAC do PVST+ (também denominado endereço MAC do SSTP [Shared Spanning Tree Protocol], 0100.0ccc.cccd), com uma marca IEEE 802.1Q VLAN correspondente.

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

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

  • As BPDUs STP da VLAN 1 também serão enviadas ao endereço MAC do STP IEEE na VLAN Nativa do tronco IEEE 802.1Q, sem marca.

  • As BPDUs STP não pertencentes à VLAN 1 serão enviadas ao endereço MAC do PVST+, com uma marca IEEE 802.1Q VLAN correspondente.

    Nota: As BPDUs STP da VLAN Nativa são enviadas sem marca.

Dessa maneira, o STP do PVST+ da VLAN 1 é mesclado com o STP do IEEE 802.1D ou do IEEE 802.1Q, enquanto ocorre o tunelamento de outras VLANs através da nuvem de bridges IEEE 802.1D ou IEEE 802.1Q. Por exemplo, a nuvem IEEE 802.1D ou IEEE 802.1Q é semelhante a um “fio” para as VLANs PVST+ diferentes de 1.

Para que o STP funcione corretamente, observe certas regras ao conectar bridges PVST+ a bridges IEEE 802.1D ou IEEE 802.1Q. A regra principal é que as bridges PVST+ devem se conectar às bridges IEEE 802.1D ou IEEE 802.1Q por meio de um tronco IEEE 802.1Q com uma VLAN Nativa consistente em todas as bridges que estiverem conectadas à nuvem de bridges IEEE 802.1Q ou IEEE 802.1D.

A BPDU PVST+ contém um número de VLAN que permite às bridges PVST+ detectar se a regra anterior foi ou não respeitada. Quando um Catalyst switch detecta um erro de configuração, as portas correspondentes são colocadas no estado “PVID-inconsistent” ou “type-inconsistent”, o qual bloqueia efetivamente o tráfego da VLAN correspondente em uma porta correspondente. Esses estados evitam os loops de encaminhamento ocasionados por erros de configuração ou de cabeamento.

Para ilustrar por que é necessária a detecção de inconsistência, considere a topologia a seguir, em que os switches A e C estão executando o STP PVST+ e o switch B está executando o STP 802.1Q:

pvid_inconsistency_24063a.gif

Se a BPDU da raiz na VLAN 1 for melhor que a BPDU da raiz na VLAN 2, não haverá uma porta de bloqueio na topologia da VLAN2. A BPDU da VLAN 2 nunca faz um “círculo completo” em torno da topologia; ela é substituída pela BPDU da VLAN 1 no link B-C, porque B executa apenas um STP mesclado com o STP do PVST+ da VLAN1. Portanto, não há um loop de encaminhamento. Felizmente, o switch A envia BPDUs PVST+ da VLAN 2 (para o endereço SSTP inundado pelo switch B) ao switch C, o qual colocará a porta C-B no estado de inconsistência de tipo, impedindo o loop.

Nota: Em algumas saídas de comando, o estado "*-inconsistent" do STP é designado como "broken".

Quando uma inconsistência do 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 BPDU foi recebida na VLAN 1 e originada na VLAN 10. Quando uma inconsistência é detectada, as duas VLANs são bloqueadas na porta em que essa BPDU é recebida.

Nota: As mensagens poderão variar com base no tipo e na versão do sistema operacional Cisco IOS® Software Release ou Catalyst OS (CatOS) em uso.

Nota: Se a porta parar de receber BPDUs inconsistentes, o estado "*-inconsistent" será limpo, e o STP alterará o estado da porta com base em sua operação normal. Uma mensagem de syslog será 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 Formação de Bridges Entre VLANs IEEE 802.1Q.

Troubleshooting

Para ver a lista de portas inconsistentes, a implementação recente de STP baseada no Cisco IOS oferece suporte ao 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 com a marca IEEE 802.1Q.

    pvid_inconsistency_24063b.gif

    Nesse cenário, a porta de acesso na bridge A recebe, da bridge B, uma BPDU PVST+ marcada a partir do STP de uma VLAN diferente da 1. A porta da bridge A será colocada no estado de inconsistência de tipo.

    Nota: Os switches não precisam estar conectados diretamente; se eles estiverem conectados por meio de um ou mais switches IEEE 802.1D ou IEEE 802.1Q, ou até mesmo de hubs, o resultado será o mesmo.

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

    pvid_inconsistency_24063c.gif

    Nesse cenário, a porta de tronco em A recebe uma BPDU PVST+ do STP da VLAN 2 com uma marca da VLAN 2. Isso dispara o bloqueio dessa porta nas VLANs 1 e 2.

Se os dispositivos em ambas as extremidades de um link ponto a ponto forem Cisco Catalyst Switches, um exame da configuração de porta local e remota geralmente revelará o erro de configuração:

  • A porta é configurada para entroncamento IEEE 802.1Q em um lado, mas, do outro, há uma porta de acesso.

  • Existem troncos IEEE 802.1Q nos dois lados, mas as VLANs Nativas são diferentes.

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

Em alguns casos, talvez não seja tão fácil identificar o motivo:

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

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

  • Uma BPDU é originada atrás de um túnel (por exemplo, nuvem DLSw+ [Data Link Switch Plus], tunelamento de protocolo L2, EoMPLS, VPLs [Virtual Path Links], LANE [LAN Emulation] e outros).

pvid_inconsistency_24063d.gif

Nesse exemplo, o switch B está configurado de forma errada e insere uma BPDU SSTP na nuvem. Isso faz com que as portas nos switches A, C e D tornem-se inconsistentes em termos de tipo. A questão é que o dispositivo que origina a BPDU responsável pelo problema não está conectado diretamente aos switches afetados. Assim, quando há muitos dispositivos no tronco, o troubleshooting de todos eles poderá ser muito demorado.

Felizmente, há uma abordagem sistemática para fazer o troubleshooting desse problema:

  1. Estabeleça o endereço MAC de origem e o ID da bridge de envio da BPDU. Esse procedimento deverá ser executado enquanto o problema estiver ocorrendo.

  2. Localize a bridge que origina a BPDU responsável pelo problema. Esse passo poderá ser executado em algum momento posterior e não necessariamente quando o problema ocorre.

Para o Passo 1, há normalmente duas opções: utilizar um analisador de pacotes ou ativar a depuração para ver o dump das BPDUs recebidas.

Para obter mais detalhes sobre o uso de uma depuração para obter um dump de BPDUs STP, consulte a seção Comandos de Depuração do STP do documento Troubleshooting do STP em um Catalyst Switch que Executa o Cisco Integrated IOS (Modo Nativo).

Este é um exemplo de saída de depuração que mostra uma 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

Uma vez conhecidos o endereço MAC de origem e o ID da bridge de envio, será necessário encontrar o dispositivo ao qual esse endereço MAC pertence. Isso poderá ser complicado uma vez que os switches geralmente não aprendem os endereços MAC de uma origem a partir de frames 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 no CatOS), normalmente nenhuma entrada será encontrada.

Uma forma de encontrar o endereço MAC que ocasionou o problema é coletar, de todos os switches conectados à nuvem, a saída do comando show spanning-tree (no Cisco IOS) ou do comando show spantree (no CatOS). Essas saídas de comando incluem informações sobre o ID de cada bridge.

Boris# show spanning-tree

!--- Use com o 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

!--- Saída suprimida.

Doris (enable) show spantree

!--- Use com o 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

!--- Saída suprimida.

Nota: Dependendo do modelo, da versão do software e da configuração, um switch poderá ter diversos endereços MAC de ID de bridge. Felizmente, em geral, todos os endereços estarão dentro de determinado 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 do ID de bridge de envio (encontrado no Passo 1) está dentro do intervalo de endereços MAC de ID de bridge especificado.

Também é possível utilizar ferramentas de gerenciamento de rede para coletar os IDs de todas as bridges.

Quando descobrir a bridge que está enviando a BPDU responsável pelo problema, você precisará verificar a configuração da porta conectada à nuvem: certifique-se de que ela é consistente (entroncamento em oposição a não entroncamento e VLAN Nativa) com outros switches conectados à mesma nuvem.

É possível que a bridge envie as BPDUs adequadas, mas elas estejam sendo modificadas de forma incorreta na nuvem de tunelamento. Nesse caso, você poderá observar que a BPDU responsável pelo problema e que entra na nuvem é consistente com a configuração das outras bridges; contudo, a mesma BPDU torna-se inconsistente ao sair da nuvem (por exemplo, ela sai da nuvem em outra VLAN ou torna-se marcada ou desmarcada). Nesse caso, poderá ser útil verificar se o endereço MAC de origem dessa BPDU pertence à mesma bridge que o ID da bridge de envio. Se esse não for o caso, você poderá 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ê poderá seguir a mesma abordagem utilizada para encontrar o ID da bridge, porém, agora a saída do comando show module será inspecionada (para os Catalyst 4000, 5000 e 6000). Nos Catalyst 2900 XL, 3500 XL, 2950 e 3550, será necessário examinar a saída do comando show interface para ver os endereços MAC pertencentes às portas.

Cat4000-IOS# show module

!--- Use para o 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

!--- Saída suprimida.

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)

!--- Saída suprimida.

Nota: Se a nuvem for DLSw+, consulte Entendendo e Configurando DLSw e 802.1Q.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 24063