Medida de pesquisa de defeitos - árvore PVID- e Tipo-inconsistências

Introdução

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; assim, o STP detecta determinados casos de configuração incorreta e a porta relevante é colocada em um estado "inconsistente".

Pode haver uns tipos diferentes de inconsistências de STP:

• Inconsistência do laço — Isto é detectado pela característica do protetor de loop. Para mais informação, refira a medida - realces do protocolo de árvore usando o protetor de loop e os recursos de detecção de desvio BPDU.

• Inconsistência da raiz — Isto é detectado pelos recursos de protetor de raiz. Para mais informação, refira a melhoria de protetor de raiz do Spanning Tree Protocol.

• Inconsistência de EtherChannel - Detectada pelo recurso de detecção de consistência EtherChannel. Para mais informação, refira compreendendo a detecção de inconsistência de EtherChannel.

• Inconsistência do vlan da porta ID (PVID) — Uma unidade de dados de protocolo de bridge (PDU) do Per-VLAN Spanning Tree (PVST+) é recebida em um VLAN diferente do que foi originada: (Má combinação ou *PVID_Inc do vlan da porta ID).

• Tipo inconsistência — UM PVST+ BPDU é recebido em um tronco non-802.1Q.

Esse documento explica como solucionar problemas causados pelas últimas duas inconsistências, PVID e tipo. Refira os documentos previamente mencionados para pesquisar defeitos outras inconsistências.

Pré-requisitos

Requisitos

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

Componentes Utilizados

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

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) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

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

Implementar PVST do Switches do Cisco catalyst usando troncos do Inter-Switch Link (ISL). Com o apoio do IEEE 802.1Q e do entroncamento ISL, uma maneira foi precisada para a interoperação entre o PVST e o conceito do IEEE 802.1Q de uma única medida - árvore para todos os VLAN. O recurso PVST+ foi introduzido para tratar desse requisito.

Nota: Do ponto de vista STP, o IEEE 802.1D não é VLAN ciente e o IEEE 802.1Q é o VLAN ciente, porém usa uma única instância STP para todas as VLANs. Isto é, se a porta está obstruindo então está obstruindo para todos os VLAN nessa porta. O mesmo é verdadeiro para enviar.

Esta lista mostra como interopera PVST+ com IEEE 802.1Q ou IEEE 802.1D, se o VLAN nativo em um tronco do IEEE 802.1Q é VLAN1:

• O VLAN1 STP BPDU é enviado ao MAC address da IEEE STP (0180.c200.0000), sem etiqueta.

• O VLAN1 STP BPDU é enviado igualmente ao MAC address PVST+, sem etiqueta.

• O NON-VLAN 1 STP BPDU é enviado ao MAC address PVST+ (igualmente chamado o MAC address compartilhado do [SSTP] do Spanning Tree Protocol, 0100.0ccc.cccd), etiquetou com uma etiqueta correspondente do IEEE 802.1Q VLAN.

Se o VLAN nativo em um tronco do IEEE 802.1Q não é VLAN1:

• O VLAN1 STP BPDU é enviado ao MAC address PVST+, etiquetado com uma etiqueta correspondente do IEEE 802.1Q VLAN.

• O VLAN1 STP BPDU é enviado igualmente ao MAC address da IEEE STP no VLAN nativo do tronco do IEEE 802.1Q, sem etiqueta.

• O NON-VLAN 1 STP BPDU é enviado ao MAC address PVST+, etiquetado com uma etiqueta correspondente do IEEE 802.1Q VLAN.

  Nota: O VLAN nativo STP BPDU é enviado a sem etiqueta.

Esta maneira, VLAN1 STP do PVST+ funde com o STP do IEEE 802.1D ou do 802.1Q, quando outros VLAN forem escavados um túnel através da nuvem do IEEE 802.1D ou das pontes do 802.1Q. Por exemplo, o IEEE 802.1D ou a nuvem do 802.1Q olham similar a um “fio” ao PVST+ VLAN diferentes de 1.

Para que o STP opere-se corretamente, observe determinadas regras quando você conecta pontes PVST+ ao IEEE 802.1D ou às pontes do 802.1Q. A regra principal é que as pontes PVST+ devem conectar ao IEEE 802.1D ou às pontes do 802.1Q através de um tronco do IEEE 802.1Q com um VLAN nativo consistente em todas as pontes que conectam à nuvem do IEEE 802.1Q ou das pontes 802.1D.

O PVST+ BPDU contém um número de VLAN que permita que as pontes PVST+ detectem se a regra precedente não está respeitada. Quando um Catalyst Switch detecta um misconfiguration, as portas correspondente estão postas “em um estado PVID-incompatível” ou “tipo-incompatível”, que obstrua eficazmente o tráfego no VLAN correspondente em uma porta correspondente. Estes estados impedem os loop de encaminhamento que configurações incorretas ou causa miswiring.

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

Se o BPDU da raiz no VLAN1 é melhor do que o BPDU da raiz no VLAN2 então lá não é nenhuma porta de bloqueio na topologia VLAN2. O BPDU do VLAN2 nunca faz “um círculo completo” em torno da topologia; é substituído pelo VLAN1 BPDU no link do B-C, porque B executa somente um STP fundido com o VLAN1 STP do PVST+. Assim, há um loop de encaminhamento. Felizmente, comute A envia PVST+ BPDU do VLAN2 (ao endereço SSTP que é inundado pelo interruptor B) para o interruptor C. Interruptor C porá CB da porta em um estado tipo-incompatível, que impeça o laço.

Nota: Em algumas saídas do comando, o estado *-inconsistent STP é referido como “quebrado.”

Quando a inconsistência de STP é detectada, o Switches envia estes mensagens do 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, o VLAN1 é o lugar onde o BPDU foi recebido, e o VLAN10 é o lugar onde o BPDU foi originado. Quando a inconsistência é detectada, ambos os VLAN estão obstruídos na porta onde este BPDU é recebido

Nota: As mensagens podem variar baseado no tipo e na versão o sistema operacional do OS de Cisco IOS® do software release ou do catalizador (Cactos) que está no uso.

Nota: Se a porta para de receber BPDU incompatíveis, o estado *-inconsistent está cancelado e o STP muda o estado de porta baseado na operação de STP normal. Um mensagem do syslog é enviado para indicar a mudança:

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

Para mais detalhes na operação PVST+, refira o Bridging entre IEEE 802.1Q vLANs.

Troubleshooting

Para considerar a lista de portas incompatíveis, a implementação de STP com base em IOS recente de Cisco apoia o comando show spanning-tree inconsistentports.

Na maioria de caso, a razão para a detecção de inconsistência de STP na porta é aparente:

• A porta de acesso recebe uma IEEE 802.1Q-tagged SSTP BPDU.

  

  Nesta encenação, a porta de acesso na ponte A recebe, da ponte B, um PVST+ etiquetado BPDU do STP de um VLAN a não ser 1. A porta em A será posta no estado tipo-incompatível.

  Nota: O Switches não precisa de ser conectado diretamente; se estão conectados com um ou vário IEEE 802.1D ou o IEEE 802.1Q comuta — ou mesmo Hubs — então o efeito é o mesmo.

• A porta de entroncamento do IEEE 802.1Q recebe um sem etiqueta SSTP BPDU com um tipo VLAN, comprimento, o valor (TLV) que não combina o VLAN onde o BPDU foi recebido.

  

  Nesta encenação, a porta de tronco em A recebe um PVST+ BPDU do STP do VLAN2 com uma etiqueta do VLAN2. Isto provoca a porta em à ser obstruído no VLAN1 e no VLAN2.

Se os dispositivos no ambas as extremidades de um link de ponto a ponto são Switches do Cisco catalyst, um exame da configuração do local e da porta remota revela tipicamente o mau combinação da configuração:

• A porta é configurada para o entroncamento do IEEE 802.1Q em um lado mas o outro lado é porta de acesso.

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

Nesses casos, fixe o mau combinação da configuração para resolver a inconsistência de STP.

Em alguns casos, pôde ser não como fácil identificar a razão:

• Um BPDU é recebido do meios compartilhados com dispositivos múltiplos.

• Um BPDU é recebido, da nuvem do interruptor, que executa um modelo do IEEE 802.1D ou do 802.1Q STP quando o Switches PVST+ for conectado à nuvem.

• Um BPDU vem de trás algum túnel (por exemplo, switch de link de dados mais a nuvem do [DLSw+], Tunelamento do protocolo L2, [VPLs] de EoMPLS, de links de caminho virtual, [LANE] do LAN Emulation, e outro).

Neste exemplo, o switch B é desconfigurado e injeta um SSTP BPDU na nuvem. Isto causa as portas no comuta A, C, e D para tornar-se tipo-incompatível. A edição é que o dispositivo que origina o BPDU “de ofensa” não está conectado diretamente ao Switches afetado. Assim, com muitos dispositivos no tronco, pôde tornar-se demorada para pesquisar defeitos todo.

Felizmente, há uma aproximação sistemática para pesquisar defeitos esta edição:

1. Estabeleça o endereço MAC de origem e o ID da ponte de envio da BPDU. Isto deve ser feito quando a edição ocorrer.

2. Encontre a ponte que origina o BPDU “de ofensa”. Isto pode ser feito em algum um tempo mais atrasado, não necessariamente quando a edição ocorre.

Para etapa 1, há normalmente duas opções: use um analisador de pacote ou permita-o debugam para ver a descarga de BPDU recebidos.

Para mais detalhes sobre o uso debugar despejar STP BPDU, refira a seção de comandos debugging STP de pesquisar defeitos o STP no Catalyst Switch que executa IO integrados Cisco (modo nativo).

Este é um exemplo do resultado do debug que mostra o BPDU recebido:

*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 que você conhece o endereço MAC de origem e ID de bridge da emissão, você precisa de encontrar o dispositivo a que este MAC address pertence. Isto pode ser complicado pelo fato de que o Switches tipicamente não aprende endereços MAC de uma fonte dos quadros BPDU. Se você emite o comando show mac-address-table address BPDU_mac_address (para switch baseado em IOS Cisco) ou o comando show cam mac_address (para switch com base em Cactos) então, tipicamente, nenhuma entrada está encontrada.

Uma maneira de encontrar o MAC address “de ofensa” é recolher, de todo o Switches que é conectado à nuvem, à saída da medir-árvore da mostra (para o Cisco IOS) ou ao comando do spantree da mostra (para Cactos). 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.

Nota: Segundo o modelo, a versão de software, e a configuração, um interruptor pode ter endereços múltiplos do ID de bridge MAC. Felizmente, todos os endereços estarão tipicamente em alguma escala (por exemplo, 0001.1234.5600 a 0001.1234.5640). Se você conhece um MAC address do ID de bridge então você pode verificar se o MAC address de emissão do ID de bridge (encontrado em etapa 1) caia dentro da escala de endereços dados do ID de bridge MAC.

Você pode igualmente usar ferramentas de gerenciamento da rede para recolher os ID de bridge de todas as pontes.

Uma vez que você encontrou a ponte que está enviando o BPDU “de ofensa”, você precisa de verificar a configuração da porta que está anexando à nuvem: assegure-se de que esteja consistente (entroncamento ao contrário do NON-entroncamento e do VLAN nativo) com o outro Switches que está conectando à mesma nuvem.

Poderia acontecer que a ponte envia BPDU apropriados, mas estão obtendo incorretamente alteraram dentro da nuvem do Tunelamento. Nesse caso, você pode ver que o BPDU “de ofensa” que entra na nuvem é consistente com a configuração das outras pontes, mas o mesmo BPDU torna-se incompatível quando retira a nuvem (por exemplo, o BPDU retira a nuvem em um VLAN diferente, ou se torna etiquetado ou sem etiqueta). Em tal caso, pode ajudar a verificar se o endereço MAC de origem do BPDU “de ofensa” pertença à mesma ponte que o ID de bridge de emissão. Se tal não for o caso então você pode tentar encontrar a ponte que possui o endereço MAC de origem do BPDU e verifica sua configuração.

Para encontrar o interruptor que possui o endereço MAC de origem do BPDU, você pode seguir a mesma aproximação que é usada para encontrar o ID de bridge, exceto agora o comando show module que a saída é inspecionada (para o Catalyst 4000, 5000, and 6000). Para o Catalyst 2900xl, 3500xl, 2950 e 3550, você deve examinar a saída do comando show interface 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.

Nota: Se a nuvem é DLSw+, refira a compreensão e configurar de DLSw e de 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