Switching de LAN : Protocolo de árbol de expansión

Resolver problemas el STP en los switches de Catalyst que funcionan con el software del sistema del Cisco IOS

16 Enero 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (20 Octubre 2015) | Comentarios


Contenido


Introducción

Este documento proporciona las guías de consulta para utilizar el software de Cisco IOS� para resolver problemas los problemas con el Spanning-Tree Protocol (STP). 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 del Troubleshooting de STP gira alrededor 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

Porque el interligar no tiene ningún mecanismo a seguir si cierto paquete se está remitiendo las épocas múltiples (por ejemplo, un Time to Live IP [TTL] está utilizado para desechar el tráfico que está circulando demasiado de largo en la red), sólo una trayectoria puede existir entre dos dispositivos en el mismo dominio de la capa 2 (L2).

El propósito del STP es bloquear los puertos redundantes basados en un algoritmo STP, para resolver la topología física redundante en una topología del árbol tiene gusto. 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 el Forwarding Loop comienza, congestionará probablemente los links del bajo-ancho de banda a lo largo de su trayectoria — si todos los links están del mismo ancho de banda, todos los links serán congestionados probablemente. Esta congestión causará la pérdida del paquete y llevará a una situación de la red abajo en el dominio afectado L2.

Con la Inundación excesiva, los síntomas no pudieron estar como evidentes. Algunos links lentos pudieron congestionarse por el tráfico saturado, y los dispositivos o los usuarios detrás de estos links congestionados pudieron experimentar la lentitud o la Pérdida total de Conectividad.

prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

Componentes Utilizados

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

  • Catalyst 6500 con el motor del supervisor 2

  • Cisco IOS Software Release 12.1(13)E

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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

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

Por qué falla el STP

El STP hace ciertas suposiciones sobre su entorno de funcionamiento. Éstas son las suposiciones más relevantes a este documento:

  • Cada link entre los dos Bridges es bidireccional. Esto significa que, si A conecta directamente con B, después A recibirá lo que ha enviado B y B recibirá lo que ha enviado A, mientras el link esté para arriba entre él.

  • Cada Bridge que está ejecutando el STP puede recibir, procesar, y transmitir regularmente las Unidades STP (BPDU), también conocidas como paquetes STP.

Mientras que estas suposiciones aparecen lógicas y obvias, hay situaciones cuando no se resuelven. La mayor parte de estas situaciones implican una cierta clase de problemas del hardware; sin embargo, los defectos del software pueden también llevar a las fallas del STP. Diversas fallas de hardware, misconfigurations, o causa del miscabling la mayoría de las fallas STP, mientras que las fallas de software explican la minoría. Las fallas del STP pueden también ocurrir debido a las conexiones adicionales innecesarias que existen entre el Switches. Los VLA N entran un estado inactivo debido a estas conexiones adicionales. Para resolver este problema, quite todas las conexiones no deseadas entre el Switches.

Cuando una de estas suposiciones no se resuelve, uno o más Bridges pudieron recibir o procesar no más los BPDU. Esto significa que el Bridge (o los Bridges) no podrá descubrir la topología de red. Sin el conocimiento de la topología correcta, el Switch no puede bloquear los loopes. Por lo tanto, el tráfico saturado circulará sobre la topología colocada, consumirá todo el ancho de banda, y derribará la red.

Los ejemplos de porqué el Switches puede no recibir los BPDU incluyen los malas transmisores-receptores o convertidores de la interfaz de Gigabite (GBIC), cuestiones del cableado, o fallas de hardware en el puerto, el linecard, o el Supervisor Engine. Una razón frecuente de las fallas del STP es un link unidireccional entre los Bridges. En tal condición, un Bridge envía los BPDU, pero el Bridge rio abajo nunca los recibe. El procesamiento de STP se puede también interrumpir por una CPU sobrecargada (el 99 por ciento o más), porque el Switch no puede procesar los BPDU recibidos. Los BPDU se pueden corromper a lo largo de la trayectoria a partir de un Bridge al otro, que también previene el correcto comportamiento de STP.

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 es causada por los problemas de software. Tal comportamiento pudo causar los “lento-loopes.” Esto significa que algunos paquetes están colocados, pero la mayoría del tráfico todavía está atravesando la red, porque los links no se congestionan probablemente.

Las secciones restantes en este documento proporcionan las guías de consulta para resolver problemas los problemas STP-relacionados mas comunes.

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

Remitiendo los loopes varíe grandemente ambos en su origen (causa) y efectúelos. Debido a la amplia variedad de problemas que puedan afectar al STP, este documento puede proporcionar solamente las Pautas generales sobre cómo resolver problemas los loopes de la expedición.

Antes de que usted comience a resolver problemas, usted debe obtener esta información:

  • Un diagrama de la topología real que detalla todo el Switches y Bridges

  • Sus números del puerto (de interconexión) correspondientes

  • Detalles de la configuración de STP, tales como los cuales el Switch es la raíz y la raíz del respaldo, que los links tienen un coste o una prioridad no valor por defecto, y la ubicación de los puertos de bloqueo

Generalmente, el resolver problemas implica estos pasos (dependiendo de la situación, algunos pasos pueden no ser necesarios):

  1. Identifique el loop.

    Cuando un Forwarding Loop ha desarrollado en la red, éstos son los síntomas frecuentes:

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

    • CPU elevada la utilización en el Routers conectó con los segmentos o los VLA N afectados que pueden llevar a los diversos síntomas, tales como cambio del cambio del vecino del Routing Protocol o del router activo del Hot Standby Router Protocol (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 el paquete que coloca en la red (por ejemplo los mensajes de la dirección IP duplicada del HSRP)

    • Mensajes de Syslog que indican volver a aprender del direccionamiento o los mensajes alternados constantes de la dirección MAC

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

    Nota: Ninguno de estos razones solamente pueden indicar diversos problemas (o ningún problema en absoluto). 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 marcar la utilización del tráfico del backplane 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 el Cisco IOS Software no soporta actualmente este comando.

    Si el nivel de tráficog actual está bien sobre normal o si el nivel de línea de base no se sabe, marque si el nivel máximo se ha alcanzado recientemente y si está cercano al nivel de tráficog actual. Por ejemplo, si el nivel del tráfico pico es el 15 por ciento y fuera alcanzado hace apenas dos minutos y el nivel de tráficog actual es el 14 por ciento, después que significaría que el Switch está funcionando bajo inusualmente mucha carga.

    Si la carga de tráfico está en un nivel normal, después ese significa probablemente que no hay o loop o que este dispositivo no está implicado en el loop. Sin embargo, todavía podría estar implicado 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 Forwarding Loop, la prioridad más alta es parar el loop y restablecer la operación de la red. Para parar el loop, usted debe saber qué puertos están implicados en el loop: mire los puertos con la utilización del vínculo más alta (paquetes por segundo). El comando del Cisco IOS Software de la interfaz de la demostración visualiza la utilización para cada interfaz.

    Para visualizar solamente la información de utilización y el nombre de la interfaz (para una análisis rápido), usted puede ser que utilice el filtrado de salida de la expresión normal del Cisco IOS Software. Publique la interfaz de la demostración | incluye la línea|\ /sec comando de visualizar solamente las estadísticas del paquete 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 la especial atención a las interfaces con la utilización del vínculo más alta. En este ejemplo, éstas son las interfaces g2/3, g2/4, y g2/8; son probablemente los puertos que están implicados en el loop.

  3. Rompa el loop.

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

    Nota: Para ayudar a la Análisis de la causa subsiguiente, usted no necesita apagado ni desconecta todos los puertos inmediatamente; en lugar, ciérrelos uno a la vez. Es generalmente mejor apagar los puertos en el punto del total afectado por el loop, tal como una distribución o un switch del núcleo. Si usted apaga todos los puertos inmediatamente y los habilita o vuelve a conectar uno a uno, puede ser que no trabaje; el loop será parado y no pudo comenzar inmediatamente después que se vuelve a conectar el puerto que ofende. Por lo tanto, sería difícil correlacionar el error a cualquier puerto determinado.

    Nota: Se recomienda que usted recoge la información antes de que usted reinicie el Switches para romper el loop. Si no, la Análisis de la causa de raíz subsiguiente será muy difícil.

    Después de que usted inhabilite o desconecte cada puerto, usted debe marcar si la utilización de backplane del Switch está de nuevo a un nivel normal.

    Nota: Tenga presente que, generalmente, algunos puertos no están sosteniendo el loop pero, están inundando bastante el tráfico que llega con el loop. Cuando usted apaga tales puertos de inundación, usted reducirá solamente la utilización de backplane al muy poco, pero usted no parará el loop.

    En la topología del próximo ejemplo, el loop es en medio conmuta A, B, y la D. Por lo tanto, los links AB, AD, y BD están sosteniendo. Si usted apaga ninguno de estos links, usted parará el loop. Los links AC, AE, BC y BE sólo están saturando el tráfico que llega con el loop.

    /image/gif/paws/28943/170.gif

    Después de que se apague el puerto de mantenimiento, la utilización de backplane irá abajo a un valor normal. Es muy importante observar qué puerto apaga la utilización de backplane traída (y la utilización de otros puertos) a un nivel normal.

    En este momento, el loop será parado y la operación de la red debe mejorar; sin embargo, porque la causa original del loop no fue reparada probablemente, pudo todavía haber algunos problemas excepcionales.

  4. Encuentre y repare la causa del loop.

    El loop se ha parado una vez, usted necesita determinar la razón por la que el loop comenzó. Ésta es a menudo la mayoría de la parte difícil del proceso, porque las razones pueden variar. Es también difícil formalizar un procedimiento exacto que trabaje en todos los casos. Sin embargo, éstas son algunas Pautas generales:

    • Investigue el Diagrama de topología, para encontrar un trayecto redundante. Esto incluye el puerto de mantenimiento encontrado en el paso anterior que vuelve al mismo Switch (los paquetes de trayectos tomaban durante el loop). En la topología del ejemplo anterior, esta trayectoria es AD-DB-BA.

    • Para cada Switch en el trayecto redundante, comprobación para 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 síntoma claro de los problemas cuando los Bridges visualizan constantemente un diverso ID para la raíz STP en un VLAN determinado o el caso STP. Publique el comando show spanning-tree vlan vlan-id de visualizar el Root Bridge ID para un VLA N dado:

      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 VLAN se puede encontrar del puerto, porque los puertos implicados en el loop fueron establecidos en los pasos anteriores. Si los puertos en cuestión son troncos, a menudo están comprendidas todas las VLAN en el tronco. En caso contrario (por ejemplo, si aparece que el loop ha sucedido en un solo VLA N) entonces usted puede intentar publicar las interfaces de la demostración | incluya el comando L2|line|broadcast (solamente en los motores del supervisor 2 y posterior en los Catalyst 6500/6000 Series Switch, porque el Supervisor 1 no proporciona las estadísticas de Switching del por el VLAN). Mire las interfaces VLAN solamente. El VLA N con la cantidad más alta de paquetes conmutados será lo más a menudo posible el donde 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, el VLAN1 explica el número más elevado de los broadcasts y del tráfico L2-switched.

    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 que el puerto se considera la raíz para un VLA N dado, publique 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. ¿Los BPDU recibidos regularmente en el puerto raíz y en los puertos que se suponen para ser están bloqueando?

      Los BPDU son enviados por el Root Bridge en cada intervalo de saludo (dos segundos por abandono). Los Non-Root Bridge reciben, procesan, modifican, y propagan los BPDU que se reciben de la raíz.

      Publique el comando show spanning-tree interface interface detail de ver si se están recibiendo los 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: Un BPDU se ha recibido entre las dos salidas del comando (el contador fue a partir el 53 a 54).

      Los contadores que aparecen son, en realidad, contadores mantenidos por el proceso STP en sí mismo. El significa que, si los contadores de la recepción incrementados, no sólo eran BPDU recibido por un puerto físico pero también fue recibido por proceso STP.

      Si el contador recibido BPDU no está incrementando en el puerto que se supone para ser el suplente o el puerto de backup de la raíz, después el control si el puerto está recibiendo cualesquiera Multicast en absoluto (los BPDU se envía como Multicast). Publique 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

      (La Breve descripción A para las funciones del puerto STP se puede encontrar en el Resumen breve de la sección STP de funciones del puerto de las mejoras del Spanning-Tree Protocol usando el Loop Guard y las características de detección oblicua BPDU.)

      Si no se recibe ningunos BPDU, marque si el puerto no está contando los errores. Publique 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 algunos Multicast están recibidos, y los errores no están incrementando, después marque si los BPDU se están cayendo en proceso STP el llano. Publique 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 usado en este ejemplo visualiza proceso STP las estadísticas. Es importante verificar que los contadores de caídas no están aumentando y que los paquetes recibidos están aumentando.

      Si los paquetes recibidos no están aumentando pero el puerto físico está recibiendo los Multicast, verifique que los paquetes estén siendo recibidos por la interfaz de la en-banda del Switch (la interfaz del CPU). Publique el ibc de la demostración del remote command switch | comando del rx_input i 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 de la en-banda ha recibido 23 paquetes.

      Nota: Estos 23 paquetes son no sólo paquetes BPDU; esto es un contador global para todos los paquetes recibidos por el puerto de la en-banda.

      Si no hay indicación que los BPDU se están cayendo en el switch local o el puerto, usted debe trasladarse al Switch en el otro lado del link y verificar si ese Switch está enviando los BPDU.

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

      Si, según la función del puerto, el puerto está enviando los BPDU — solamente el vecino no los está recibiendo — marca si los BPDU se están enviando realmente. Publique 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, dos BPDU se han enviado entre las salidas.

      Nota: Proceso STP mantiene el BPDU: enviado al revés. Esto significa que el contador indica que el BPDU se ha enviado hacia el puerto físico, para ser enviado eventual. Marque si los contadores de puerto están aumentando para los paquetes de multidifusión transmitidos. Publique 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 conectar donde los BPDU no se reciben, se envían, o se procesan.

      Es posible, al menos inverosímil, que el STP ha calculado el estado correcto para el puerto, pero debido a un problema del avión del control, no podía fijar este estado en el hardware para reenvío. Un loop puede ser creado, si el puerto de bloqueo supuesto no se bloquea en el nivel del hardware. Si usted sospecha tal problema en su red, entre en contacto el Soporte técnico de Cisco para la asistencia adicional.

  5. Restablezca la Redundancia.

    Una vez que se ha encontrado el dispositivo o conecta que está causando el loop, este dispositivo se debe aislar de la red, o medidas se deben tomar para resolver el problema (por ejemplo substituya la fibra o el GBIC). Los links redundantes, desconectados en el paso 3, deben ser restablecidos.

    Es importante hacer como poca manipulación como sea posible al dispositivo o conectar que está causando el loop, porque muchas condiciones que llevan a un loop pueden ser muy transitorias, intermitentes, e inestables. Esto significa que, si la condición se borra durante o después del troubleshooting, puede tardar un rato antes de que ocurra tal condición otra vez. Es posible que la condición no se repita más. El todos los esfuerzos se debe hacer para preservar la condición, para poderlo investigar más a fondo por el Soporte técnico de Cisco. Es importante que usted recoge la información sobre la condición antes de que usted reajuste el Switches. Si se va una condición, es a menudo imposible determinar la causa raíz del loop. Para encontrar el dispositivo o conectar que acciona el loop es un logro importante, pero usted necesita asegurarse de que otro error de la misma clase no cause el loop otra vez. Para más información, refiera a asegurar la red contra la sección de los loopes de la expedición 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 evitar una interrupción de conectividad porque, después de un TC, los puertos determinados directos previamente accesibles de algunas direcciones MAC pudieron llegar a ser accesibles a través de diversos puertos. El TC acorta el tiempo de envejecimiento de la tabla de reenvío en todo el Switches en el VLA N donde ocurre el TC; así, si el direccionamiento no se vuelve a aprender, edad-hacia fuera y la inundación ocurrirá para asegurar a alcance de los paquetes la dirección MAC del destino.

El TC es accionado por el cambio del estado STP de un puerto a o desde el estado del reenvío STP. Después de que el TC, incluso si la dirección MAC del destino determinado tiene envejecido hacia fuera, inundando no deba continuar para de largo. El direccionamiento será vuelto a aprender por el primer paquete que viene del host cuya dirección MAC ha sido envejecido hacia fuera. El problema pudo presentarse cuando están ocurriendo los TC en varias ocasiones, con los intervalos cortos. El Switches será constantemente envejecimiento rápido sus tablas de reenvío, así que la inundación será casi constante.

Nota: Con el STP rápido o el STP múltiple (IEEE 802.1W y IEEE 802.1S), el TC es accionado por un cambio del estado de puerto al envío, así como el cambio del papel de señalado para arraigar. Con el STP rápido, la tabla de reenvío L2 se vacia inmediatamente, en comparación con 802.1d, 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 va un link en un puerto del switch hacia arriba o hacia abajo, hay eventual un TC, una vez que el estado STP del puerto está cambiando a o desde la expedición. Cuando el puerto está inestable, se podrían ocasionar TC e inundaciones reiteradamente.

Los puertos con la característica del STP portfast habilitada no causarán los TC al ir a o desde el estado de reenvío. 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 más información sobre los TC, refiera comprensión del Cambios de topología de protocolo de spanning tree.

Si hay TC repetitivos en la red, usted debe identificar la fuente de estos TC y tomar medidas para reducirlos, para traer la inundación a un 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 usted sigue los puertos que están recibiendo TCN BPDU, usted puede encontrar el dispositivo que está originando los TC.

Establecer si las TC de STP provocaron saturación

Normalmente, usted puede determinar que está inundando del rendimiento lento, las caídas de paquetes en los links que no se suponen ser congestionados, y el analizador de paquete que muestra los paquetes de unidifusión múltiples al mismo destino que no está en el segmento local.

Para más información sobre la Inundación de unidifusión, refiera a las saturaciones de unidifusión en red de campus conmutada.

En un Catalyst 6500/6000 que funciona con el Cisco IOS Software, usted puede marcar el contador del motor de reenvío (solamente en el motor del supervisor 2) para estimar la cantidad de inundación. Publique las estadísticas del conde de la demostración del remote command switch | 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 puesto que la última vez que este comando fue ejecutado, y la segunda columna muestra el valor acumulativo desde la reinicialización más reciente. La primera línea muestra el periodo de los bastidores inundados, y la segunda línea muestra el periodo de los bastidores procesados. 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 se puede utilizar solamente conjuntamente con otras maneras de verificar la inundación, pues los contadores no son granulares. Hay un contador por el Switch, no por el puerto o el VLA N. Es normal ver algunos paquetes de la inundación, pues el Switch inundará siempre si la dirección MAC del 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.

Rastree la fuente de los TC

Si el número VLAN se sabe para el VLA N donde está ocurriendo la Inundación excesiva, marque los contadores STP para ver si el número de TC es alto o que incrementa regularmente. Publique el comando show spanning-tree vlan vlan-id detail (en este ejemplo, se utiliza el VLAN1):

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

Usted puede monitorear el número de cambios de la topología en dirección contraria ve si está aumentando regularmente. Entonces, movimiento al Bridge que está conectado con el puerto se muestra que, de recibir el último TC (en el ejemplo anterior, el puerto GigabitEthernet1/1) y de ver de donde el TC vino para ese Bridge. Este proceso debe ser relanzado hasta que el puerto de la estación terminal sin el STP portfast habilitado se encuentre, o hasta el link inestable se encuentra 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, usted debe configurar la característica portfast para prevenir la generación de TCs.

Nota: En la implementación de STP del Cisco IOS Software, el contador para los TC incrementará solamente si un TCN BPDU es recibido por un puerto en un VLA N. Si una configuración normal BPDU con un indicador del conjunto TC entonces se recibe el contador TC no se incrementa. Esto significa que, si usted sospecha un TC para ser la razón de inundar, es el mejor comenzar a rastrear las fuentes para el TC del Root Bridge STP en ese VLA N. Tendrá la mayoría de la información precisa con respecto la cantidad y a 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. Éstos son los dos problemas más frecuentes:

  • La convergencia de STP o el reconvergence toma que esperado más de largo.

  • La topología resultante es diferente que esperada.

Lo más a menudo posible, éstas son las razones de este comportamiento:

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

  • Misconfiguration, tal como configuración inconsistente de temporizadores STP, excediendo el diámetro STP, o el misconfiguration del portfast

  • Switch sobrecargado CPU durante la convergencia o el reconvergence

  • Defecto de software

Según lo mencionado anterior, este documento puede proporcionar solamente las Pautas generales para resolver problemas, debido a la amplia variedad de problemas que podrían afectar al STP.

Para entender porqué la convergencia toma que esperado más de largo, mire la secuencia de eventos STP para descubrir qué sucedían y en qué orden. Porque la implementación de STP en Cisco IOS Software no tiene registro especial (a excepción de los eventos específicos, tales como inconsistencias del puerto), usted puede utilizar las capacidades de debugging del Cisco IOS Software STP de entender qué está sucediendo.

Para el STP, con un Catalyst 6500/6000 que funciona con el Cisco IOS Software, el proceso se hace en el switch processor (SP) (o el supervisor), así que los debugs necesitan ser habilitados en el SP. Para los Grupos de Bridge del Cisco IOS Software, el proceso se hace en el (RP) del Route Processor, así que los debugs necesitan ser habilitados en el (MSFC) RP.

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 ninguna salida que sea significativa alguien sin el conocimiento detallado de la implementación de STP en Cisco IOS Software. Algunos debugs pueden proporcionar la salida que es inmediatamente legible, por ejemplo los cambios de estado de puerto, los cambios del papel, los eventos tales como TC, y un volcado de los BPDU recibidos y transmitidos. Esta sección no proporciona una descripción completa de todos los debugs, sino introduce bastante abreviadamente lo más frecuentemente usados.

Nota: Cuando usted utiliza los comandos debug, habilite los debugs necesarios mínimos. Si los debugs en tiempo real no son necesarios, registre la salida al registro bastante que lo a la consola. Los debugs excesivos pueden sobrecargar el CPU e interrumpir la operación del Switch. Para dirigir la salida de los debugs al registro en vez a la consola o a las sesiones telnets, publique 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. Éste es el primer debug que da una idea general de qué está sucediendo con el STP.

En Múltiples Árboles de expansión (MST) el modo, no trabaja para publicar el comando debug spanning-tree event. Por lo tanto, publique el comando debug spanning-tree mstp roles de ver la función del puerto de los cambios.

Para ver los cambios de estado del puerto STP, publique el comando debug spanning-tree switch state así como 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 porqué el STP se comporta de cierta manera, es a menudo útil ver los BPDU que son recibidos y enviados 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

Este debug trabaja para el PVST, el Rápido-PVST, y los modos MST; pero no decodifica el contenido de los BPDU. Sin embargo, usted puede utilizarlo para asegurarse de que los BPDU están recibidos.

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, usted puede habilitar el BPDU detallado decodifica 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 el Cisco IOS Software Release 12.1.13E y Posterior, los debugs condicionales para el STP se soportan. Esto significa que usted puede hacer el debug de los BPDU que se reciben o se transmiten sobre una base por puerto o del por el VLAN.

Publique los comandos debug condition vlan vlan_num o debug condition interface interface, de limitar el alcance de la salida de los debugs al por interface o al por el VLAN.

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

Para manejar la incapacidad STP para ocuparse correctamente de ciertos incidentes, Cisco ha desarrollado varias características y mejoras para proteger las redes contra los loopes de la expedición.

Resolviendo problemas las ayudas STP para aislar y para encontrar posiblemente la causa para una falla determinada, mientras que la implementación de estas mejoras es la única forma de asegurar la red contra los loopes de la expedición.

Éstos son métodos para proteger su red contra los loopes de la expedición:

  1. UniDirectional Link Detection (UDLD) del permiso en todos los links entre switches. Para más información sobre el UDLD, refiera a entender y a configurar la función del Unidirectional Link Detection Protocol.

  2. Habilite el Loop Guard en todo el Switches. Para más información sobre el Loop Guard, refiera a las mejoras del Spanning-Tree Protocol usando el Loop Guard y las características de detección oblicua BPDU.

    Cuando está habilitado, el UDLD y el Loop Guard eliminan a la mayoría de las posibles causas para remitir los loopes. Bastante que un Forwarding Loop, el link que ofende (o todo conecta al dependiente en el hardware que falla) se apaga o se bloquea.

    Nota: Aunque estas dos funciones parecen un poco redundantes, cada una tiene capacidades exclusivas. Por lo tanto, utilice ambas características al mismo tiempo para proporcionar el del más alto nivel de la protección. Para una comparación detallada del UDLD y del Loop Guard, refiera al Loop Guard contra la 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 puerto-pegados (cuando el link está para arriba, pero allí no son ningún blackholes asociado del tráfico). La desventaja de esta funcionalidad agregada es que el UDLD agresivo puede potencialmente inhabilitar links en los que no hay falla consistente alguna. La gente confunde a menudo la modificación del intervalo de saludo UDLD con la característica del UDLD agresivo. Esto es incorrecto. Los temporizadores pueden modificarse en ambos modos de UDLD.

    Nota: En los casos pocos probables, el UDLD agresivo puede apagar todos los puertos de link ascendente, que esencialmente aísla el Switch del resto de la red. Por ejemplo, esto podría suceder cuando el Switches por aguas arriba está experimentando muy CPU elevada la utilización y se utiliza el UDLD de modo agresivo. Por lo tanto, se recomienda que usted configura los errordisable-descansos, si el Switch no tiene la administración fuera de banda.

  3. Portfast del permiso en todos los puertos de la estación terminales.

    Usted debe permitir al portfast para limitar la cantidad de TC y de inundación subsiguiente, que pueden afectar al funcionamiento de la red. Utilice solamente este comando con los puertos que conectan con las estaciones terminales. Si no, un loop accidental de la topología puede causar un loop del paquete de datos e interrumpir el Switch y la operación de la red.

    precaución Precaución: Ejercite la precaución cuando usted no utiliza el ningún comando spanning-tree portfast. Este comando quita solamente cualquier comando portfast del específico del puerto. Este comando habilita implícito el portfast si usted define el comando default del árbol de expansión Portfast en el modo de configuración global y si el puerto no es un puerto troncal. Si usted no configura el portfast global, no hay el comando spanning-tree portfast equivalente al comando disable del árbol de expansión Portfast.

  4. Fije los EtherChanneles al desirable mode en los ambos lados (donde soportado) y la 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 da un grado adicional de protección contra los loopes, especialmente durante las reconfiguraciones del canal (por ejemplo cuando los links se unen a o salen del canal, y detección de falla de link). Hay un guardia del misconfiguration del canal del accesorio, que se habilita por abandono y que evita el envío de los loopes debidos canalizar el misconfiguration u otras condiciones. Para más información sobre esta característica, refiera comprensión de la detección de inconsistencias en EtherChannel.

  5. No inhabilite la negociación automática (si está soportado) en los links entre switches.

    Los mecanismos de la negociación automática pueden transportar la información de falla remota, que es el modo más rápido de detectar el error en el lado remoto. Si la falla detéctese en el lado remoto, el lado local derriba el link incluso si el link todavía está recibiendo los pulsos. Comparado a los mecanismos de detección de alto nivel tales como UDLD, la negociación automática es muy rápida (dentro de los microsegundos) pero falta la cobertura de punta a punta del UDLD (tal como el datapath entero: CPU — lógica de la expedición — port1 — port2 — lógica de la expedición — CPU contra port1 — port2). El modo del UDLD agresivo proporciona las funciones similares a la de la negociación automática en lo que respecta a la detección de falla. Si se admite una negociación en ambos extremos del link, no hay necesidad de permitir un UDLD de modo agresivo.

  6. Tenga cuidado cuando usted ajusta los temporizadores STP.

    Los temporizadores STP son dependientes en uno a y en la topología de red. Es posible que STP no funcione correctamente con modificaciones arbitrarias en los temporizadores. Para más información sobre los temporizadores STP, refiera a entender y a ajustar 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 una posibilidad, la protección raíz y la protección BPDU deben ser utilizadas para proteger la red. Para más información sobre la protección raíz y la protección BPDU, refiera a estos documentos:

  8. Protección BPDU del permiso en los puertos activados por Portfast, evitar que el STP sea afectado por los dispositivos de red desautorizados (tales como Hubs, Switches, y interligar al Routers) que están conectados con los puertos.

    Si configuran a la protección raíz correctamente, evitará ya que el STP sea influenciado del exterior. Si habilitan a la protección BPDU, apagará los puertos que están recibiendo cualquier BPDU (no sólo BPDU superiores). Esto puede ser útil si tales incidentes necesitan ser investigados, porque la protección BPDU presenta el mensaje de Syslog y apaga el puerto. Debe ser observado que los loopes de cortocircuito-vida no son prevenidos por la raíz o las protecciones BPDU, si dos puertos activados por Portfast están conectados directamente o a través del concentrador.

  9. Evite el tráfico de usuarios en el 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 del administrador de switches recibe los paquetes de broadcast en el VLAN de administración. Si ocurren los broadcastes excesivos (por ejemplo una tormenta de broadcast o una aplicación que funciona incorrectamente), el Switch CPU pudo sobrecargarse, que podría torcer posiblemente el Funcionamiento del STP.

  10. Una raíz (puesta en hard-code) fiable y ubicación de respaldo de la root STP STP.

    La raíz STP y la raíz de reserva STP deben ser configuradas de modo que la convergencia, en el caso de los errores, ocurra en una forma predecible y construya la topología óptima en cada escenario. No deje la prioridad STP en el valor predeterminado, para prevenir la selección imprevisible del switch de la raíz.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 28943