Resolución de problemas de STP en switches Catalyst que ejecutan el software del sistema Cisco IOS

Introducción

Este documento proporciona pautas para utilizar el software Cisco IOS® para resolver problemas de STP (Spanning-Tree Protocol). Hay comandos específicos que solamente se aplican a switches Catalyst 6500/6000; sin embargo, puede aplicar la mayor parte de los principios a cualquier switch Cisco Catalyst que ejecute el software Cisco IOS.

La mayoría de la resolución de problemas de STP gira en torno a tres problemas:

• loops de reenvío

• flujo excesivo debido a una alta tasa de Cambios de topología (TC) de STP

• problemas relacionados con el tiempo de convergencia

Debido a que el puente no tiene ningún mecanismo para rastrear si un paquete determinado se reenvía varias veces (por ejemplo, se utiliza un tiempo de vida de IP [TTL] para descartar el tráfico que circula demasiado tiempo en la red), sólo puede existir una ruta entre dos dispositivos en el mismo dominio de capa 2 (L2).

El propósito de STP es bloquear los puertos redundantes basados en un algoritmo STP, para resolver la topología física redundante en una topología similar a un árbol. Un loop de reenvío (como un loop STP) ocurre cuando ningún puerto en una topología redundante se encuentra bloqueado y el tráfico se reenvía en círculos en forma indefinida.

Una vez que se inicie el loop de reenvío, probablemente congestione los links de ancho de banda más bajo a lo largo de su trayectoria; si todos los links tienen el mismo ancho de banda, es probable que todos los links estén congestionados. Esta congestión causará la pérdida de paquetes y conducirá a una situación de caída de la red en el dominio L2 afectado.

Con una inundación excesiva, los síntomas podrían no ser tan evidentes. Algunos links lentos pueden congestionarse debido al tráfico inundado, y los dispositivos o usuarios detrás de estos links congestionados pueden experimentar lentitud o pérdida total de conectividad.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Varios tipos de árbol de expansión y cómo configurarlos. Si desea obtener más información, consulte Configuración de STP y IEEE 802.1 MST.

• Varias funciones de árbol de extensión y cómo configurarlas. Consulte Configuración de las Funciones STP para obtener más información.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Catalyst 6500 con motor Supervisor 2

• Cisco IOS Software Release 12.1(13)E

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

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Por qué falla el STP

STP realiza ciertas suposiciones sobre su entorno operativo. Estas son las suposiciones más relevantes para este documento:

• Cada link entre los dos puentes es bidireccional. Esto significa que, si A se conecta directamente con B, A recibirá lo que B ha enviado y B recibirá lo que A ha enviado, siempre y cuando el link esté activo entre ellos.

• Cada puente que ejecuta STP puede recibir, procesar y transmitir regularmente Unidades de datos de protocolo de puente (BPDU) STP, también conocidas como paquetes STP.

Si bien estas suposiciones parecen lógicas y obvias, hay situaciones en las que no se las cumple. La mayoría de estas situaciones implican algún tipo de problema de hardware; sin embargo, los defectos del software también pueden conducir a fallas de STP. Varios fallos de hardware, configuraciones erróneas o cableado provocan la mayoría de las fallas de STP, mientras que las fallas de software representan la minoría. Los errores STP también pueden ocurrir debido a conexiones adicionales innecesarias que existen entre los switches. Las VLAN pasan a un estado inactivo debido a estas conexiones adicionales. Para resolver este problema, elimine todas las conexiones no deseadas entre los switches.

Cuando no se cumple una de estas suposiciones, es posible que uno o más bridges ya no reciban ni procesen las BPDU. Esto significa que el puente (o los puentes) no podrán detectar la topología de red. Sin conocimiento de la topología correcta, el switch no puede bloquear los loops. Por lo tanto, el tráfico inundado circulará a través de la topología con loop, consumirá todo el ancho de banda y hará que la red se cierre.

Algunos ejemplos de por qué los switches pueden no recibir BPDU son transceptores inadecuados o convertidores de interfaz Gigabit (GBIC), problemas de cableado o fallos de hardware en el puerto, la tarjeta de línea o el motor supervisor. Una razón frecuente de las fallas de STP es un link unidireccional entre los bridges. En tal condición, un bridge envía BPDU, pero el bridge descendente nunca las recibe. El procesamiento STP también puede verse interrumpido por una CPU sobrecargada (99% o más), porque el switch no puede procesar las BPDU recibidas. Las BPDU se pueden corromper a lo largo del trayecto de un puente a otro, lo que también evita el comportamiento STP adecuado.

Además de los loops de reenvío, cuando no hay puertos bloqueados, hay situaciones en que sólo ciertos paquetes se reenvían erróneamente a través de los puertos bloqueantes. En la mayoría de los casos, esto se debe a problemas de software. Ese comportamiento podría causar "loops lentos". Esto significa que algunos paquetes tienen loop, pero la mayor parte del tráfico sigue fluyendo a través de la red, porque es probable que los links no estén congestionados.

Las secciones restantes de este documento proporcionan pautas para resolver los problemas más comunes relacionados con STP.

Solución de problemas sobre los loops de reenvío

Los loops de reenvío varían mucho tanto en su origen (causa) como en su efecto. Debido a la gran variedad de problemas que pueden afectar al STP, este documento sólo puede proporcionar pautas generales sobre cómo resolver problemas de loops de reenvío.

Antes de comenzar a resolver problemas, debe obtener esta información:

• Un diagrama de topología real que detalla todos los switches y puentes

• Sus números de puerto correspondientes (interconectados)

• Detalles de la configuración de STP, como qué switch es la raíz y la raíz de respaldo, qué links tienen un costo o prioridad no predeterminado, y la ubicación de los puertos de bloqueo

Por lo general, la solución de problemas implica estos pasos (dependiendo de la situación, es posible que algunos pasos no sean necesarios):

1. Identificar el loop.

   Cuando se ha desarrollado un loop de reenvío en la red, estos son los síntomas habituales:

   • Pérdida de conectividad con, desde y a través de regiones de red afectadas

   • Uso excesivo de CPU en routers conectados a los segmentos afectados o VLAN que puede generar diversos síntomas, como inestabilidad en el vecino de protocolo de ruteo o inestabilidad en el router activo de Protocolo de ruteo de reserva directa (HSRP)

   • Alta utilización de links (a menudo, el 100 por ciento)

   • Alto nivel de utilización de la placa de interconexiones del switch (comparada con la utilización de línea de base)

   • Mensajes de Syslog que indican un loop de paquetes en la red (por ejemplo, mensajes de dirección IP HSRP duplicados)

   • Mensajes de Syslog que indican un reaprendizaje constante de direcciones o mensajes inestables de direcciones MAC

   • Un número creciente de caídas de salida en muchas interfaces

   Nota: Cualquiera de estas razones por sí solas puede indicar problemas diferentes (o ningún problema). Sin embargo, cuando se observan muchos de estos al mismo tiempo, es muy probable que un loop de reenvío se haya desarrollado en la red.

   Nota: La manera más rápida de verificar esto es verificar la utilización del tráfico de la placa de interconexiones del switch:

   cat# show catalyst6000 traffic-meter
   
     traffic meter =   13%  Never cleared
              peak =   14%  reached at 12:08:57 CET Fri Oct 4 2002

   Nota: El Catalyst 4000 con Cisco IOS Software actualmente no soporta este comando.

   Si el nivel de tráfico actual se encuentra muy por encima de lo normal o si se desconoce el nivel de línea de base, verifique si el nivel de pico se ha alcanzado recientemente y si está cerca del nivel de tráfico actual. Por ejemplo, si el nivel de tráfico pico es del 15% y se alcanzó hace sólo dos minutos y el nivel de tráfico actual es del 14%, esto significaría que el switch está funcionando con una carga inusualmente alta.

   Si la carga de tráfico se encuentra en un nivel normal, esto probablemente significa que no hay ningún loop o que este dispositivo no está involucrado en el loop. Sin embargo, todavía podría estar involucrada en un loop lento.

2. Descubra la topología (alcance) del loop.

   Una vez que se ha establecido que la razón de la interrupción de la red es un loop de reenvío, la prioridad más alta es detener el loop y restaurar el funcionamiento de la red. Para detener el loop, debe saber qué puertos están involucrados en el loop: observe los puertos con la utilización de enlaces más alta (paquetes por segundo). El comando show interface Cisco IOS Software muestra la utilización para cada interfaz.

   Para mostrar solamente la información de uso y el nombre de la interfaz (para un análisis rápido), puede utilizar el filtrado de salida de expresiones regulares del software Cisco IOS. Ejecute el comando show interface | incluyen el comando line|\/sec para mostrar sólo las estadísticas de paquetes por segundo y el nombre de la interfaz:

   cat# show interface | include line|\/sec
   
   GigabitEthernet2/1 is up, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/2 is up, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/3 is up, line protocol is up
     5 minute input rate 99765230 bits/sec, 24912 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/4 is up, line protocol is up
     5 minute input rate 1000 bits/sec, 27 packets/sec
     5 minute output rate 101002134 bits/sec, 25043 packets/sec
   GigabitEthernet2/5 is administratively down, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/6 is administratively down, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/7 is up, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/8 is up, line protocol is up
     5 minute input rate 2000 bits/sec, 41 packets/sec
     5 minute output rate 99552940 bits/sec, 24892 packets/sec
   

   Preste especial atención a las interfaces con el mayor uso del link. En este ejemplo, estas son interfaces g2/3, g2/4 y g2/8; probablemente sean los puertos involucrados en el loop.

3. Interrumpa el loop.

   Para romper el loop, debe apagar o desconectar los puertos involucrados. Es muy importante no sólo detener el loop sino también encontrar y reparar la causa raíz del loop. Es relativamente más fácil romper el bucle.

   Nota: Para ayudar al análisis de causa subsiguiente, no necesita apagar o desconectar todos los puertos a la vez; en su lugar, ciérrelos de uno en uno. Por lo general, es mejor apagar los puertos en el punto de agregación afectado por el loop, como un switch de distribución o de núcleo. Si apaga todos los puertos a la vez y los activa o vuelve a conectar uno por uno, es posible que no funcione; el loop se detendrá y puede que no se inicie inmediatamente después de que se vuelva a conectar el puerto infractor. Por lo tanto, sería difícil correlacionar la falla con cualquier puerto en particular.

   Nota: Se recomienda recopilar información antes de reiniciar los switches para interrumpir el loop. De lo contrario, el análisis de la causa raíz será muy difícil.

   Después de inhabilitar o desconectar cada puerto, debe verificar si la utilización de la placa de interconexiones del switch ha vuelto a un nivel normal.

   Nota: Tenga en cuenta que, normalmente, algunos puertos no soportan el loop sino que, más bien, están inundando el tráfico que llega con el loop. Cuando se cierran estos puertos de inundación, sólo se reducirá la utilización de la placa de interconexiones en una pequeña cantidad, pero no se detendrá el loop.

   En el siguiente ejemplo de topología, el loop se encuentra entre los switches A, B y D. Por lo tanto, los links AB, AD y BD se mantienen. Si cierra cualquiera de estos links, detendrá el loop. Los links AC, AE, BC y BE sólo están saturando el tráfico que llega con el loop.

   

   Después de que se cierre el puerto de sostenimiento, la utilización de la placa de interconexiones bajará a un valor normal. Es muy importante tener en cuenta qué puerto apagó llevó el uso de la placa de interconexiones (y el uso de otros puertos) a un nivel normal.

   En este punto, el loop se detendrá y el funcionamiento de la red mejorará; sin embargo, dado que la causa original del loop probablemente no fue corregida, puede que todavía haya algunos problemas pendientes.

4. Identifique y corrija la causa del loop.

   Una vez que se ha detenido el loop, debe determinar la razón por la que comenzó el loop. Esta es a menudo la parte más difícil del proceso, porque las razones pueden variar. También es difícil formalizar un procedimiento exacto que funcione en todos los casos. Sin embargo, estas son algunas pautas generales:

   • Investigue el diagrama de topología para encontrar una ruta redundante. Esto incluye el puerto de mantenimiento encontrado en el paso anterior que regresa al mismo switch (los paquetes de trayectoria tomaban durante el loop). En la topología de ejemplo anterior, esta trayectoria es AD-DB-BA.

   • Para cada switch en la trayectoria redundante, verifique estos problemas:

   1. ¿Conoce el switch la raíz STP correcta?

      Todos los switches en una red L2 deberían estar de acuerdo con una raíz STP común. Es un claro síntoma de problemas cuando los puentes muestran consistentemente un ID diferente para la raíz STP en una VLAN o instancia STP determinada. Ejecute el comando show spanning-tree vlan vlan-id para mostrar el ID de root bridge para una VLAN dada:

      cat# show spanning-tree vlan 333
      
      MST03
        Spanning tree enabled protocol mstp
        Root ID    Priority    32771
                   Address     0050.14bb.6000
                   Cost        20000
                   Port        136 (GigabitEthernet3/8)
                   Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
      
        Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)
                   Address     00d0.003f.8800
                   Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
      
      Interface        Role Sts Cost      Prio.Nbr Status
      ---------------- ---- --- --------- -------- ------------------------
      Gi3/8            Root FWD 20000     128.136  P2p
      Po1              Desg FWD 20000     128.833  P2p

      El número de VLAN se puede encontrar desde el puerto, porque los puertos involucrados en el loop se establecieron en pasos anteriores. Si los puertos en cuestión son troncos, a menudo están comprendidas todas las VLAN en el tronco. Si este no es el caso (por ejemplo, si parece que el loop ha ocurrido en una sola VLAN), puede intentar ejecutar el comando show interfaces | incluye el comando L2|line|broadcast (sólo en los motores Supervisor 2 y posteriores en los switches Catalyst 6500/6000 Series, porque el Supervisor 1 no proporciona estadísticas de switching por VLAN). Observe solamente las interfaces VLAN. La VLAN con la mayor cantidad de paquetes conmutados será con mayor frecuencia la que ocurrió el loop:

      cat# show int | include L2|line|broadcast
      
      Vlan1 is up, line protocol is up
        L2 Switched: ucast: 653704527 pkt, 124614363025 bytes - mcast:
               23036247 pkt, 1748707536 bytes
           Received 23201637 broadcasts, 0 runts, 0 giants, 0 throttles
      Vlan10 is up, line protocol is up
        L2 Switched: ucast: 2510912 pkt, 137067402 bytes - mcast:
               41608705 pkt, 1931758378 bytes
           Received 1321246 broadcasts, 0 runts, 0 giants, 0 throttles
      Vlan11 is up, line protocol is up
        L2 Switched: ucast: 73125 pkt, 2242976 bytes - mcast:
               3191097 pkt, 173652249 bytes
           Received 1440503 broadcasts, 0 runts, 0 giants, 0 throttles
      Vlan100 is up, line protocol is up
        L2 Switched: ucast: 458110 pkt, 21858256 bytes - mcast:
               64534391 pkt, 2977052824 bytes
           Received 1176671 broadcasts, 0 runts, 0 giants, 0 throttles
      Vlan101 is up, line protocol is up
        L2 Switched: ucast: 70649 pkt, 2124024 bytes - mcast:
               2175964 pkt, 108413700 bytes
           Received 1104890 broadcasts, 0 runts, 0 giants, 0 throttles

      En este ejemplo, la VLAN 1 representa el mayor número de broadcasts y tráfico conmutado por L2.

   2. ¿El puerto raíz está identificado correctamente?

      El puerto raíz debe tener el costo menor al puente raíz (algunas veces, un trayecto es más corto en términos de saltos, pero más largo en términos de costo, como los puertos de baja velocidad poseen costos superiores).

      Para determinar qué puerto se considera la raíz para una VLAN dada, ejecute el comando show spanning-tree vlan vlan:

      cat# show spanning-tree vlan 333
      
      MST03
        Spanning tree enabled protocol mstp
        Root ID    Priority    32771
                   Address     0050.14bb.6000
                   Cost        20000
                   Port        136 (GigabitEthernet3/8)
                   Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
      
        Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)
                   Address     00d0.003f.8800
                   Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
      
      Interface        Role Sts Cost      Prio.Nbr Status
      ---------------- ---- --- --------- -------- ------------------------
      Gi3/8            Root FWD 20000     128.136  P2p
      Po1              Desg FWD 20000     128.833  P2p

   3. ¿Se reciben BPDU regularmente en el puerto raíz y en los puertos que se supone que bloquean?

      El puente raíz envía las BPDU cada intervalo hello (dos segundos de forma predeterminada). Los puentes que no son raíz reciben, procesan, modifican y propagan las BPDU que se reciben desde la raíz.

      Ejecute el comando show spanning-tree interface interface detail para ver si se reciben las BPDU:

      cat# show spanning-tree interface g3/2 detail
      
      Port 130 (GigabitEthernet3/2) of MST00 is backup blocking
         Port path cost 20000, Port priority 128, Port Identifier 128.130.
         Designated root has priority 0, address 0007.4f1c.e847
         Designated bridge has priority 32768, address 00d0.003f.8800
         Designated port id is 128.129, designated path cost 2000019
         Timers: message age 4, forward delay 0, hold 0
         Number of transitions to forwarding state: 0
         Link type is point-to-point by default, Internal
         Loop guard is enabled by default on the port
         BPDU: sent 3, received 53
      
      cat# show spanning-tree interface g3/2 detail
      
      Port 130 (GigabitEthernet3/2) of MST00 is backup blocking
         Port path cost 20000, Port priority 128, Port Identifier 128.130.
         Designated root has priority 0, address 0007.4f1c.e847
         Designated bridge has priority 32768, address 00d0.003f.8800
         Designated port id is 128.129, designated path cost 2000019
         Timers: message age 5, forward delay 0, hold 0
         Number of transitions to forwarding state: 0
         Link type is point-to-point by default, Internal
         Loop guard is enabled by default on the port
         BPDU: sent 3, received 54
      

      Nota: Se ha recibido una BPDU entre las dos salidas del comando (el contador pasó de 53 a 54).

      Los contadores que aparecen son, en realidad, contadores mantenidos por el proceso STP en sí mismo. Esto significa que, si los contadores de recepción aumentaron, no sólo un puerto físico recibió BPDU sino que también fue recibido por el proceso STP.

      Si el contador BPDU recibido no aumenta en el puerto que se supone que es el puerto raíz alternativo o de respaldo, verifique si el puerto está recibiendo alguna multidifusión en absoluto (las BPDU se envían como multicast). Ejecute el comando show interface interface counters:

      cat# show interface g3/2 counters
      
      Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
      Gi3/2           14873036             2         89387             0
      
      Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
      Gi3/2          114365997         83776        732086            19
      
      cat# show interface g3/2 counters
      
      Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
      Gi3/2           14873677             2         89391             0
      
      Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
      Gi3/2          114366106         83776        732087            19

      (Se puede encontrar una breve descripción de las funciones de puerto STP en la sección Breve Resumen de las funciones de puerto STP de Mejoras de protocolo de árbol de expansión mediante las Funciones de protección de loop y detección de desviación de BPDU).

      Si no se recibe ninguna BPDU, verifique si el puerto no cuenta errores. Ejecute el comando show interface interface counters errors:

      cat# show interface g4/3 counters errors
      
      Port     Align-Err    FCS-Err   Xmit-Err    Rcv-Err UnderSize OutDiscards
      Gi4/3        0          0          0          0         0           0
      
      Port  Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen   Runts    Giants
      Gi4/3       0         0         0          0         0        0         0

      Es posible que el puerto físico reciba las BPDU pero aún no alcance el proceso STP. Si los comandos usados en los dos ejemplos anteriores muestran que se reciben algunas multidifusión y que los errores no aumentan, verifique si las BPDU se descartan en el nivel de proceso STP. Ejecute el comando remote command switch test spanning-tree process-stats en el Catalyst 6500:

      cat# remote command switch test spanning-tree process-stats
      
      ------------------TX STATS------------------
       transmission rate/sec     = 2
       paks transmitted          = 5011226
       paks transmitted (opt)    = 0
       opt chunk alloc failures  = 0
       max opt chunk allocated   = 0
      ------------------RX STATS------------------
       receive rate/sec          = 1
       paks received at stp isr  = 3947627
       paks queued at stp isr    = 3947627
       paks dropped at stp isr   = 0
       drop rate/sec             = 0
       paks dequeued at stp proc = 3947627
       paks waiting in queue     = 0
       queue depth               = 7(max) 12288(total)
      --------------PROCESSING STATS---------------
       queue wait time (in ms)   = 0(avg) 540(max)
       processing time (in ms)   = 0(avg) 4(max)
       proc switch count         = 100
       add vlan ports            = 20
       time since last clearing  = 2087269 sec

      El comando utilizado en este ejemplo muestra las estadísticas del proceso STP. Es importante verificar que los contadores de caídas no aumenten y que los paquetes recibidos aumenten.

      Si los paquetes recibidos no aumentan pero el puerto físico está recibiendo multidifusión, verifique que los paquetes estén siendo recibidos por la interfaz en banda del switch (la interfaz de la CPU). Ejecute el comando remote switch show ibc | i rx_input en el Catalyst 6500/6000:

      cat# remote command switch show ibc | i rx_input
      
      rx_inputs=5626468, rx_cumbytes=859971138
      
      cat# remote command switch show ibc | i rx_input
      
      rx_inputs=5626471, rx_cumbytes=859971539

      Este ejemplo muestra que, entre las salidas, el puerto dentro de banda ha recibido 23 paquetes.

      Nota: Estos 23 paquetes no son solamente paquetes BPDU; este es un contador global para todos los paquetes recibidos por el puerto dentro de banda.

      Si no hay indicación de que las BPDU se están descartando en el switch o puerto local, debe moverse al switch en el otro lado del link y verificar si ese switch está enviando las BPDU.

   4. ¿Se envían regularmente los BDPU en puertos designados que no sean de raíz?

      Si, según el rol de puerto, el puerto está enviando BPDU, pero el vecino no las está recibiendo, verifique si las BPDU están siendo enviadas. Ejecute el comando show spanning-tree interface interface detail:

      cat# show spanning-tree interface g3/1 detail
      
      Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding
         Port path cost 20000, Port priority 128, Port Identifier 128.129.
         Designated root has priority 0, address 0007.4f1c.e847
         Designated bridge has priority 32768, address 00d0.003f.8800
         Designated port id is 128.129, designated path cost 2000019
         Timers: message age 0, forward delay 0, hold 0
         Number of transitions to forwarding state: 0
         Link type is point-to-point by default, Internal
         Loop guard is enabled by default on the port
         BPDU: sent 1774, received 1
      
      cat# show spanning-tree interface g3/1 detail
      
      Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding
         Port path cost 20000, Port priority 128, Port Identifier 128.129.
         Designated root has priority 0, address 0007.4f1c.e847
         Designated bridge has priority 32768, address 00d0.003f.8800
         Designated port id is 128.129, designated path cost 2000019
         Timers: message age 0, forward delay 0, hold 0
         Number of transitions to forwarding state: 0
         Link type is point-to-point by default, Internal
         Loop guard is enabled by default on the port
         BPDU: sent 1776, received 1

      En este ejemplo, se han enviado dos BPDU entre los resultados.

      Nota: El proceso STP mantiene la BPDU: contador enviado. Esto significa que el contador indica que la BPDU ha sido enviada hacia el puerto físico, para ser enviada finalmente. Verifique si los contadores de puerto están aumentando para los paquetes multicast transmitidos. Ejecute el comando show interface interface counters. Esto puede ayudar a determinar si las BPDU están saliendo o no:

      cat# show interface g3/1 counters
      
      Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
      Gi3/1          127985312         83776        812319            19
      
      Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
      Gi3/1          131825915          3442        872342           386
      
      cat# show interface g3/1 counters
      
      Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
      Gi3/1          127985312         83776        812319            19
      
      Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
      Gi3/1          131826447          3442        872346           386

      Con todos estos pasos, la idea es encontrar el switch o link donde no se reciben, envían o procesan las BPDU.

      Es posible, aunque improbable, que el STP haya calculado el estado correcto para el puerto, pero debido a un problema del plano de control, no pudo establecer este estado en el hardware de reenvío. Se puede crear un loop si el puerto de bloqueo supuesto no está bloqueado en el nivel de hardware. Si sospecha que existe un problema de este tipo en su red, póngase en contacto con el Soporte Técnico de Cisco para obtener más ayuda.

5. Restauración de la redundancia.

   Una vez que se ha encontrado el dispositivo o link que está causando el loop, este dispositivo debe aislarse de la red, o se deben tomar medidas para resolver el problema (como reemplazar la fibra o GBIC). Los links redundantes, desconectados en el Paso 3, deben ser restaurados.

   Es importante manipular lo menos posible el dispositivo o link que está causando el loop, ya que muchas condiciones que conducen a un loop pueden ser muy transitorias, intermitentes e inestables. Esto significa que, si la condición se borra durante o después de la resolución de problemas, puede que lleve un tiempo antes de que dicha condición vuelva a ocurrir. Es posible que la condición no se repita más. Se debe hacer todo lo posible para preservar la condición, de modo que el Soporte Técnico de Cisco pueda investigarla más a fondo. Es importante que recopile información sobre la condición antes de restablecer los switches. Si una condición se ha ido, a menudo es imposible determinar la causa raíz del loop. Encontrar el dispositivo o link que activa el loop es un logro importante, pero debe asegurarse de que otro fallo del mismo tipo no vuelva a causar el loop. Para obtener más información, consulte la sección Protección de la Red contra Loops de Reenvío de este documento.

Solución de problemas de cambios de tipología excesivos causantes de saturación

La función del mecanismo TC es corregir las tablas de reenvío L2 luego de que la topología de reenvío haya cambiado. Esto es necesario para evitar una interrupción de la conectividad porque, después de un TC, algunas direcciones MAC previamente accesibles a través de determinados puertos podrían volverse accesibles a través de diferentes puertos. TC reduce el tiempo de envejecimiento de la tabla de reenvío en todos los switches en la VLAN donde se produce el TC; por lo tanto, si la dirección no se vuelve a aprender, se desvanecerá y se producirá una inundación para asegurar que los paquetes alcancen la dirección MAC de destino.

TC se activa por el cambio del estado STP de un puerto hacia o desde el estado de reenvío STP. Después de TC, incluso si la dirección MAC de destino en particular se ha desactualizado, la inundación no debe continuar durante mucho tiempo. La dirección será aprendida nuevamente por el primer paquete que viene del host cuya dirección MAC ha sido desactualizada. El problema puede surgir cuando se producen repetidamente TC con intervalos cortos. Los switches van a envejecer rápidamente constantemente sus tablas de reenvío, por lo que la inundación será casi constante.

Nota: Con el STP rápido o el STP múltiple (IEEE 802.1w e IEEE 802.1s), el TC se activa por un cambio del estado del puerto al reenvío, así como por el cambio de rol de designado a root. Con el STP rápido, la tabla de reenvío L2 se vacía inmediatamente, en comparación con 802.1d, lo que acorta el tiempo de envejecimiento. El vaciado inmediato de la tabla de reenvío restaura la conectividad más rápido, pero generará mayor inundación.

En una red bien configurada, TC debería ser un evento poco común. Cuando un link en un puerto del switch sube o baja, finalmente hay un TC, una vez que el estado STP del puerto cambia a o desde el reenvío. Cuando el puerto está inestable, se podrían ocasionar TC e inundaciones reiteradamente.

Los puertos con la función STP portfast habilitada no causarán TC cuando vayan al estado de reenvío o desde él. La configuración de Portfast en todos los puertos de dispositivo final (tales como impresoras, PC y servidores) debe limitar los cambios de topología a una cantidad baja, y esto se recomienda muy especialmente. Para obtener más información sobre TC, consulte Introducción a los Cambios de Topología del Protocolo de Spanning Tree.

Si hay TC repetitivos en la red, debe identificar el origen de estos TC y tomar medidas para reducirlos, para reducir la inundación al mínimo.

Con 802.1d, la información de STP sobre un evento TC se distribuye entre los puentes a través de una Notificación TC (TCN), que es un tipo especial de BPDU. Si sigue los puertos que reciben BPDU de TCN, puede encontrar el dispositivo que está originando TCs.

Establecer si las TC de STP provocaron saturación

Normalmente, puede determinar que hay inundación por rendimiento lento, caídas de paquetes en links que no se supone que estén congestionados y el analizador de paquetes que muestra varios paquetes de unidifusión al mismo destino que no está en el segmento local.

Para obtener más información sobre inundación de unidifusión, refiérase a Inundación Unicast en Redes de Campus Conmutadas.

En un Catalyst 6500/6000 que ejecuta Cisco IOS Software, puede verificar el contador del motor de reenvío (sólo en el motor Supervisor 2) para estimar la cantidad de inundación. Ejecute el comando remote switch show earl statistics | i MISS_DA|ST_FR comando:

cat# remote command switch show earl statistics | i MISS_DA|ST_FR

         ST_MISS_DA     =       18                      530308834
         ST_FRMS        =       97                      969084354

cat# remote command switch show earl statistics | i MISS_DA|ST_FR

         ST_MISS_DA     =       4                       530308838
         ST_FRMS        =       23                      969084377

En este ejemplo, la primera columna muestra el cambio desde la última vez que se ejecutó este comando, y la segunda columna muestra el valor acumulativo desde el último reinicio. La primera línea muestra la cantidad de tramas inundadas y la segunda línea muestra la cantidad de tramas procesadas. Si los dos valores son similares o si el primer valor está incrementando a alta velocidad, podría ocurrir que el switch esté siendo inundado con tráfico. Sin embargo, esto sólo se puede utilizar junto con otras formas para verificar la inundación, ya que los contadores no son granulares. Hay un contador por switch, no por puerto o VLAN. Es normal ver algunos paquetes de inundación, ya que el switch siempre se inundará si la dirección MAC de destino no está en la tabla de reenvío. Esto sucederá en el caso de que el switch reciba un paquete con una dirección de destino que aún no se conoce.

Seguimiento del origen de los TC

Si el número de VLAN se conoce para la VLAN donde se produce una inundación excesiva, verifique los contadores STP para ver si el número de TCs es alto o aumenta regularmente. Ejecute el comando show spanning-tree vlan vlan-id detail (en este ejemplo, se utiliza VLAN 1):

cat# show spanning-tree vlan 1 detail

VLAN0001 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, sysid 1, address 0007.0e8f.04c0
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 0, address 0007.4f1c.e847
  Root port is 65 (GigabitEthernet2/1), cost of root path is 119
  Topology change flag not set, detected flag not set
  Number of topology changes 1 last change occurred 00:00:35 ago
          from GigabitEthernet1/1
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

Si el número de VLAN no se conoce, puede usar el analizador de paquetes o revisar los contadores de TC para todas las VLAN.

Tome medidas para evitar TCs excesivas

Puede supervisar el número de contador de cambios de topología para ver si aumenta regularmente. A continuación, vaya al puente que está conectado al puerto que se muestra para recibir el último TC (en el ejemplo anterior, puerto GigabitEthernet1/1) y vea de dónde vino el TC para ese puente. Este proceso debe repetirse hasta que se encuentre el puerto de la estación final sin STP portfast activado, o hasta que se encuentre el link inestable que necesita ser reparado. El procedimiento total necesita repetirse si las TC todavía están llegando desde otras fuentes. Si el link pertenece a un host extremo, debe configurar la función portfast para evitar la generación de TCs.

Nota: En la implementación STP del software Cisco IOS, el contador para TCs sólo aumentará si un puerto en una VLAN recibe una TCN BPDU. Si se recibe una BPDU de configuración normal con un indicador de TC establecido, el contador de TC no se incrementa. Esto significa que, si sospecha que un TC es la razón de la inundación, es mejor comenzar a rastrear los orígenes del TC desde el bridge raíz STP en esa VLAN. Dispondrá de la información más exacta sobre la cantidad y la fuente de los TC.

Solución de problemas relacionados con el tiempo de convergencia

Hay situaciones en las cuales el funcionamiento efectivo de un STP no coincide con el comportamiento esperado. Estos son los dos problemas más frecuentes:

• La convergencia o reconvergencia de STP tarda más de lo esperado.

• La topología resultante es diferente a la esperada.

A menudo, estas son las razones de este comportamiento:

• Una falta de coincidencia entre la topología documentada y la real

• Configuración incorrecta, como una configuración incoherente de los temporizadores STP, que excede el diámetro STP o configuración incorrecta portfast

• CPU de switch sobrecargado durante convergencia o reconvergencia

• Defecto de software

Como se mencionó anteriormente, este documento sólo puede proporcionar pautas generales para la resolución de problemas, debido a la amplia variedad de problemas que podrían afectar al STP.

Para entender por qué la convergencia tarda más de lo esperado, observe la secuencia de eventos STP para averiguar qué estaba sucediendo y en qué orden. Debido a que la implementación STP en el software Cisco IOS no tiene registro especial (excepto para eventos específicos, como inconsistencias de puertos), puede utilizar las capacidades de depuración STP del software Cisco IOS para entender lo que está sucediendo.

Para STP, con un Catalyst 6500/6000 que ejecuta el software Cisco IOS, el procesamiento se realiza en el Procesador del switch (SP) (o Supervisor), por lo que las depuraciones deben habilitarse en el SP. Para los grupos de puentes de software del IOS de Cisco, el procesamiento se realiza en el procesador de ruta (RP), por lo que las depuraciones deben habilitarse en el RP (MSFC).

Comandos de depuración del STP

Muchos comandos de depuración de STP están diseñados para uso en ingeniería de desarrollo. No proporcionan ningún resultado significativo para alguien sin un conocimiento detallado de la implementación STP en el software Cisco IOS. Algunas depuraciones pueden proporcionar resultados que se pueden leer instantáneamente, como cambios en el estado del puerto, cambios de rol, eventos como TC y un vaciado de BPDU recibidas y transmitidas. Esta sección no proporciona una descripción completa de todas las depuraciones, sino que presenta brevemente las más utilizadas.

Nota: Cuando utilice comandos debug, habilite las depuraciones mínimas necesarias. Si no se necesitan depuraciones en tiempo real, registre el resultado en el registro en lugar de imprimirlo en la consola. Los debugs excesivos pueden sobrecargar la CPU e interrumpir el funcionamiento del switch. Para dirigir el resultado de la depuración al registro en lugar de a la consola o a las sesiones Telnet, ejecute los comandos logging console informational y no logging monitor en el modo de configuración global.

Para ver el registro de los eventos generales, ejecute el comando debug spanning-tree event para el Árbol de expansión por VLAN (PVST) y PVST rápido. Esta es la primera depuración que da una idea general de lo que está sucediendo con STP.

En el modo Árbol de extensión múltiple (MST), no funciona para ejecutar el comando debug spanning-tree event. Por lo tanto, ejecute el comando debug spanning-tree mstp roles para ver los cambios de rol de puerto.

Para ver los cambios en el estado STP del puerto, ejecute el comando debug spanning-tree switch state junto con el comando debug pm vp:

cat-sp# debug spanning-tree switch state

Spanning Tree Port state changes debugging is on

cat-sp# debug pm vp

Virtual port events debugging is on
Nov 19 14:03:37: SP:     pm_vp 3/1(333): during state forwarding, got event 4(remove)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333):
  forwarding -> notforwarding

port 3/1 (was forwarding) goes down in vlan 333

Nov 19 14:03:37: SP: *** vp_fwdchange: single: notfwd: 3/1(333)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): notforwarding -> present
Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/1(333)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): present -> not_present
Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/1(333)
Nov 19 14:03:37: SP:     pm_vp 3/2(333): during state notforwarding,
  got event 4(remove)
Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): notforwarding -> present
Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/2(333)

Port 3/2 (was not forwarding) in vlan 333 goes down

Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): present -> not_present
Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/2(333)

Nov 19 14:03:53: SP:     pm_vp 3/1(333): during state not_present,
  got event 0(add)
Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): not_present -> present
Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/1(333)
Nov 19 14:03:53: SP:     pm_vp 3/1(333): during state present,
  got event 8(linkup)
Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): present ->
  notforwarding
Nov 19 14:03:53: SP: STP SW: Gi3/1 new blocking req for 0 vlans
Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/1(333)

Port 3/1 link goes up and blocking in vlan 333

Nov 19 14:03:53: SP:     pm_vp 3/2(333): during state not_present,
  got event 0(add)
Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): not_present -> present
Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/2(333)
Nov 19 14:03:53: SP:     pm_vp 3/2(333): during state present,
  got event 8(linkup)
Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): present ->
  notforwarding
Nov 19 14:03:53: SP: STP SW: Gi3/2 new blocking req for 0 vlans
Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/2(333)

Port 3/2 goes up and blocking in vlan 333

Nov 19 14:04:08: SP: STP SW: Gi3/1 new learning req for 1 vlans
Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 0 vlans
Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 1 vlans
Nov 19 14:04:23: SP:     pm_vp 3/1(333): during state notforwarding,
  got event 14(forward_notnotify)
Nov 19 14:04:23: SP: @@@ pm_vp 3/1(333): notforwarding ->
  forwarding
Nov 19 14:04:23: SP: *** vp_list_fwdchange: forward: 3/1(333)

Port 3/1 goes via learning to forwarding in vlan 333

Para entender por qué el STP se comporta de una manera determinada, a menudo es útil ver las BPDU que son recibidas y enviadas por el switch:

cat-sp# debug spanning-tree bpdu receive

Spanning Tree BPDU Received debugging is on
Nov  6 11:44:27: SP: STP: VLAN1 rx BPDU: config protocol = ieee,
  packet from GigabitEthernet2/1  , linktype IEEE_SPANNING ,
  enctype 2, encsize 17
Nov  6 11:44:27: SP: STP: enc 01 80 C2 00 00 00 00 06 52 5F 0E 50 00 26 42 42 03
Nov  6 11:44:27: SP: STP: Data 0000000000000000074F1CE8470000001380480006525F0E4
  080100100140002000F00
Nov  6 11:44:27: SP: STP: VLAN1 Gi2/1:0000 00 00 00 000000074F1CE847 00000013
  80480006525F0E40 8010 0100 1400 0200 0F00

Esta depuración funciona para los modos PVST, Rapid-PVST y MST; pero no decodifica el contenido de las BPDU. Sin embargo, puede usarla para asegurarse de que se reciban las BPDU.

Para ver los contenidos del BPDU, ejecute el comando de decodificación debug spanning-tree switch rx junto con el comando de proceso debug spanning-tree switch rx para PVST y Rapid–PVST. Ejecute el comando debug spanning-tree mstp bpdu-rx para ver los contenidos del BPDU para MST:

cat-sp# debug spanning-tree switch rx decode

Spanning Tree Switch Shim decode received packets debugging is on

cat-sp# debug spanning-tree switch rx process

Spanning Tree Switch Shim process receive bpdu debugging is on

Nov  6 12:23:20: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026
Nov  6 12:23:20: SP:     encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1
Nov  6 12:23:20: SP:     42 42 03 SPAN
Nov  6 12:23:20: SP:     CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013
Nov  6 12:23:20: SP:     B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00

Nov  6 12:23:22: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026
Nov  6 12:23:22: SP:     encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1
Nov  6 12:23:22: SP:     42 42 03 SPAN
Nov  6 12:23:22: SP:     CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013
Nov  6 12:23:22: SP:     B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00

Para el modo MST, puede habilitar el descódigo detallado de BPDU con este comando debug:

cat-sp# debug spanning-tree mstp bpdu-rx

Multiple Spanning Tree Received BPDUs debugging is on
Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated]
Nov 19 14:37:43: SP: MST:   Proto:0 Version:3 Type:2 Role: DesgFlags[   F    ]
Nov 19 14:37:43: SP: MST:   Port_id:32897 cost:2000019
Nov 19 14:37:43: SP: MST:   root_id  :0007.4f1c.e847 Prio:0
Nov 19 14:37:43: SP: MST:   br_id    :00d0.003f.8800 Prio:32768
Nov 19 14:37:43: SP: MST:   age:2 max_age:20 hello:2 fwdelay:15
Nov 19 14:37:43: SP: MST:   V3_len:90 PathCost:30000 region:STATIC rev:1
Nov 19 14:37:43: SP: MST:   ist_m_id :0005.74
Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated]
Nov 19 14:37:43: SP: MST:   Proto:0 Version:3 Type:2 Role: DesgFlags[   F    ]
Nov 19 14:37:43: SP: MST:   Port_id:32897 cost:2000019
Nov 19 14:37:43: SP: MST:   root_id  :0007.4f1c.e847 Prio:0
Nov 19 14:37:43: SP: MST:   br_id    :00d0.003f.8800 Prio:32768
Nov 19 14:37:43: SP: MST:   age:2 max_age:20 hello:2 fwdelay:15
Nov 19 14:37:43: SP: MST:   V3_len:90 PathCost:30000 region:STATIC rev:1
Nov 19 14:37:43: SP: MST:   ist_m_id :0005.7428.1440 Prio:32768  Hops:18
  Num Mrec: 1
Nov 19 14:37:43: SP: MST: stci=3  Flags[ F    ] Hop:19 Role:Desg [Repeated]
Nov 19 14:37:43: SP: MST:         br_id:00d0.003f.8800 Prio:32771 Port_id:32897
  Cost:2000028.1440 Prio:32768  Hops:18  Num Mrec: 1
Nov 19 14:37:43: SP: MST: stci=3  Flags[ F    ] Hop:19 Role:Desg [Repeated]
Nov 19 14:37:43: SP: MST:         br_id:00d0.003f.8800 Prio:32771 Port_id:32897
  Cost:20000

Nota: Para Cisco IOS Software Release 12.1.13E y posteriores, se soportan debugs condicionales para STP. Esto significa que puede depurar las BPDU que se reciben o se transmiten por puerto o por VLAN.

Ejecute los comandos debug condition vlan vlan_num o debug condition interface interface, para limitar el alcance del resultado de debug a per-interface o per-VLAN.

Cómo proteger la red contra loops de reenvío

Para manejar la incapacidad del STP para hacer frente correctamente a ciertos fallos, Cisco ha desarrollado una serie de funciones y mejoras para proteger las redes de los loops de reenvío.

La resolución de problemas de STP ayuda a aislar y posiblemente encontrar la causa de una falla particular, mientras que la implementación de estas mejoras es la única manera de asegurar la red contra loops de reenvío.

Estos son métodos para proteger su red contra loops de reenvío:

1. Habilite la detección de enlaces unidireccionales (UDLD) en todos los enlaces de switch a switch. Para obtener más información sobre el UDLD, consulte Comprensión y Configuración de la Función Unidirectional Link Detection Protocol.

2. Habilite la protección contra loops en todos los switches. Para obtener más información sobre la protección contra loops, refiérase a Mejoras del Spanning-Tree Protocol usando las Funciones de Detección de Desviación de Bucle Guard y BPDU.

   Cuando se activa, UDLD y Loop Guard eliminan la mayoría de las causas posibles para los loops de reenvío. En lugar de crear un loop de reenvío, el link infractor (o todos los links dependientes del hardware defectuoso) se apaga o bloquea.

   Nota: Aunque estas dos funciones parecen un tanto redundantes, cada una tiene sus capacidades únicas. Por lo tanto, utilice ambas funciones al mismo tiempo para proporcionar el nivel más alto de protección. Para obtener una comparación detallada del UDLD y la protección contra loops, consulte Protección contra loops frente a Detección de Link Unidireccional.

   Existen diferentes opiniones respecto de si debe usar UDLD agresivo o normal. Cabe observar que el UDLD agresivo no otorgará más protección contra los loops que la que otorga el modo normal UDLD. El UDLD agresivo detecta los escenarios de puerto atascado (cuando el link está activo, pero no hay agujeros negros de tráfico asociados). La desventaja de esta funcionalidad agregada es que el UDLD agresivo puede potencialmente inhabilitar links en los que no hay falla consistente alguna. A menudo, las personas confunden la modificación del intervalo hello UDLD con la función UDLD agresiva. Esto es incorrecto. Los temporizadores pueden modificarse en ambos modos de UDLD.

   Nota: En casos excepcionales, el UDLD agresivo puede apagar todos los puertos de enlace ascendente, lo que básicamente aísla el switch del resto de la red. Por ejemplo, esto podría ocurrir cuando ambos switches ascendentes están experimentando una utilización de CPU muy alta y se utiliza el UDLD del modo agresivo. Por lo tanto, se recomienda que configure errordisable-timeouts, si el switch no tiene una administración fuera de banda en su lugar.

3. Habilite portfast en todos los puertos de la estación final.

   Debe habilitar portfast para limitar la cantidad de TC y la inundación subsiguiente, lo que puede afectar el rendimiento de la red. Utilice sólo este comando con los puertos que se conectan a las estaciones finales. De lo contrario, un loop de topología accidental puede causar un loop de paquetes de datos e interrumpir el funcionamiento del switch y de la red.

   Precaución: Tenga cuidado cuando utilice el comando no spanning-tree portfast. Este comando sólo quita cualquier comando portfast específico del puerto. Este comando habilita implícitamente portfast si define el comando spanning-tree portfast default en el modo de configuración global y si el puerto no es un puerto trunk. Si no configura portfast globalmente, el comando no spanning-tree portfast es equivalente al comando spanning-tree portfast disable.

4. Establezca EtherChannels en el modo deseable en ambos lados (donde se admita) y opción no silenciosa.

   El modo deseable permitirá que el Protocolo de agrupamiento de puertos (PAgP) asegure la consistencia de los tiempos de ejecución entre los pares de canalización. Esto proporciona un grado adicional de protección contra los loops, especialmente durante las reconfiguraciones del canal (como cuando los links se unen o salen del canal, y detección de fallas de link). Hay una protección de configuración errónea del canal integrada, que está habilitada de forma predeterminada y que evita los loops de reenvío debido a una configuración incorrecta del canal u otras condiciones. Para obtener más información sobre esta función, refiérase a Comprensión de la Detección de Inconsistencia de EtherChannel.

5. No inhabilite la negociación automática (si se admite) en los links de switch a switch.

   Los mecanismos de negociación automática pueden transmitir información de fallas remota, que es la forma más rápida de detectar fallas en el lado remoto. Si se detecta una falla en el lado remoto, el lado local cierra el link incluso si el link sigue recibiendo impulsos. En comparación con los mecanismos de detección de alto nivel como el UDLD, la negociación automática es muy rápida (en microsegundos) pero carece de la cobertura de extremo a extremo del UDLD (como el datapath completo: CPU: lógica de reenvío: puerto1—puerto2—lógica de reenvío—CPU versus puerto1—puerto2). El modo UDLD agresivo proporciona una funcionalidad similar a la de la negociación automática con respecto a la detección de fallas. Si se admite una negociación en ambos extremos del link, no hay necesidad de permitir un UDLD de modo agresivo.

6. Tenga cuidado al ajustar los temporizadores STP.

   Los temporizadores STP dependen unos de otros y de la topología de red. Es posible que STP no funcione correctamente con modificaciones arbitrarias en los temporizadores. Para obtener más información sobre los temporizadores STP, refiérase a Comprensión y Ajuste de los Temporizadores del Spanning Tree Protocol.

7. Si existe la posibilidad de ataques de denegación del servicio, asegure el perímetro STP de la red con la protección de raíz.

   El protector de raíz y el protector BPDU le permiten asegurar el STP contra la influencia del exterior. Si tal ataque es posible, la protección de raíz y la protección BPDU deben utilizarse para proteger la red. Para obtener más información sobre la protección de raíz y la protección de BPDU, consulte estos documentos:

   • Mejora del protector de raíz del protocolo de árbol de expansión

   • Mejoras de la Protección de Spanning Tree PortFast BPDU

8. Habilite la protección BPDU en los puertos habilitados para portfast para evitar que el STP se vea afectado por dispositivos de red no autorizados (como hubs, switches y routers de conexión en puente) que están conectados a los puertos.

   Si la protección de raíz está configurada correctamente, ya impedirá que el STP se vea influenciado desde el exterior. Si la protección BPDU está activada, apagará los puertos que reciben cualquier BPDU (no sólo BPDU superiores). Esto puede ser útil si es necesario investigar tales incidentes, porque la protección BPDU produce el mensaje syslog y cierra el puerto. Debe tenerse en cuenta que los loops de vida corta no son prevenidos por los Guardias de raíz o BPDU, si dos puertos activados por portfast están conectados directamente o a través del hub.

9. Evite el tráfico del usuario en la VLAN de administración. La VLAN de administración está contenida en un bloque de construcción, y no en toda la red.

   La interfaz de administración del switch recibe paquetes de difusión en la VLAN de administración. Si se producen broadcasts excesivos (como una tormenta de difusión o una aplicación que funciona mal), la CPU del switch podría sobrecargarse, lo que podría distorsionar el funcionamiento de STP.

10. Una ubicación raíz STP predecible (codificada) y una ubicación raíz STP de respaldo.

    La raíz STP y la raíz STP de respaldo deben configurarse de modo que la convergencia, en caso de fallas, se produzca de una manera predecible y genere una topología óptima en cada escenario. No deje la prioridad STP en el valor predeterminado, para evitar la selección impredecible del switch raíz.

Información Relacionada

• Soporte de Producto de LAN
• Soporte de Tecnología de LAN Switching
• Soporte Técnico y Documentación - Cisco Systems