Identificar e Solucionar Problemas de Loops de Camada 2 nos Catalyst 9000 Series Switches

Introdução

Este documento descreve como identificar e solucionar problemas de loops de camada 2 em redes que incluem switches da série Catalyst 9000. 

Pré-requisitos

Recomenda-se que você compreenda os conceitos do protocolo spanning-tree. 

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 rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Os loops de Camada 2 causam o havok em uma rede local. A "tempestade de broadcasts" resultante interfere na comunicação dentro das LANs virtuais (VLANs) afetadas e congela os endpoints e os dispositivos de rede. O problema ganha força com o tempo, pois o tráfego da camada 2 não tem nenhum mecanismo, como o Time-to-live (TTL), que eventualmente faz com que um pacote seja consumido na rede. O tráfego em loop, como ARP (Address Resolution Protocol) ou DHCP (Dynamic Host Configuration Protocol), em vez disso, faz um loop infinito até que o loop seja interrompido. Um indivíduo responsável pela investigação de um loop ativo encontra-se em uma posição estressante.

Felizmente, existem métodos testados e verdadeiros para investigar e solucionar problemas de loops de camada 2. Este documento descreve a metodologia usada por gerações de engenheiros do TAC. 

Spanning-Tree: como ele evita loops?

Essa topologia simples mostra o protocolo spanning-tree em ação. Estes pontos são verdadeiros para esta topologia:

• Todos os links neste exemplo têm a mesma largura de banda.
• D/F significa Designated (a função da porta) Forwarding (o estado da porta).
• R/F significa Root (a função da porta) Forwarding (o estado da porta).
• A/B significa Alternate (the port role) Blocking (the port state) (Bloqueio alternativo (a função da porta)).
• A eleição da bridge raiz resultou na escolha do switch identificado como bridge raiz. Todas as interfaces na bridge raiz estão na função 'designated' e no estado 'forwarding'.
• A porta raiz para os switches AAAA e BBB é a porta que conecta cada switch diretamente à bridge raiz.
• No link que conecta o AAAA ao BBB, a porta designada pertence ao AAAA em virtude do MAC da ponte. 
• No link que conecta o AAAA ao BBB, a porta de bloqueio pertence ao BBB em virtude do MAC da bridge.

O spanning-tree convergiu nessa topologia para evitar loops.  As setas verdes representam como um pacote de broadcast transmitido por um PC cliente seria encaminhado nos switches interconectados. A porta de bloqueio no BBB impede que o broadcast transmitido pelo cliente faça looping indefinido entre os dispositivos.

Como se formam as tempestades de broadcast da camada 2?

Há muitos cenários em que a prevenção de loop proporcionada pelo spanning-tree não impede uma tempestade de broadcast.  

Problemas físicos (camada 1) na rede podem resultar em links unidirecionais, impedindo que os alto-falantes spanning-tree troquem BPDUs de forma confiável. O recebimento ou a entrega não confiável de BPDUs causam a convergência indesejada e inesperada de spanning-tree.

Exemplo 1:

Neste cenário, o BBB pára de receber BPDUs da bridge raiz em sua porta raiz. O BBBB converge em resposta a essa perda de BPDUs. Sua porta raiz não é mais um caminho viável para a raiz, pois não recebe mais BPDUs e torna-se uma porta designada. Sua porta de bloqueio continua a receber BPDUs de AAAA e torna-se a porta raiz. Nenhuma das interfaces é bloqueada, o que resulta em um loop.

O link unidirecional faz com que o Spanning-Tree convirja inesperadamente

Exemplo 2:

As interrupções de rede também podem ocorrer quando o spanning-tree é convergido como esperado.  Determinados dispositivos conectados à rede podem ser vetores para loops. Um hub ou dispositivo similar conectado inesperadamente à rede pode resultar em tempestades de broadcast.

Hub conectado à rede resulta em tempestade de broadcast

Troubleshooting

Há muitas maneiras pelas quais os engenheiros de rede tendem a se aproximar de loops de camada 2 e de tempestades de broadcast. Esta seção descreve um método testado e comprovado que foi testado em inúmeros casos de TAC e interrupções catastróficas.

Esse método aproveita comandos muito básicos e evita pontos de dados, como as TCNs (Notificações de Alteração de Topologia) do STP (Protocolo de Árvore de Abrangência), que podem ser caóticos de perseguir. Os TCNs em uma topologia de STP Rápido (RSTP) ocorrem quando as portas não borda são movidas para ENCAMINHAMENTO a partir de BLOQUEIO. O loop em si pode sobrecarregar os alto-falantes STP até o ponto em que eles não podem participar previsivelmente da convergência. As interfaces nos switches vitimizados são movidas para FORWARDING se não puderem processar corretamente BPDUs de entrada devido ao seu plano de controle congestionado. Os TCNs são frequentemente sintomas que revelam dispositivos vitimizados, mas não necessariamente para a origem do loop.

Em vez de TCNs de STP, um ponto de dados mais válido e linear a ser considerado são as taxas de entrada de interface.  As interfaces que participam do loop mostram taxas de entrada muito mais altas do que o esperado. As taxas de saída não são tão preocupantes, já que esses dispositivos downstream provavelmente são as próprias vítimas. Você também pode observar uma alta taxa de broadcast e multicast nas interfaces afetadas e observar que o tamanho médio do pacote oscila para um valor menor que o esperado.

Com apenas esses comandos, um engenheiro de rede pode isolar a maioria, se não todos, os loops de camada 2 de uma maneira direta:

• show interfaces | include is up|taxa de entrada

• show cdp neighbors <interface> OR show lldp neighbors <interface>
• show spanning-tree

O comando "show interfaces | include is up|input rate" com o pipe e os argumentos nos fornece um trecho de saída rapidamente digestível. Ela mostra todas as nossas interfaces que estão atualmente "ativadas", bem como suas taxas de entrada. Para os nossos propósitos, nos preocupamos apenas com as taxas de entrada. Interfaces com taxas de entrada inesperadamente altas provavelmente serão vítimas do loop. O dispositivo conectado a uma interface com uma taxa de entrada inesperadamente alta provavelmente está mais próximo da origem do loop.  Interfaces com taxas de saída inesperadamente altas provavelmente nos levam para longe da origem do loop.

ACCESS-SWITCH1#show interfaces | in is up|input rate
<snip>
GigabitEthernet1/0/1 is up, line protocol is up (connected) <----- Typical endpoint with a low input rate. This would not raise suspiscion.
  5 minute input rate 33000 bits/sec, 21 packets/sec
GigabitEthernet1/0/2 is up, line protocol is up (connected)
  5 minute input rate 24000 bits/sec, 11 packets/sec
<snip>
  5 minute input rate 0 bits/sec, 0 packets/sec            <----- This output represents interfaces that are down.
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
TwentyFiveGigE1/1/1 is up, line protocol is up (connected) <----- Twe1/1/1 in this scenario is high-bandwith uplink interface. We would expect uplinks to have a fair amount of traffic on input.
  5 minute input rate 2816922000 bits/sec, 2072252 packets/sec.    If we were troubleshooting a loop, pay special attention to this interface given the input rate.
TwentyFiveGigE1/1/2 is up, line protocol is up (connected)
    5 minute input rate 2926942401 bits/sec, 3043467 packets/sec <-- The same logic goes for this port. The input rate is relatively high but that is possibly function of its position in the network.
TwentyFiveGigE1/1/3 is up, line protocol is up (connected)
      5 minute input rate 0 bits/sec, 0 packets/sec
<snip>

• show cdp neighbors <interface> OR show lldp neighbors <interface>

ACCESS-SWITCH1#show cdp neighbor twe1/1/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
ACCESS-SWITCH2           Twe 1/1/1         142              S I   C9300-48P Twe 1/1/4 <--- We confirm that the expected neighbor is attached to this interface.

Total cdp entries displayed : 1

• show spanning-tree

Use este comando para entender como o switch local acredita que o spanning-tree está convergido.  Tenha em mente as diferenças nos vários sabores de spanning-tree. Os switches Catalyst executam Rapid-PVST por padrão, mas oferecem suporte a PVST e MST.

ACCESS-SWITCH1#show spanning-tree  

VLAN0001                                  <----- Keep in mind that in per-vlan spanning-tree, each VLAN represents a unique instance of spanning-tree
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             Cost        2000
             Port        3 (TwentyFiveGigE1/0/3)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     b08b.d08d.6b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gig1/0/1            Desg FWD 20000     128.1    P2p
Gig1/0/2            Desg FWD 20000     128.2    P2p
<snip>
Twe1/1/1            Root FWD 800       128.33   P2p
Twe1/1/2            Desg FWD 800       128.34   P2p
Twe1/1/3            Alt  BLK 800       128.35   P2p <---- This output corresponds with expectation. This step helps to populate STP information in your topology as you move from device to device

Esse método simples e direto evita capturas de pacotes demoradas, elimina o foco em TCNs de spanning-tree e mantém o problema real na vanguarda da investigação. Ele também elimina a solução de problemas de "adivinhação e verificação".

Considere este diagrama de topologia:

Caminho de broadcast do cliente na topologia convergente

A árvore de abrangência bloqueia várias portas nessa topologia devido às interconexões redundantes entre os switches. Para este exemplo, o gráfico X amarelo representa as portas de bloqueio. As portas de encaminhamento são todas designadas ou raiz, dependendo da localização do switch local em comparação com a bridge raiz.  As setas verdes representam o fluxo normal e esperado de tráfego de broadcast que um exemplo de cliente enviaria nessa rede.

Embora não seja muito complexa, essa rede oferece muitas oportunidades para a formação de loops devido aos muitos links redundantes.  

Este fragmento da topologia maior concentra-se nas funções/estados de spanning-tree do switch de acesso onde o servidor se conecta.

Trabalhando a convergência de árvore de abrangência

Considere se tivemos um link unidirecional que impede que o switch de acesso downstream receba BPDUs em sua porta raiz. O spanning-tree reconverge em resposta, e um loop de camada 2 se segue.

A porta raiz anterior no ACCESS-C para de receber BPDUs de DISTRO-B. O switch não o reconhece mais como um caminho viável para a raiz, de modo que a porta de bloqueio de prioridade mais alta se torne ROOT/FORWARDING. A porta raiz anterior faz a transição para DESIGNATED/FORWARDING. Essa reconvergência resulta em um loop de encaminhamento.

Este diagrama mostra como o loop afeta o tráfego de broadcast enviado de nosso cliente.  A menos que o loop seja interrompido, o tráfego em loop continua a efetuar loop indefinidamente e possivelmente ingressar/sair de um switch afetado em várias interfaces. Você pode ver várias setas vermelhas que representam a direção do tráfego em loop. 

O problema continua a ganhar força à medida que mais e mais tráfego é infinitamente em loop. A família de switches Catalyst 9000 utiliza um mecanismo robusto de policiamento de plano de controle (CoPP) por padrão, mas alguns produtos não. Os switches com uma interface virtual do switch (SVI) local em uma VLAN em loop têm uma cópia do tráfego de broadcast dentro dessa VLAN apontada para a CPU. Sem CoPP, todo esse tráfego pontilhado pode interromper a CPU do switch. Isso tende a piorar uma situação ruim, pois os switches vitimizados não podem participar do spanning-tree como esperado.

Metologia

Um dos desafios iniciais enfrentados quando solucionamos esse tipo de problema é determinar por onde começar.  Em última análise, a posição em que começamos não é muito importante.  Todos os dispositivos afetados pelo loop são rastreados até a origem do loop.

Neste exemplo, começamos no switch onde o cliente afetado se conecta.

Ponto de partida - ACESSO-A - Conectado diretamente ao cliente

Esse método torna o ponto inicial irrelevante.  Todas as interfaces afetadas apontam para a origem do problema. Onde quer que você comece, se esse processo for seguido, você chegará à origem do loop/reflexão. Neste cenário, o cliente afetado se conecta ao switch ACCESS-A. É aqui que começamos. A primeira etapa nesse processo é considerar as taxas de entrada em todas as interfaces ativas.

• show interfaces | include is up|taxa de entrada

ACCESS-A#show interfaces | in is up|input rate

GigabitEthernet1/0/1 is up, line protocol is up (connected) 
  5 minute input rate 33000 bits/sec, 21 packets/sec          <--- This access port (downlink) has a small volume of traffic inbound. This does not raise suspiscion. 
<snip>
  5 minute input rate 0 bits/sec, 0 packets/sec            
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
TwentyFiveGigE1/1/1 is up, line protocol is up (connected)
  5 minute input rate 2816922000 bits/sec, 2672252 packets/sec <--- This port is an uplink. There is a fair amount of traffic inbound on this port, but also keep in mind that the uplink is expected to be busier.  
TwentyFiveGigE1/1/2 is up, line protocol is up (connected) <--- This is our other uplink on this switch. The input rate is zero, suggesting the other end of this link is not transmitting. This implies that the other end of the link successfully blocks.
    5 minute input rate 0 bits/sec, 0 packets/sec 

O tamanho médio do pacote é calculado dividindo-se bytes por segundo por pacotes por segundo. Neste exemplo, o tamanho médio do pacote é de cerca de 132 bytes. Isso sugere um alto volume de pequenos pacotes que distorce a média. Um alto volume de ARP, por exemplo, pode causar o mesmo desvio do tamanho médio de pacote esperado em uma rede de produção e sugere que a porta seja vitimizada pela tempestade de broadcast.

Nenhum dos downlinks mostra taxas de entrada anormais. A única porta potencialmente afetada é a porta raiz - o uplink em direção à camada de distribuição. Antes de passarmos para o próximo dispositivo, considere primeiro o spanning-tree para o switch.

• show spanning tree 

ACCESS-A#show spanning-tree  <--- Without an argument, this command gives spanning-tree information for all VLANs with an active STP instance running. For this example, we assume VLAN 1 is consistent with all VLANs on the trunk.

VLAN0001                                  
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             Cost        2000
             Port        3 (TwentyFiveGigE1/1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     b08b.d08d.6b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gig1/0/1            Desg FWD 20000     128.1    P2p
Gig1/0/2            Desg FWD 20000     128.2    P2p
<snip>
Twe1/1/1            Root FWD 800       128.33   P2p
Twe1/1/2            Desg FWD 800       128.34   P2p

<snip>

Aqui é onde vale a pena conhecer sua rede e como se espera que o spanning-tree convirja. Te1/1/1 é a porta raiz esperada. Twe1/1/2 também se conecta a um switch e encaminha, mas sua taxa de entrada é de 0 pacote/s, portanto sabemos que a outra extremidade do link é bloqueada com êxito. Tudo parece bem com relação ao spanning-tree. Agora, confirmamos o peer do link na porta afetada.

• show cdp neighbor <interface>

ACCESS-A#show cdp neighbors twentyFiveGigE 1/1/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
DISTRO-A         Twe 1/1/1        137        S I         C9300-48P Twe 1/0/3

Switch Next-Hop - DISTRO-A

DISTRO-A

A próxima etapa é uma repetição da atividade anterior no switch que se conecta à interface suspeita.  Execute "show interfaces | include is up|input rate" para identificar interfaces com taxas de entrada suspensivamente altas.

• show interfaces | include is up|taxa de entrada

DISTRO-A#show interfaces | in is up|input rate       

  5 minute input rate 0 bits/sec, 0 packets/sec            
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
TwentyFiveGigE1/1/1 is up, line protocol is up (connected)
  5 minute input rate 4846092202 bits/sec, 4572251 packets/sec   <-- In this scenario, this input rate raises red flags. This is another situation where understanding normal baselines is helpful.
TwentyFiveGigE1/1/2 is up, line protocol is up (connected) 
  5 minute input rate 0 bits/sec, 0 packets/sec                  <-- The other end of this link is likely blocking.
TwentyFiveGigE1/1/3 is up, line protocol is up (connected) 
  5 minute input rate 146192134 bits/sec, 171252 packets/sec     <-- Fair amount of usage, though exponentially smaller that our 'suspect' link. Again, knowing expected baselines is helpful to identify when deviations occur. This is a downlink towards an access switch in this scenario, and does not raise red flags.
TwentyFiveGigE1/1/4 is up, line protocol is up (connected) 
  5 minute input rate 4938392202 bits/sec, 4723294 packets/sec   <-- This is along the same magnitude of input as Twe1/1/1. Often, interfaces impacted by the same broadcast storm shows similar activity. In our scenario, this interface raises red flags.
TwentyFiveGigE1/1/5 is up, line protocol is up (connected) 
  5 minute input rate 032182156 bits/sec, 104263 packets/sec     <-- Similar to Twe1/1/3, this interface is active but not at a suspicious level.

No DISTRO-A, encontramos duas interfaces com taxas de entrada maiores que a expectativa. A natureza dos loops significa que normalmente há vários caminhos até a origem.  Observamos as duas interfaces, mas primeiro verificamos o spanning-tree para qualquer coisa fora do padrão.

• show spanning-tree 

DISTRO-A#show spanning-tree

VLAN0001                                  
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             Cost        2000
             Port        3 (TwentyFiveGigE1/1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     c18b.a18d.5b76
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Twe1/1/1            Root FWD 800       128.33   P2p
Twe1/1/2            Desg FWD 800       128.34   P2p
Twe1/1/3            Desg FWD 800       128.35   P2p
Twe1/1/4            Desg FWD 800       128.36   P2p
Twe1/1/5            Desg FWD 800       128.37   P2p
<snip>

Se você observar a posição do DISTRO-A na rede, poderá ver que todas as portas neste switch devem encaminhar. Ele tem uma porta raiz (Twe1/1/1) que a conecta diretamente ao bridge raiz. Todos os seus downlinks e interconexões com outros switches são designados e encaminhados. Isso acompanha nossa saída spanning-tree.

Agora, verificamos os colegas em nossas interfaces suspeitas e decidimos para onde ir em seguida.  Qualquer direção resulta em nossa chegada à origem do loop.

• show cdp neighbors <interface>

DISTRO-A#show cdp neighbors twentyFiveGigE 1/1/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
CORE             Twe 1/1/1       137        S I         C9500-48Y4C Twe 1/0/1

DISTRO-A#show cdp neighbors twentyFiveGigE 1/1/4
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
ACCESS-B         Twe 1/1/4        137        S I         C9300-48P Twe 1/1/1

Primeiro, verificamos o CORE, mas ele seria igualmente válido neste cenário quando se muda para o ACCESS-B.

Switch Next-Hop - CORE

• show interfaces | include is up|taxa de entrada

CORE#show interfaces | in is up|input rate       
TwentyFiveGigE1/0/1 is up, line protocol is up (connected)     <--- Both active downlinks have comparably high input rates. It is not unexpected for core devices to have high interface activity. 
  5 minute input rate 4946092202 bits/sec, 4671352 packets/sec 
TwentyFiveGigE1/0/2 is up, line protocol is up (connected)
  5 minute input rate 4936092202 bits/sec, 4474252 packets/sec <--- It appears that both Twe1/0/1 and Twe1/0/2 are victimized. These are the only active downlinks, so this makes sense.
  <snip>
    5 minute input rate 0 bits/sec, 0 packets/sec            
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec

Como esse switch é a bridge raiz, esperaríamos que todas as suas interfaces encaminhassem. Confirme rapidamente com "show spanning-tree".

CORE#show spanning-tree

VLAN0001
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    1      (priority 0 sys-id-ext 1)
             Address     380e.4d77.4800
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Twe1/0/1            Desg FWD 800       128.25   P2p
Twe1/0/2            Desg FWD 800       128.26   P2p

Não há caminhos inesperados de ingresso para a tempestade de broadcasts. Com base nas informações à nossa disposição, o loop está a jusante do núcleo. Agora verificamos nossos colegas em nossos downlinks.

• show cdp neighbors

CORE#show cdp neighbors twentyFiveGigE 1/0/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
DISTRO-A         Twe 1/0/1       144        S I         C9300-48P Twe 1/1/1

CORE#show cdp neighbors twentyFiveGigE 1/0/2
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
DISTRO-B         Twe 1/0/2        139        S I         C9300-48P Twe 1/1/1

Acabamos de vir da DISTRO-A. Podemos visitar novamente o DISTRO-A e conferir nossa outra interface/peer naquele switch que foi marcado como suspeito, ou podemos ir para o DISTRO-B. Em seguida, vamos conferir DISTRO-B.

Switch Next-Hop - DISTRO-B

DISTRO-B

                    

• show interfaces | include is up|taxa de entrada

DISTRO-B#show interfaces | in is up|input rate   
<snip>
  5 minute input rate 0 bits/sec, 0 packets/sec            
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
TwentyFiveGigE1/1/1 is up, line protocol is up (connected)
  5 minute input rate 4446192309 bits/sec, 4673252 packets/sec <--- Suspicious 
TwentyFiveGigE1/1/2 is up, line protocol is up (connected)
  5 minute input rate 4457101202 bits/sec, 4571365 packets/sec <--- Suspicious
TwentyFiveGigE1/1/3 is up, line protocol is up (connected)
  5 minute input rate 136192034 bits/sec, 170261 packets/sec  
TwentyFiveGigE1/1/4 is up, line protocol is up (connected)
  5 minute input rate 4936092202 bits/sec, 4474252 packets/sec <--- Suspicious
  

Agora, examinamos rapidamente o spanning-tree para garantir que tudo apareça como esperado.

• show spanning-tree

DISTRO-B#show spanning-tree

  VLAN0001                                  
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             Cost        800
             Port        3 (TwentyFiveGigE1/1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     b08b.d08d.6b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

  Interface           Role Sts Cost      Prio.Nbr Type
  ------------------- ---- --- --------- -------- --------------------------------
  <snip>
  Twe1/1/1            Root FWD 800       128.33   P2p
  Twe1/1/2            Desg FWD 800       128.34   P2p
  Twe1/1/3            Desg FWD 800       128.33   P2p
  Twe1/1/3            Desg FWD 800       128.33   P2p
  Twe1/1/5            Alt  BLK 800       128.34   P2p
  

O spanning-tree neste switch corresponde ao que esperamos em uma rede estável. Podemos ver que nossa porta raiz está convergida conforme o esperado e que nossa interconexão com blocos DISTRO-B (Twe1/1/4). Nossas interfaces de acesso são designadas/encaminhadas. 

Agora investigamos nossos colegas nas interfaces suspeitas.

• show cdp neighbors <interface>

DISTRO-B#show cdp neighbors twentyFiveGigE 1/1/1
  Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                    S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                    D - Remote, C - CVTA, M - Two-port Mac Relay

  Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
  CORE             Twe 1/1/1         144        S I         C9500-48Y4C Twe 1/0/1

  DISTRO-B#show cdp neighbors twentyFiveGigE 1/1/2
  Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                    S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                    D - Remote, C - CVTA, M - Two-port Mac Relay

  Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
  ACCESS-C         Twe 1/1/2         139       S I         C9300-48P Twe 1/1/1

  DISTRO-B#show cdp neighbors twentyFiveGigE 1/1/5
  Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                    S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                    D - Remote, C - CVTA, M - Two-port Mac Relay

  Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
  DISTRO-A         Twe 1/1/5         132        S I         C9300-48P Twe 1/1/2

Acabamos de vir do CORE e já visitamos a DISTRO-A. Com base em nossas descobertas até agora, a lógica nos envia para o ACCESS-C.

ACCESS-C

ACCESS-C#show interfaces | in is up|input rate
  
GigabitEthernet1/0/1 is up, line protocol is up (connected) 
    5 minute input rate 43012 bits/sec, 34 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec            
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
<snip>
TwentyFiveGigE1/1/1 is up, line protocol is up (connected)
    5 minute input rate 0 bits/sec, 0 packets/sec                <-- This interface has zero packets inbound. Normally this means the interface on the other end of the link is blocking. In this scenario we need to take a closer look since the upstream switch is a distribution switch.
TwentyFiveGigE1/1/2 is up, line protocol is up (connected)
    5 minute input rate 4834056103 bits/sec, 4461235 packets/sec <-- This interface has a suspicious input rate.
TwentyFiveGigE1/1/3 is up, line protocol is up (connected)
    5 minute input rate 4456091109 bits/sec, 4573242 packets/sec <-- This interface also has a suspicious input rate.

Esse switch é obviamente afetado pelo loop. Duas interfaces mostram evidência de vitimização. Há também um uplink para a camada de distribuição que é inesperadamente silencioso. Tomamos nota dessas observações e verificamos o spanning-tree ao lado para ver se algo se destaca.

• show spanning-tree 

ACCESS-C#show spanning-tree

    VLAN0001                                  
    Spanning tree enabled protocol rstp
    Root ID    Priority    1
               Address     380e.4d77.4800
               Cost        1600
               Port        4 (TwentyFiveGigE1/1/2)
               Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

    Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
               Address     b08b.d08d.6b80
               Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
               Aging Time  300 sec

    Interface           Role Sts Cost      Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Gig1/0/1            Desg FWD  20000    128.01   P2P
    <snip>
    Twe1/1/1            Desg FWD 800       128.33   P2p
    Twe1/1/2            Root FWD 800       128.34   P2p
    Twe1/1/3            Alt  BLK 800       128.33   P2p

Mais uma vez, vale a pena entender as operações de spanning-tree e o que é esperado em sua rede. Com base no diagrama anterior que mostra a convergência esperada do spanning-tree, espera-se que o ACCESS-C tenha duas portas de bloqueio. Há apenas uma porta de bloqueio listada na saída de show spanning-tree, que é um grande sinalizador vermelho. Isso é potencialmente discreto durante a solução de problemas, então vamos ver o que mais se destaca nesse switch como fora do padrão.

Os switches de acesso em uma rede em camadas geralmente têm uma porta raiz e uma ou mais portas alternativas para a raiz. Os downlinks distantes da bridge raiz normalmente são 'designados' e 'encaminhando'. Twe1/1/1 é mostrado como uma porta designada, o que significa que ele acredita estar mais próximo da bridge raiz do que seu parceiro de link. Nosso diagrama não lista os números de porta, então vamos confirmar quais dispositivos se conectam a quais portas em nosso dispositivo suspeito.

• show cdp neighbors

ACCESS-C#show cdp neighbors twentyFiveGigE 1/1/1
    Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                      S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                      D - Remote, C - CVTA, M - Two-port Mac Relay

    Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID. <--- There is no neighbor information listed for this interface. Very suspiscious. 
    
ACCESS-C#show cdp neighbors twentyFiveGigE 1/1/2
    Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                      S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                      D - Remote, C - CVTA, M - Two-port Mac Relay

    Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
    ACCESS-B         Twe 1/1/2         144        S I         C9300-48P Twe 1/1/3

ACCESS-C#show cdp neighbors twentyFiveGigE 1/1/3
    Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                      S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                      D - Remote, C - CVTA, M - Two-port Mac Relay

    Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
    DISTRO-A         Twe 1/1/3         137        S I         C9300-48P Twe 1/1/2

A interface Twe1/1/1 não tem um vizinho listado. Isso indica que o quadro CDP enviado do peer não chega (ou chega e não pode ser processado) e sugere um link unidirecional nesse contexto. Neste ponto, há evidências suficientes para examinar melhor o link entre DISTRO-B e ACCESS-C. 

A taxa de entrada de zero nessa interface enquanto esperamos que a outra extremidade encaminhe com base na saída de spanning-tree e na taxa de saída da interface. Combinado com a convergência de STP inesperada, onde cada extremidade do enlace alega estar designada e a falta de informações de CDP, esse enlace é unidirecional.

A maneira mais rápida de quebrar o loop nessa situação seria desligar Twe1/1/1 no ACCESS-A.  Uma vez que Twe1/1/1 é desligado, o loop é fisicamente interrompido. Uma vez que o loop é fisicamente interrompido, a tempestade de broadcast imediatamente começa a diminuir.

Este foi um cenário simplificado, mas demonstra o conceito. Rastreie as interfaces afetadas até a origem do loop. 

Summary

Esse cenário demonstrou a metodologia básica para a identificação e solução de problemas de loops de camada 2 com rapidez e precisão. O método pode ser resumido nestas etapas:

1. Em um dispositivo afetado, limpe os contadores e verifique se há evidências de taxas de entrada anormalmente altas em qualquer interface ativa. Considere o tamanho médio dos pacotes de entrada - um tamanho médio menor significa um volume maior de pacotes pequenos (ARPs ou broadcasts DHCP, por exemplo) - e verifique os contadores de entrada de broadcast/multicast para entender se há uma alta porcentagem de tráfego de broadcast/multicast em relação à entrada total de tráfego. Essas interfaces estão potencialmente envolvidas no loop.

ACCESS-C#show interfaces | in is up|input rate

2. Determine os dispositivos pares que se conectam às interfaces suspeitas. O loop está a jusante de uma dessas interfaces.  Vários caminhos apontam em direção ao loop, mas todos os caminhos acabam levando à origem.

ACCESS-C#show cdp neighbors twentyFiveGigE 1/1/1

3. Algumas redes têm dispositivos com vários caminhos de encaminhamento. Verifique o spanning-tree para garantir que a topologia seja convergida como esperado. Verifique se as interfaces de bloqueio estão bloqueadas.

ACCESS-C#show spanning-tree

Incorpore essas etapas e construa uma topologia conforme você se move de um dispositivo para outro. Em última análise, você chega à origem do loop.

O loop pode acontecer quando algum fator impede que o spanning-tree convirja como esperado. Neste cenário, um link unidirecional fez com que um switch de acesso encaminhasse em um link que deveria ser bloqueado.

As tempestades de broadcast também ocorrem quando dispositivos invasores ou suspeitos fazem loop ou refletem o tráfego de volta para a rede.

A metodologia descrita neste documento ajuda os profissionais de rede a localizar rapidamente a origem de qualquer loop de camada 2 ou cenário de reflexão de tráfego.

Finalmente - Por que não TCNs?

Uma prática comum no campo é focalizar e perseguir TCNs de spanning-tree ao solucionar problemas de loops. Recomendamos contra esta proposta a favor das taxas de entrada. A família de switches Catalyst 9000 incorpora uma robusta política de policiamento de plano de controle (CoPP) para evitar interrupções no caminho de punt devido ao volume de tráfego punted. O CoPP nos switches Catalyst 9000 policia as BPDUs se o volume exceder o valor do vigilante da plataforma; no entanto, mesmo que a utilização elevada da CPU não seja vista, o spanning-tree em um Catalyst 9000 é vitimado. Outras plataformas de switch, incluindo os Catalyst legados, como as linhas 2960, 3560, 3750 e 4k, não empregam CoPP e podem ser facilmente sobrecarregadas durante um loop. Qualquer dispositivo é potencialmente vitimizado pelo loop - o que faz o spanning-tree competir com os milhões de broadcasts errados no caminho de punt da CPU. Como resultado, os TCNs gerados são frequentemente falsos positivos e levam um engenheiro pelo caminho errado.

Prevenção e práticas recomendadas

Há recursos opcionais disponíveis nos switches Catalyst que se fortalecem contra loops de camada 2. Esses recursos e as práticas recomendadas têm como objetivo evitar loops antes que eles ocorram e, caso ocorram, reduzir seu impacto.

Recursos

RootGuard - O protetor de raiz impede que as interfaces se tornem portas raiz. O recurso coloca a interface em um estado de Raiz Inconsistente se um BPDU superior for recebido. Isso é especialmente útil se a rede contiver conexões com dispositivos que são gerenciados por outras organizações. Normalmente, isso é aplicado aos downlinks da camada de distribuição que enfrentam a camada de acesso. Nunca se espera que BPDUs superiores cheguem de downstream em uma rede estável.

LoopGuard - Geralmente no STP, as portas raiz e as portas alternativas recebem BPDUs enquanto as portas designadas as transmitem. Essa relação pode fazer com que o spanning-tree não responda a links unidirecionais. O protetor de loop impede que portas alternativas ou raiz sejam designadas. O protetor de loop coloca a interface no estado desativada por erro se as BPDUs não forem recebidas e processadas regularmente pela interface.

BPDUGuard - Este recurso opera colocando uma interface no status err-disable se um BPDU é recebido em uma porta configurada. Configure isso em portas de borda onde não é esperado que outro dispositivo de rede se conecte. Esse recurso é frequentemente usado em conjunto com o Portfast.

PortFast - O Portfast é usado em portas de borda - principalmente acesso, mas também troncos em alguns cenários. Permite que uma porta de borda abandone os estágios normais do spanning-tree e passe diretamente para o encaminhamento. Isso economiza o tempo da perspectiva do endpoint e também evita que uma porta de borda instável transmita TCNs. O Portfast deve sempre ser usado junto com o BPDUGuard para evitar a indução de um loop se um dispositivo de rede for conectado acidentalmente.

Práticas recomendadas adicionais

Escopo de VLAN - Permitir somente VLANs necessárias em troncos. Isso limita o escopo dos loops e evita que um problema localizado se torne uma interrupção em toda a rede. 

Usar VLANs não operacionais como nativa - A prática recomendada é usar uma VLAN não operacional para troncos. Muitas redes usam a VLAN nativa padrão (1), que abrange toda a rede. Use uma VLAN não operacional como nativa para limitar ainda mais o escopo potencial de um loop.

Usar o método de cálculo de custo de caminho uniforme - Todos os switches da série Catalyst 9000 executam o método de custo de caminho longo por padrão a partir do IOS XE 17.6. As versões anteriores são potencialmente curtas por padrão. A maioria dos switches Catalyst herdados é curta por padrão. Os ambientes onde os métodos de custo de caminho misto estão em uso têm problemas para responder a alterações e distúrbios de topologia. Verifique se todos os switches executam o mesmo método. Mais informações podem ser encontradas no guia de configuração de plataforma relevante para spanning-tree.

Use o comando "spanning-tree pathcost method <long/short>" para manipular o método de custo de caminho. "Show spanning-tree summary" é usado para confirmar o método em uso.

ACCESS-A(config)#spanning-tree pathcost method ?
  long   Use 32 bit based values for default port path costs
  short  Use 16 bit based values for default port path costs

ACCESS-A(config)#spanning-tree pathcost method long
<snip>
ACCESS-A#show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: VLAN0001
Extended system ID                      is enabled
Portfast Default                        is disabled
PortFast BPDU Guard Default            is disabled
Portfast BPDU Filter Default           is disabled
Loopguard Default                      is disabled
EtherChannel misconfig guard            is enabled
UplinkFast                              is disabled
BackboneFast                            is disabled
Configured Pathcost method used is long             <--- Displays the configured pathcost method.
<snip>

Informações Relacionadas

Configurando o Spanning Tree Protocol - Switches Catalyst 9300

Configurando recursos opcionais de árvore estendida - Switches Catalyst 9300

Configurando recursos opcionais de árvore estendida - Switches Catalyst 9600

Configurando a detecção de link unidirecional (UDLD) - Switches Catalyst 9300

Identificar e Solucionar Problemas de Operações do Plano de Controle nos Switches Catalyst 9000