Resolución de Problemas de Bucles de Capa 2 en los Catalyst 9000 Series Switches

Introducción

Este documento describe cómo identificar y resolver problemas de loops de capa 2 en redes que incluyen switches Catalyst de la serie 9000. 

Prerequisites

Se recomienda que comprenda los conceptos de protocolo de árbol de extensión. 

Componentes Utilizados

Este documento no se limita a una versión específica de software o de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Los loops de Capa 2 causan havok en una red de área local. La "tormenta de difusión" resultante interfiere con la comunicación dentro de las LAN virtuales (VLAN) afectadas y bloquea los terminales y los dispositivos de red por igual. El problema cobra impulso con el tiempo, ya que el tráfico de capa 2 no tiene ningún mecanismo, como el tiempo de vida (TTL), que finalmente hace que un paquete se consuma en la red. El tráfico en bucle, como el protocolo de resolución de direcciones (ARP) o el protocolo de configuración dinámica de host (DHCP), se repite infinitamente hasta que se interrumpe el bucle. Un individuo encargado de la investigación de un loop activo se encuentra en una posición estresante.

Afortunadamente, existen métodos probados y verdaderos para investigar y resolver problemas de loops de capa 2. Este documento describe la metodología utilizada por generaciones de ingenieros del TAC. 

Spanning-Tree: ¿Cómo se previenen los loops?

Esta topología simple muestra el protocolo de árbol de expansión en acción. Estos puntos son verdaderos para esta topología:

• Todos los links en este ejemplo son de igual ancho de banda.
• D/F significa Designated (el rol de puerto) Forwarding (el estado de puerto).
• R/F significa reenvío de raíz (la función de puerto) (el estado de puerto).
• A/B significa bloqueo alternativo (la función de puerto) (el estado de puerto).
• La elección del root bridge resultó con el switch identificado elegido como root bridge. Todas las interfaces del puente raíz tienen la función 'designada' y el estado 'reenviando'.
• El puerto raíz para los switches AAAA y BBB es el puerto que conecta cada switch directamente al puente raíz.
• En el link que conecta AAAA con BBBB, el puerto designado pertenece a AAAA en virtud del bridge MAC. 
• En el link que conecta AAAA a BBBB, el puerto de bloqueo pertenece a BBBB en virtud del bridge MAC.

El árbol de expansión ha convergido en esta topología para evitar bucles.  Las flechas verdes representan cómo un paquete de broadcast transmitido por un PC cliente reenviaría en los switches interconectados. El puerto de bloqueo en BBB evita que la transmisión transmitida por el cliente se realice en loop indefinidamente entre los dispositivos.

¿Cómo se forman las tormentas de difusión de capa 2?

Hay muchos escenarios donde la prevención de loops que ofrece el árbol de expansión no previene una tormenta de difusión.  

Los problemas físicos (capa 1) en la red pueden dar lugar a links unidireccionales, lo que evita que los altavoces del árbol de expansión realicen el intercambio confiable de BPDU. La recepción o entrega no confiable de BPDU causa una convergencia de árbol de expansión inesperada y no deseada.

Ejemplo 1:

En esta situación, BBBB deja de recibir BPDU del puente raíz en su puerto raíz. BBBB converge en respuesta a esta pérdida de BPDU. Su puerto raíz ya no es una trayectoria viable a la raíz dado que ya no recibe BPDU y se convierte en un puerto designado. Su puerto de bloqueo continúa recibiendo BPDU de AAAA y se convierte en puerto raíz. Ninguna de las interfaces se bloquea, por lo que se produce un bucle.

El link unidireccional hace que el Spanning-Tree converja inesperadamente

Ejemplo 2:

Las interrupciones en la red también pueden producirse cuando el árbol de extensión converge según lo previsto.  Algunos dispositivos conectados a la red pueden ser vectores de bucles. Un concentrador o un dispositivo similar conectado inesperadamente a la red puede provocar tormentas de difusión.

El concentrador conectado a la red provoca una tormenta de difusión

Resolución de problemas

Hay muchas formas en las que los ingenieros de redes suelen abordar los bucles de nivel 2 y las tormentas de difusión. Esta sección describe un método probado y verdadero que ha sido probado en innumerables casos de TAC y en interrupciones catastróficas.

Este método aprovecha comandos muy básicos y evita puntos de datos como las notificaciones de cambio de topología (TCN) del protocolo de árbol de extensión (STP) que pueden ser caóticas de perseguir. Los TCN en una topología de STP rápido (RSTP) se producen cuando los puertos no de borde se mueven a REENVÍO desde BLOQUEO. El loop en sí puede cargar a los altavoces STP hasta el punto en que no pueden participar predeciblemente en la convergencia. Las interfaces en los switches victimizados se mueven a FORWARDING si no pueden procesar correctamente las BPDU entrantes debido a su plano de control congestionado. Las TCN son a menudo síntomas que revelan dispositivos víctimas, pero no necesariamente al origen del loop.

En lugar de TCN STP, un punto de datos más válido y lineal a considerar son las tasas de entrada de interfaz.  Las interfaces que participan en el loop muestran velocidades de entrada mucho más altas de lo esperado. Las tasas de producción no son tan preocupantes ya que estos dispositivos de flujo descendente son probablemente víctimas ellas mismas. También puede observar una alta velocidad de transmisión y multidifusión en las interfaces afectadas y observar que el tamaño promedio del paquete se inclina a un valor menor al esperado.

Con solo estos comandos, un ingeniero de redes puede aislar la mayoría, si no todos, los bucles de capa 2 de una manera directa:

• show interfaces | include is up|input rate

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

El comando "show interfaces | include is up|input rate" con la canalización y los argumentos nos proporciona un fragmento de salida rápidamente digerible. Nos muestra todas nuestras interfaces que están actualmente en funcionamiento, así como sus velocidades de entrada. Para nuestros propósitos, solo nos preocupamos por las tasas de entrada. Las interfaces con velocidades de entrada inesperadamente altas probablemente sean víctimas del loop. Es probable que el dispositivo conectado a una interfaz con una velocidad de entrada inesperadamente alta esté más cerca del origen del loop.  Las interfaces con velocidades de salida inesperadamente altas probablemente nos alejan de la fuente del 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> O 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

Utilice este comando para comprender cómo el switch local cree que el spanning-tree es convergente.  Tenga en cuenta las diferencias en los diversos sabores de spanning-tree. Los switches Catalyst ejecutan rapid-PVST de forma predeterminada pero admiten PVST y 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

Este sencillo método evita las capturas de paquetes que consumen mucho tiempo, elimina el foco en las TCN del árbol de expansión y mantiene el problema real en la vanguardia de la investigación. También elimina la resolución de problemas de "conjetura y comprobación".

Considere este diagrama de topología:

Ruta de difusión del cliente en topología convergente

El árbol de expansión bloquea varios puertos en esta topología debido a las interconexiones redundantes entre los switches. En este ejemplo, el gráfico X amarillo representa los puertos de bloqueo. Los puertos de reenvío son todos designados o root, según la ubicación del switch local en comparación con el bridge root.  Las flechas verdes representan el flujo normal y esperado de tráfico de broadcast que un cliente de ejemplo enviaría en esta red.

Aunque no es demasiado compleja, esta red ofrece muchas oportunidades para que se formen bucles debido a los numerosos enlaces redundantes.  

Este fragmento de la topología mayor se centra en los roles/estados del árbol de expansión del switch de acceso al que se conecta el servidor.

Convergencia de árbol de extensión en funcionamiento

Considere si tenemos un link unidireccional que evita que el switch de acceso descendente reciba BPDU en su puerto raíz. El árbol de expansión vuelve a converger en respuesta y se produce un loop de capa 2.

El puerto raíz anterior en ACCESS-C deja de recibir BPDU de DISTRO-B. El switch ya no lo reconoce como una trayectoria viable hacia la raíz, por lo que el puerto de bloqueo de mayor prioridad se convierte en ROOT/FORWARDING. El puerto raíz anterior pasa a DESIGNATED/FORWARDING. Esta reconvergencia da como resultado un loop de reenvío.

Este diagrama muestra cómo el loop afecta el tráfico de broadcast enviado desde nuestro cliente.  A menos que se interrumpa el loop, el tráfico en loop continúa en loop indefinidamente y potencialmente ingresa/egresa un switch afectado en múltiples interfaces. Puede ver varias flechas rojas que representan la dirección del tráfico en bucle. 

El problema sigue cobrando impulso a medida que crece el tráfico en bucles infinitos. La familia de switches Catalyst 9000 aprovecha un sólido mecanismo de regulación del plano de control (CoPP) de forma predeterminada, pero algunos productos no lo hacen. Los switches con una interfaz virtual (SVI) de switch local en una VLAN en bucle tienen una copia del tráfico de difusión dentro de esa VLAN dirigida a la CPU. Sin CoPP, todo este tráfico impulsado puede interrumpir la CPU del switch. Esto tiende a empeorar la situación, ya que los switches afectados no pueden participar en el árbol de extensión como se esperaba.

Metodología

Uno de los retos iniciales a los que nos enfrentamos cuando solucionamos este tipo de problemas es determinar por dónde empezar.  En última instancia, la posición en la que empezamos no es tan importante.  Todos los dispositivos afectados por el loop eventualmente se encuentran en el origen del loop.

En este ejemplo, comenzamos en el switch donde se conecta el cliente afectado.

Punto inicial - ACCESS-A - Conectado directamente al cliente

Este método hace que el punto inicial sea irrelevante.  Todas las interfaces afectadas apuntan hacia el origen del problema. Dondequiera que usted comience, si este proceso es seguido usted llega a la fuente del loop/reflexión. En esta situación, el cliente afectado se conecta al switch ACCESS-A. Aquí es donde empezamos. El primer paso en este proceso es considerar las velocidades de entrada en todas las interfaces activas.

• show interfaces | include is up|input rate

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 

El tamaño promedio de los paquetes se calcula dividiendo bytes por segundo por paquetes por segundo. En este ejemplo, el tamaño promedio de los paquetes es de alrededor de 132 bytes. Esto sugiere un alto volumen de paquetes pequeños que sesga el promedio. Un volumen alto de ARP, por ejemplo, puede causar la misma desviación del tamaño promedio de paquete esperado en una red de producción y sugiere que el puerto es víctima de la tormenta de difusión.

Ninguno de los enlaces descendentes muestra tasas de entrada anormales. El único puerto potencialmente afectado es el puerto raíz, el enlace ascendente hacia la capa de distribución. Antes de pasar al siguiente dispositivo, considere primero el árbol de extensión para el 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>

Aquí es donde vale la pena conocer su red y cómo se espera que converja el árbol de extensión. Te1/1/1 es el puerto raíz esperado. Twe1/1/2 también se conecta a un switch y se reenvía, pero su velocidad de entrada es de 0 paquetes/seg, por lo que sabemos que el otro extremo del link se bloquea con éxito. Todo se ve bien con respecto al árbol de expansión. Ahora, confirmamos el par de link en el puerto afectado.

• 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

Interruptor de próximo salto: DISTRO-A

DISTRO-A

El siguiente paso es una repetición de la actividad anterior en el switch que se conecta a la interfaz sospechosa.  Ejecute "show interfaces | include is up|input rate" para identificar interfaces con velocidades de entrada sospechosamente altas.

• show interfaces | include is up|input rate

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.

En DISTRO-A, encontramos dos interfaces con velocidades de entrada superiores a las esperadas. La naturaleza de los loops significa que, por lo general, existen varias trayectorias al origen.  Tomamos nota de ambas interfaces, pero primero verificamos el árbol de expansión para ver si hay algo fuera de lo normal.

• 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>

Si observa la posición de DISTRO-A en la red, puede ver que se espera que todos los puertos de este switch se reenvíen. Tiene un puerto raíz (Twe1/1/1) que lo conecta directamente con el puente raíz. Todos sus enlaces descendentes e interconexiones con otros switches se designan y reenvían. Este seguimiento se realiza con nuestra salida de árbol de expansión.

Ahora, comprobamos los pares en nuestras interfaces sospechosas y decidimos dónde ir a continuación.  Cualquiera de las direcciones da como resultado nuestra llegada a la fuente del 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

En primer lugar, comprobamos CORE, pero sería igualmente válido en este escenario si se migra a ACCESS-B.

Switch de próximo salto: CORE

• show interfaces | include is up|input rate

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

Dado que este switch es el puente raíz, esperaríamos que todas sus interfaces se reenvíen. Confirme rápidamente con "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

No hay rutas de acceso inesperadas para la tormenta de difusión. Basándonos en la información de que disponemos, el loop está aguas abajo del núcleo. Ahora comprobamos a nuestros compañeros en nuestros enlaces descendentes.

• 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 llegar de DISTRO-A. Podríamos volver a visitar DISTRO-A y ver nuestra otra interfaz/peer en ese switch que fue marcado como sospechoso, o podemos dirigirnos a DISTRO-B. A continuación, echaremos un vistazo a DISTRO-B.

Interruptor de próximo salto: DISTRO-B

DISTRO-B

                    

• show interfaces | include is up|input rate

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
  

Ahora echamos un vistazo rápido al árbol de extensión para asegurarnos de que todo aparece como se esperaba.

• 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
  

El árbol de extensión de este switch se corresponde con lo que esperamos en una red estable. Podemos ver que nuestro puerto raíz converge como se esperaba y que nuestra interconexión a los bloques DISTRO-B (Twe1/1/4). Nuestras interfaces de acceso están designadas/reenviando. 

Ahora investigamos a nuestros pares en las interfaces sospechosas.

• 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

Venimos de CORE y ya hemos visitado DISTRO-A. Según las conclusiones a las que hemos llegado hasta ahora, la lógica nos envía a 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.

Obviamente, este switch se ve afectado por el loop. Dos interfaces muestran evidencia de victimización. También hay un enlace ascendente a la capa de distribución que es inesperadamente silencioso. Tomamos nota de estas observaciones y comprobamos el árbol de extensión siguiente para ver si hay algo que destaque.

• 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

Una vez más, vale la pena comprender las operaciones del árbol de extensión y lo que se espera de su red. Según el diagrama anterior que muestra la convergencia esperada del árbol de expansión, se espera que ACCESS-C tenga dos puertos de bloqueo. Sólo hay un puerto de bloqueo en la salida de show spanning-tree que es una enorme bandera roja. Esto puede pasar desapercibido durante la resolución de problemas, así que veamos qué más destaca en este switch como fuera de la norma.

Los switches de acceso de una red por niveles suelen tener un puerto raíz y uno o más puertos alternativos para la raíz. Los enlaces descendentes alejados del puente raíz son generalmente 'designados' y 'reenviando'. Twe1/1/1 se muestra como un puerto designado, lo que significa que cree que está más cerca del puente raíz que su socio de link. Nuestro diagrama no enumera los números de puerto, así que permítanos confirmar qué dispositivos se conectan a qué puertos de nuestro dispositivo sospechoso.

• 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

La interfaz Twe1/1/1 no tiene un vecino en la lista. Esto indica que la trama CDP enviada desde el peer no llega (o llega y no puede ser procesada) y sugiere un link unidireccional en este contexto. En este momento, hay suficientes pruebas para analizar más a fondo el vínculo entre DISTRO-B y ACCESS-C. 

La velocidad de entrada de cero en esta interfaz, mientras que esperamos que el otro extremo se reenvíe en función de su salida de árbol de expansión y la velocidad de salida de la interfaz. Combinado con la convergencia STP inesperada donde cada extremo del link reclama la designación y la falta de información CDP, este link es unidireccional.

La manera más rápida de romper el loop en esta situación sería cerrar Twe1/1/1 en ACCESS-A.  Una vez cerrado Twe1/1/1, el loop se rompe físicamente. Una vez que el loop se interrumpe físicamente, la tormenta de difusión comienza inmediatamente a disminuir.

Se trataba de un escenario simplificado, pero que demuestra el concepto. Rastrea las interfaces impactadas hasta el origen del loop. 

Summary

Este escenario demostró la metodología básica para solucionar de manera rápida y precisa los loops de capa 2. El método se puede resumir en estos pasos:

1. En un dispositivo impactado, borre los contadores y luego verifique si hay evidencia de velocidades de entrada anormalmente altas en cualquier interfaz activa. Considere el tamaño medio de los paquetes entrantes (un tamaño medio más pequeño significa un mayor volumen de paquetes pequeños (ARP o difusiones DHCP, por ejemplo)) y compruebe los contadores de entrada de difusión/multidifusión para saber si hay un alto porcentaje de tráfico de difusión/multidifusión con respecto al tráfico total de entrada. Estas interfaces están potencialmente involucradas en el loop.

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

2. Determine los dispositivos pares que se conectan a las interfaces sospechosas. El loop está aguas abajo de una de estas interfaces.  Varios trayectos apuntan hacia el loop, pero todos los trayectos eventualmente conducen al origen.

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

3. Algunas redes tienen dispositivos con múltiples trayectorias de reenvío. Verifique el árbol de expansión para asegurarse de que la topología converja según lo esperado. Asegúrese de bloquear las interfaces.

ACCESS-C#show spanning-tree

Incorpore estos pasos y cree una topología conforme se desplaza de un dispositivo a otro. En última instancia, se llega al origen del bucle.

El loop puede ocurrir cuando algún factor impide que el spanning-tree converja como se espera. En este escenario, un link unidireccional hizo que un switch de acceso se reenviara en un link que se esperaba que se bloqueara.

Las tormentas de difusión también se producen cuando los dispositivos sospechosos o sospechosos reproducen en bucle o reflejan el tráfico de vuelta en la red.

La metodología descrita en este documento ayuda a los profesionales de red a localizar rápidamente el origen de cualquier loop de capa 2 o escenario de reflexión de tráfico.

Por último, ¿por qué no TCN?

Una práctica común en este campo es centrarse en las TCN de árbol de extensión y perseguirlas cuando se solucionan problemas de bucles. Recomendamos no hacerlo a favor de las tasas de entrada. La familia de switches Catalyst 9000 incorpora una sólida política de políticas de plano de control (CoPP) para evitar interrupciones en la ruta de punt debido al volumen de tráfico punteado. Sin embargo, la CoPP en los switches Catalyst 9000 controla las BPDU si el volumen excede el valor del regulador de plataforma, por lo que incluso si no se observa una alta utilización de la CPU, el árbol de expansión en un Catalyst 9000 se convierte en víctima. Otras plataformas de switches, incluidos los Catalyst heredados, como las líneas 2960, 3560, 3750 y 4k, no emplean CoPP y pueden saturarse fácilmente durante un bucle. Cualquier dispositivo es potencialmente víctima del loop, lo que hace que el spanning-tree compita con los millones de broadcasts erróneos en el trayecto de punt de la CPU. Como resultado, las TCN generadas suelen ser falsos positivos y llevan a un ingeniero por el camino equivocado.

Prevención y mejores prácticas

Hay funciones opcionales disponibles en los switches Catalyst que se resisten a los loops de capa 2. Estas funciones y prácticas recomendadas tienen como objetivo evitar los bucles antes de que se produzcan y reducir su impacto en caso de que se produzcan.

Funciones

RootGuard - La protección de raíz evita que las interfaces se conviertan en puertos raíz. La función coloca a la interfaz en un estado de inconsistencia de raíz si se recibe una BPDU superior. Esto resulta especialmente útil si la red contiene conexiones a dispositivos administrados por otras organizaciones. Normalmente, esto se aplica a los enlaces descendentes de la capa de distribución que se encuentran frente a la capa de acceso. Nunca se espera que las BPDU superiores lleguen de flujo descendente en una red estable.

LoopGuard: Generalmente en STP, los puertos raíz y los puertos alternativos reciben BPDU mientras los puertos designados las transmiten. Esta relación puede hacer que el spanning-tree no pueda responder a los links unidireccionales. La protección contra loops evita que los puertos alternativos o root se designen. La protección contra loops pone la interfaz en estado err-disabled si la interfaz no recibe y procesa regularmente las BPDU.

BPDUGuard - Esta función funciona colocando una interfaz en estado err-disable si se recibe una BPDU en un puerto configurado. Configure este puerto en el borde donde no se espera que se conecte otro dispositivo de red. Esta función se utiliza a menudo junto con Portfast.

PortFast: Portfast se utiliza en los puertos periféricos, principalmente en el acceso, pero también en los troncales en algunos escenarios. Permite que un puerto de borde se olvide de las etapas normales del árbol de expansión y se mueva directamente al reenvío. Esto ahorra tiempo desde la perspectiva del terminal y también evita que un puerto de borde inestable transmita TCN. Portfast debe utilizarse siempre junto con BPDUGuard para evitar la inducción de un loop si un dispositivo de networking se conecta accidentalmente.

Prácticas recomendadas adicionales

Alcance de VLAN: solo permita las VLAN necesarias en los troncos. Esto limita el alcance de los loops y evita que un problema localizado se convierta en una interrupción en toda la red. 

Usar VLAN no operativas como nativas - La práctica recomendada es utilizar una VLAN no operativa para troncos. Muchas redes utilizan la VLAN nativa predeterminada (1), que abarca toda la red. Utilice una VLAN no operativa como nativa para limitar aún más el alcance potencial de un loop.

Uso del Método de Cálculo de Costo de Trayectoria Uniforme - Todos los switches de la serie Catalyst 9000 ejecutan el método de costo de trayectoria larga de manera predeterminada a partir de IOS XE 17.6. Las versiones anteriores se cortan potencialmente de forma predeterminada. La mayoría de los switches Catalyst heredados se quedan cortos de forma predeterminada. Los entornos en los que se utilizan métodos de costo de ruta mixta tienen problemas para responder a los cambios y las perturbaciones de la topología. Asegúrese de que todos los switches ejecuten el mismo método. Encontrará más información en la guía de configuración de la plataforma relevante para el árbol de extensión.

Utilice el comando "spanning-tree pathcost method <long/short>" para manipular el método de costo de trayectoria. "Show spanning-tree summary" se utiliza para confirmar el método en 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>

Información Relacionada

Configuración del protocolo de árbol de extensión - Switches Catalyst 9300

Configuración de las Funciones Opcionales del Spanning Tree - Switches Catalyst 9300

Configuración de las Funciones Opcionales del Spanning-Tree - Switches Catalyst 9600

Configuración de la Detección de Link Unidireccional (UDLD) - Switches Catalyst 9300

Resolución de problemas de operaciones del plano de control en switches Catalyst 9000