Solución de problemas de STP y consideraciones de diseño relacionadas

Introducción

Este documento describe cómo resolver problemas y prevenir fallas de protocolo de árbol de expansión (STP) en redes Cisco Catalyst conectadas en puente.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento se centra en el comportamiento STP clásico y los comandos del software Cisco IOS.

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

Antecedentes

Este documento describe algunas de las razones comunes por las que el STP puede fallar y la información que debe buscar para identificar el origen del problema. También muestra el tipo de diseño que minimiza los problemas relacionados con el spanning tree y es fácil de resolver.

Este documento no hace referencia al funcionamiento básico de STP. Para obtener información acerca de cómo funciona STP, consulte este documento:

• Comprensión y configuración del protocolo STP en switches Catalyst

Este documento no analiza el STP rápido (RSTP) definido en la norma IEEE 802.1w. Además, este documento no describe el protocolo de árbol de expansión múltiple (MST), definido en IEEE 802.1s. A menos que se indique lo contrario, las descripciones del temporizador y de la convergencia de este documento se aplican al comportamiento STP clásico de IEEE 802.1D.

Para obtener más información sobre RSTP y MST, consulte estos documentos:

• Comprensión del protocolo de árbol de extensión múltiple (802.1s)

• Explicación del Protocolo de árbol de expansión rápida (802.1w)

Para obtener un documento más específico de solución de problemas de STP para los switches Catalyst que ejecutan Cisco IOS Software, refiérase al documento Solución de Problemas de STP en los Switches Catalyst.

Falla del protocolo de árbol de expansión

La función primaria del algoritmo del árbol de expansión (STA) es cortar los bucles creados por enlaces redundantes en redes con conexión en puente. El STP funciona en la Capa 2 del modelo de interconexión de sistemas abiertos (OSI). Por medio de unidades de datos de protocolo puente (BPDU) que intercambian entre puentes, el STP elige los puertos que finalmente reenvían o bloquean el tráfico. Este protocolo puede fallar en algunos casos específicos, y para resolver la situación que los resultados pueden ser muy difíciles, que depende del diseño de la red. En esta área en particular, debe realizar la parte más importante del proceso de solución de problemas antes de que se produzca el problema.

Un error en el STA lleva, por lo general, a un bucle de conexión en puente. La mayoría de los clientes que llama a Cisco Technical Support por problemas de árbol de expansión sospecha que se ha producido un error, pero rara vez la causa es un error. Incluso si el problema es el software, un loop de conexión en puente en un entorno STP aún proviene de un puerto que puede bloquear, pero en cambio reenvía el tráfico.

Convergencia del árbol de expansión

Consulte el video del árbol de expansión para ver un ejemplo que explica cómo el árbol de expansión converge inicialmente. En el ejemplo también se explica por qué un puerto bloqueado entra en el modo de reenvío a puerto asignado debido a una pérdida excesiva de BPDU, lo que genera una falla en el STA.

El resto de este documento enumera las diferentes situaciones que pueden causar un error en el STA. La mayoría de estos errores está relacionada con una pérdida masiva de BPDU. La pérdida ocasiona el bloqueo de puertos para la transición al modo de reenvío.

discordancia dúplex

La discordancia dúplex en un enlace punto a punto es un error de configuración muy habitual En los links Ethernet de 10/100 Mbps heredados, si configura manualmente el modo dúplex en Full en un lado del link y deja el otro lado en el modo de negociación automática, el link termina en half-duplex. (Un puerto configurado con modo dúplex completo ya no negocia.)

El peor de los casos se produce cuando un puente que envía BPDU tiene el modo dúplex configurado en semidúplex en un puerto, pero el puerto par en otro extremo del enlace tiene el modo dúplex configurado en dúplex completo. En el ejemplo anterior, la discordancia dúplex en el link entre el puente A y B puede conducir fácilmente a un loop de conexión en puente. Dado que el puente B tiene una configuración de dúplex completo, no lleva a cabo la detección de la portadora antes de acceder al enlace. El puente B comienza a enviar tramas incluso si el puente A ya utiliza el link. Esta situación supone un problema para A; el puente A detecta una colisión y ejecuta el algoritmo de rango de postergación antes de que el puente vuelva a intentar otra transmisión del marco. Si hay suficiente tráfico de B a A, cada paquete que envía A, que incluye las BPDU, se somete a un aplazamiento o colisión y, finalmente, se elimina. Desde el punto de vista de un STP, dado que el puente B no recibe más BPDU desde A, el puente B perdió el puente de ruta. Esto hace que B desbloquee el puerto conectado al puente C, y crea el bucle.

Siempre que hay una discordancia dúplex, se puede ver este mensaje de error en las consolas del switch de los switches Catalyst que ejecutan el Cisco IOS Software:

Cisco IOS Software

%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet5/1 (not half duplex), with TBA05071417(Cat6K-B) 4/1 (half duplex).

Verifique la configuración de dúplex y, si no coincide, configúrela correctamente.

Para obtener más información sobre cómo resolver problemas de discordancia de dúplex, consulte el documento Configuración y verificación de la negociación automática de dúplex medio/completo Ethernet 10/100/1000Mb.

link unidireccional

Los links unidireccionales son una causa común del loop de conexión en puente. En los enlace de fibra, un error no detectado suele ocasionar enlaces unidireccionales. También puede provocar un problema con un transceptor. Todo lo que haga que un enlace se mantenga activo mientras suministra comunicación unidireccional es muy peligroso en lo que concierne a STP. El siguiente ejemplo puede aclararlo:

En este caso, suponga que el enlace entre A y B es unidireccional. El enlace elimina el tráfico de A a B, mientras transmite el tráfico de B a A. Supongamos que el puente B se bloqueó antes de que el enlace se vuelva unidireccional. Sin embargo, un puerto solo puede bloquear si recibe BPDU desde un puente con una prioridad superior. Dado que, en este caso, se pierden todas las BPDU que provienen de A, el puente B finalmente realiza la transición de su puerto hacia A al estado de reenvío y reenvía el tráfico. De esta forma, se crea un bucle. Si la falla se produce en el inicio, el STP no converge correctamente. En el caso de una discordancia de dúplex, un reinicio ayuda de forma temporal; pero, en este caso, un reinicio de los puentes no tiene ningún efecto.

Cisco diseñó e implementó el protocolo de detección de enlace unidirección (UDLD) para detectar los enlaces unidireccionales antes de crear el bucle de reenvío. UDLD detecta condiciones unidireccionales en links de Capa 2 soportados. Configure el modo UDLD agresivo en links punto a punto soportados donde se requiera la inhabilitación automática del puerto luego de la detección de una condición unidireccional.

Para obtener más información sobre el uso de UDLD, consulte el documento Configuración de la Función de Protocolo UDLD.

Corrupción de paquetes

La corrupción del paquete también puede conducir a la misma clase de falla. Si un enlace tiene una gran cantidad de errores físicos, puede perder una determinada cantidad de BPDU consecutivas. Esta pérdida puede hacer que un puerto de bloqueo cambie al estado de reenvío. Este caso no se ve con mucha frecuencia porque los parámetros STP predeterminados son muy conservadores. Con los temporizadores predeterminados clásicos de IEEE 802.1D, un puerto bloqueado puede tardar aproximadamente 50 segundos desde la pérdida de la última BPDU superior para alcanzar el estado de reenvío: 20 segundos de edad máxima, 15 segundos de escucha y 15 segundos de aprendizaje. La transmisión exitosa de una sola BPDU interrumpe el bucle. Este caso ocurre habitualmente cuando los parámetros de STP se han ajustado de forma descuidada. Un ejemplo de ajuste es la reducción de la duración máxima.

La discordancia de dúplex, los cables defectuosos o la longitud incorrecta de los cables pueden provocar el daño de los paquetes. Refiérase al documento Resolución de Problemas de Puerto e Interfaz del Switch para obtener una explicación de la salida del contador de errores del software Cisco IOS.

Errores de recurso

El STP se implementa en el software, aun en los switches de alta gama que realizan la mayoría de las funciones de switch en el hardware mediante circuitos integrados de aplicación específica (ASIC). Si por alguna razón hay un uso excesivo de la CPU del puente, los recursos pueden ser inadecuados para la transmisión de BPDU. El STA generalmente no hace un uso intensivo del procesador y tiene prioridad sobre otros procesos. En la sección Búsqueda de errores de recursos de este documento, se proporcionan algunas pautas sobre la cantidad de instancias de STP que una plataforma específica puede gestionar.

Error de configuración de PortFast

PortFast es una función que típicamente desea habilitar únicamente para un puerto o interfaz que se conecta a un host. Cuando el enlace se presenta en este puerto, el puente omite las primeras etapas del STA, y pasa directamente al modo de reenvío.

Precaución: Habilite PortFast solamente en las interfaces de borde que no se conectan a un dispositivo de bridging de Capa 2. No habilite PortFast en una interfaz que pueda recibir BPDU o crear un loop de Capa 2.

En este ejemplo, el dispositivo A es un puente con un puerto p1 que ya reenvía. El puerto p2 tiene una configuración para PortFast. El dispositivo B es un concentrador. Tan pronto como conecta el segundo cable en A, el puerto p2 pasa al modo de reenvío y crea un loop entre p1 y p2. Este loop se detiene tan pronto como p1 o p2 recibe una BPDU que pone uno de estos dos puertos en modo de bloqueo. Pero hay un problema con este tipo de bucle transitorio. Si el tráfico de bucle es muy intenso, es probable que el puente pueda tener problemas para transmitir exitosamente la BPDU que detiene el bucle. Este problema puede retrasar la convergencia de manera considerable o, en casos extremos, hacer que la red se caiga.

Para obtener más información sobre el uso correcto de PortFast en los switches que ejecutan el Cisco IOS Software, refiérase al documento Uso de PortFast y Otros Comandos para Corregir los Retrasos de Conectividad de Inicio de la Estación de Trabajo.

Incluso con la configuración de PortFast, el puerto o la interfaz aún participan en STP. Si un switch con una prioridad de puente inferior a la del puente de ruta activo actual se conecta a un puerto o una interfaz configurados para PortFast, se puede seleccionar como puente de ruta. Este cambio de puente de ruta puede afectar negativamente la topología STP activa y hacer que la red esté por debajo de los valores óptimos. Para evitar esta situación, la mayoría de los switches Catalyst que ejecutan Cisco IOS Software tienen una función con el nombre BPDU Guard. La protección de BPDU deshabilita un puerto o una interfaz configurados para PortFast si el puerto o la interfaz reciben una BPDU.

Para obtener más información sobre el uso de la función BPDU Guard en switches que ejecutan Cisco IOS Software, consulte el documento Comprensión de la Mejora de la Protección de BPDU PortFast del Spanning Tree.

Ajuste complicado de parámetros STP y problemas de diámetro

Un valor radical para el parámetro de duración máxima y el retraso de reenvío puede generar una topología de STP muy inestable. En estos casos, la pérdida de algunas BPDU puede causar la aparición de un bucle. Otro problema, no muy conocido, está relacionado con el diámetro de la red puente. Los valores predeterminados conservadores para los temporizadores de STP imponen un diámetro de red máximo de siete. El máximo diámetro de red limita la distancia posible entre los puentes de la red. En este caso, dos puentes distintos no deben estar a más de siete saltos de distancia. Parte de esta restricción proviene del campo de edad que tiene BPDU.

Cuando una BPDU se propaga del puente de ruta hacia las hojas del árbol, el campo de duración aumenta cada vez que la BPDU atraviesa un puente. Finalmente, el puente descarta la BPDU cuando el campo de duración supera la duración máxima. Si la raíz está demasiado lejos de algunos puentes de la red, puede haber problemas. Este problema afecta a la convergencia del árbol de expansión.

Por lo tanto, preste especial atención si va a cambiar los valores predeterminados de los temporizadores STP. Existe peligro si se intenta lograr una reconvergencia más rápida de esta manera. Un cambio en el temporizador STP afecta al diámetro de la red y a la estabilidad del STP. Puede cambiar la prioridad del puente para seleccionar el puente de ruta y cambiar el parámetro de prioridad o costo de puerto para controlar la redundancia y el balance de carga.

El software Cisco Catalyst le brinda macros que ajustan los parámetros de STP más importantes para usted:

• El comando spanning-tree vlan number root { primary | secondary } disminuye la prioridad del puente para que se convierta en root (o raíz alternativa). Una opción opcional para este comando consiste en el ajuste de los temporizadores STP mediante la especificación del diámetro de red. Incluso cuando se realiza correctamente, el ajuste del temporizador no mejora significativamente el tiempo de convergencia e introduce algunos riesgos de inestabilidad en la red. Además, este tipo de ajuste debe actualizarse cada vez que se agrega un dispositivo a la red. Mantenga los valores predeterminados conservadores, que son conocidos por los ingenieros en redes.

• El comando spanning-tree uplinkfast para el Cisco IOS Software aumenta la prioridad del switch para que el switch no se convierta en el root bridge. El comando reduce el tiempo de convergencia STP después de una falla de link ascendente directo. Utilice esta función antigua en un switch de capa de acceso con enlaces ascendentes redundantes a la capa de distribución cuando la plataforma y el modo STP la admitan. Consulte el documento Comprensión y configuración de la función UplinkFast de Cisco.

• El comando spanning-tree backbonefast para Cisco IOS Software puede reducir el tiempo de convergencia STP del switch en caso de una falla de link indirecto. BackboneFast es una función patentada de Cisco. Consulte el documento Comprensión y Configuración de Backbone Fast en Catalyst Switches.

Para obtener más información sobre los temporizadores STP y las reglas para ajustarlos cuando sea absolutamente necesario, consulte el documento Comprensión y ajuste de los temporizadores del protocolo de árbol de expansión.

Errores de software

Como se mencionó en la Introducción, el STP es una de las primeras funciones que se implementaron en los productos de Cisco. Por lo general, esta característica es muy estable. Sólo la interacción con funciones más recientes, como EtherChannel, ha provocado que el STP falle en algunos casos muy específicos que ya se trataron. Diversos factores pueden causar un error de software y esto pueden tener diferentes efectos. No hay un modo de describir adecuadamente los problemas que puede causar un error. La situación más peligrosa que surge de los errores de software es si ignora algunas BPDU o si tiene una transición de puerto de bloqueo a reenvío.

Resolución de problemas de falla

Desafortunadamente, no hay ningún procedimiento sistemático para solucionar un problema de STP. Sin embargo, en esta sección se resumen algunas de las acciones que están a su disposición. La mayoría de los pasos descritos en esta sección se aplican a la resolución de problemas de bucles de conexión en puente en general. Puede utilizar un método más convencional para identificar otros errores del STP que llevan a la pérdida de conectividad. Por ejemplo, puede explorar el trayecto que toma el tráfico cuando se encuentra con un problema.

Nota: La mayoría de estos pasos para resolver problemas asumen conectividad con los diferentes dispositivos de la red puente. Esta conectividad significa que tiene acceso a la consola. Por ejemplo, durante un loop de conexión en puente probablemente no pueda establecer una conexión remota.

Si tiene el resultado de un show tech-support comando de su dispositivo Cisco, puede utilizar Cisco CLI Analyzer.

Utilice el diagrama de la red

Antes de solucionar un bucle de conexión en puente, como mínimo debe conocer estos elementos:

• La topología de la red conectada en puente

• La ubicación del puente de ruta

• La ubicación de los puertos bloqueados y los enlaces redundantes

Estos conocimientos son esenciales por lo menos por estas dos razones:

• Para saber qué se debe reparar en la red, debe saber cómo se ve la red cuando funciona correctamente.

• La mayoría de los pasos para resolver problemas simplemente utilizan los comandos show para intentar identificar las condiciones de error. Tener conocimientos sobre la red lo ayuda a concentrarse en los puertos críticos de los principales dispositivos.

Identificación de una conexión en puente

Antes, solía ocurrir que una tormenta de difusión podía tener un efecto desastroso en la red. En la actualidad, con los dispositivos y los enlaces de alta velocidad, que permiten la conmutación en el nivel de hardware, no es probable que un solo host, por ejemplo, un servidor, desactive una red a través de difusiones. La mejor manera de identificar un bucle de conexión en puente es capturar el tráfico en un enlace saturado y verificar que se vean paquetes similares varias veces. Sin embargo, para ser realista, si todos los usuarios en un dominio de puente determinado tienen problemas de conectividad al mismo tiempo, ya puede sospechar que hay un bucle de conexión en puente.

Verifique la utilización de los puertos de sus dispositivos y busque valores anormales. Consulte la sección Verificar uso de puertos de este documento.

Restaurar rápidamente la conectividad y prepararse para otro momento

Desactive los puertos para interrumpir el bucle

Los bucles de conexión en puente acarrean consecuencias extremadamente graves en una red en puente. En general, los administradores no tienen tiempo para buscar la causa del bucle y prefieren restaurar la conectividad lo antes posible. Para detener un loop activo, utilice la consola o el acceso fuera de banda para inhabilitar una trayectoria redundante sospechosa a la vez, y verifique la conectividad después de cada cambio. Evite inhabilitar los links que proporcionan la única trayectoria de administración o reenvío a un segmento de red. Si puede identificar una parte de la red que se vea más afectada, empiece a deshabilitar puertos en esta área. O, si es posible, inhabilite inicialmente los puertos que pueden estar bloqueando. Cada vez que desactive un puerto, compruebe si ha restaurado la conectividad en la red. Al identificar qué puerto deshabilitado detiene el bucle, también identifica la ruta redundante en la que se encuentra este puerto. Si este puerto ha estado bloqueando, probablemente haya encontrado el link en el que apareció la falla.

Registro de eventos STP en dispositivos que alojan puertos bloqueados

Si no puede identificar con precisión el origen del problema, o si el problema es transitorio, habilite el registro de eventos de STP en los puentes y switches de la red que experimenta la falla. Si desea limitar la cantidad de dispositivos para configurar, al menos habilite este registro en los dispositivos que alojan puertos bloqueados; la transición de un puerto bloqueado es lo que crea un bucle.

• Ejecute el comando EXEC debug spanning-tree events para habilitar la depuración de eventos STP. Configure logging buffered para capturar los mensajes en el buffer de registro.

También puede intentar enviar el resultado de la depuración a un dispositivo syslog. Desafortunadamente, cuando se produce un bucle de conexión en puente, pocas veces se mantiene la conectividad con un servidor syslog.

Verificar puertos

Los puertos críticos que deben analizarse primero son los puertos de bloqueo. Esta sección proporciona una lista de lo que se debe buscar en los diferentes puertos, con una descripción rápida de los comandos a ejecutar para los switches que ejecutan el Cisco IOS Software.

Verificación de los puertos bloqueados que reciben BPDU

Especialmente en los puertos bloqueados y en los puertos de ruta, verifique que reciba BPDU de forma periódica. Varios problemas pueden derivar en que un puerto no reciba paquetes o BPDU.

• Cisco IOS Software-In Cisco IOS Software Release 12.0 o posterior, la salida del comando show spanning-tree vlan <vlan-id>detail tiene un campo BPDU. El campo muestra la cantidad de BPDU recibida para cada interfaz. Ejecute el comando una o dos veces más para determinar si el dispositivo recibe BPDU. Otra opción es habilitar el debug STP con el comando debug spanning-tree bpdu para verificar la recepción de las BPDU.

Comprobación de discordancias dúplex

Para buscar una discordancia de dúplex, debe comprobar cada lado del enlace punto a punto.

• Cisco IOS Software-Ejecute el show interfaces [interface-number] status comando para verificar la velocidad y el estado dúplex del puerto específico.

Verificar utilización de puertos

Es posible que una interfaz con una sobrecarga de tráfico no logre transmitir BPDU importantes. Un enlace sobrecargado también es un indicador de un posible bucle de conexión en bridge.

• Cisco IOS Software: utilice el comando show interfaces para determinar la utilización en una interfaz. Existen varios campos que lo ayudan en esta determinación, como carga y entrada/salida de paquetes. Refiérase al documento Troubleshooting de Problemas del Puerto del Switch y de la Interfaz para obtener una explicación del resultado del show interfaces comando.

Verificar el daño de paquetes

• Software Cisco IOS: Busque incrementos de errores en el contador de errores de entrada del comando show interfaces. Los contadores de errores incluyen fragmentos minúsculos, fragmentos gigantes, sin búfer, CRC, tramas, desbordamiento y recuentos ignorados.

  Refiérase al documento Resolución de Problemas de Puerto e Interfaz del Switch para obtener una explicación de la show interfaces command output.

Búsqueda de errores de recursos

Una alta utilización de la CPU puede resultar peligrosa para un sistema que ejecuta STA. Utilice el método siguiente para comprobar que los recursos de la CPU son adecuados para un dispositivo:

• Software Cisco IOS: Ejecute el comando show processes cpu. Verifique que la utilización de la CPU no sea demasiado elevada.

Hay una limitación en la cantidad de instancias diferentes de STP que pude gestionar un motor supervisor. Asegúrese de que el número total de puertos lógicos a través de todas las instancias de STP para las diferentes VLAN no excedan la cantidad máxima soportada por cada tipo y de Supervisor Engine y configuración de memoria.

Ejecute el show spanning-tree summary totals comando para los switches, este comando muestra el número de puertos lógicos o interfaces por VLAN en la columna STP Active. El total aparece en la parte inferior de esta columna. El total representa la suma de todos los puertos lógicos a través de todas las instancias de STP para las diferentes VLAN. Asegúrese de que este número no exceda la cantidad máxima admitida por cada tipo de motor supervisor.

Nota: La fórmula para calcular la suma de puertos lógicos del switch es la siguiente:

(number of non-ATM trunks * number of active Vlans on that trunk)
+ 2*(number of ATM trunks * number of active Vlans on that trunk)
+ number of non-trunking ports

Para obtener un resumen de las restricciones para STP que se aplican a los switches Catalyst, consulte estos documentos:

Platform	Restricciones de STP para el software Cisco IOS
Motor supervisor 720 Catalyst 6500/6000	Notas de la versión para Cisco IOS Release 12.2SXF y compilaciones
Catalyst 4500/4000	Notas de la versión del switch Catalyst serie 4500, Cisco IOS, 12.1EW
Catalyst 3750	Guía de Configuración del Software del Switch Catalyst 3750, Rel. 12.1(19)EA1

Comandos útiles

Comandos del Cisco IOS Software

• show interfaces

• show spanning-tree

• show processes cpu

• debug spanning-tree

• logging buffered

Diseñe STP para evitar inconvenientes

Conocer la ubicación de la raíz

A menudo, la información sobre la ubicación de la raíz no está disponible al momento de solucionar los problemas. No deje que sea el STP el que decida qué puente es el puente de ruta. Para cada VLAN, normalmente se puede identificar qué switch puede servir mejor como raíz. Esto depende del diseño de la red. En general, se recomienda elegir un puente potente en el medio de la red. Si coloca el puente de ruta en el centro de la red, con conexión directa a los servidores y routers, reduce generalmente la distancia promedio desde los clientes a los servidores y routers.

Este diagrama indica:

• Si el puente B es de ruta, el enlace de A a C se bloquea en el puente A o en el puente C. En este caso, los hosts que se conectan al switch B pueden acceder al servidor y al router en dos saltos. Los hosts que se conectan al puente C pueden acceder al servidor y al router en tres saltos. La distancia promedio es de dos saltos y medio.

• Si el puente A es raíz, el router y el servidor son alcanzables en dos saltos para ambos hosts que se conectan en B y C. La distancia promedio ahora es de dos saltos.

La lógica que hay detrás de este ejemplo se puede trasladar a topologías más complejas.

Nota: Para cada VLAN, configure el puente raíz y el puente raíz de respaldo reduciendo el valor de prioridad de puente STP. Alternativamente, utilice los comandos spanning-tree vlan <vlan-id> root primary y spanning-tree vlan <vlan-id> root secondary.

Conozca dónde existe redundancia

Proyecte la manera en que se organizan sus enlaces redundantes. Olvídese de la función plug-and-play del STP. Ajuste el parámetro de costo de STP para decidir qué puertos bloquear. Por lo general, este ajuste no es necesario si dispone de un diseño jerárquico y un puente de ruta en una buena ubicación.

Nota: Para cada VLAN, sepa qué puertos pueden estar bloqueando en la red estable. Tenga un diagrama de red que muestre claramente cada loop físico en la red en el que los puertos bloqueados rompen los loops.

Conocer la ubicación de los enlaces redundantes permite identificar un bucle de conexión en puente accidental y la causa. Además, conocer la ubicación los puertos bloqueados le permitirá determinar la ubicación del error.

Minimizar la cantidad de puertos bloqueados

La única acción crítica que realiza el STP es el bloqueo de los puertos. Un sólo puerto de bloqueo que cambie a reenvío por equivocación puede fundir una gran parte de la red. Una buena manera de limitar el riesgo inherente al uso de STP es reducir el número de puertos bloqueados en la medida que sea posible.

Separar las VLAN que no se utilizan

Evite trayectos independientes innecesarios de Capa 2 entre dos nodos de conmutación. Agrupe enlaces paralelos en un EtherChannel cuando el diseño y la plataforma lo admitan:

Los switches de distribución están vinculados en forma dual a dos switches de núcleo. Los usuarios que se conectan en switches de distribución sólo se encuentran en un subconjunto de VLAN disponibles en la red. En este ejemplo, los usuarios que se conectan en Dist 2 se encuentran todos en VLAN 2; Dist 3 solo conecta a los usuarios en la VLAN 3. De forma predeterminada, los enlaces troncales portan todas las VLAN definidas en el dominio del Protocolo de troncal VLAN (VTP). Solamente el Dist 2 recibe tráfico de broadcast y multicast innecesario para la VLAN 3, pero también está bloqueando uno de sus puertos para la VLAN 3. El resultado son tres trayectos redundantes entre el Core A y el Core B. Esta redundancia tiene como consecuencia más puertos bloqueados y una mayor probabilidad de bucle.

Nota: Quite las VLAN que no necesite de los enlaces troncales.

El recorte de VTP reduce el tráfico inundado innecesario para las VLAN elegibles, pero la configuración de VLAN permitida de tronco explícito proporciona una ubicación de VLAN predecible. No trate el recorte de VTP como un reemplazo para eliminar las VLAN no utilizadas de las listas de troncales permitidos.

En este ejemplo, sólo se usa una VLAN de acceso para conectar los switches de distribución al núcleo:

En este diseño, sólo un puerto está bloqueado por cada VLAN. Además, con este diseño, es posible remover enlaces redundantes en sólo un paso si se cierra el núcleo A o el núcleo B.

Use la conmutación de Capa 3

Switching de Capa 3 significa un routing aproximadamente a la velocidad de switching. Un router realiza dos funciones principales:

• Un router crea una tabla de reenvíos. En general, el router intercambia información con los pares mediante protocolos de routing.

• Un router recibe paquetes y los reenvía a la interfaz correcta según la dirección de destino.

Los switches de capa 3 de Cisco de gama alta pueden realizar esta función a la misma velocidad que la función de switching de capa 2. Si introduce un salto de routing y crea una segmentación adicional de la red, no hay penalidad en la velocidad. En este diagrama, se utiliza el ejemplo de la sección Recortar VLAN que no usa como base:

El núcleo A y el B son ahora algunos switches de la Capa 3. VLAN 2 y VLAN 3 ya no están conectadas en puente entre el núcleo A y el núcleo B, por lo que un loop STP no puede atravesar ese límite ruteado. Los loops de Capa 2 siguen siendo posibles dentro de cada VLAN puenteada.

• La redundancia aún está presente, con una dependencia en los protocolos de routing de la Capa 3. El diseño utiliza routing de capa 3 para la redundancia de ruta. El tiempo de convergencia depende del protocolo de routing, el mecanismo de detección de fallos, los temporizadores, la topología y la plataforma.

• Ya no hay ningún puerto que bloquee STP. Por lo tanto, no es posible la creación de un bucle de conexión en puente.

• No hay penalización de velocidad, ya que dejar la VLAN por switching de Capa 3 es tan rápido como hacer bridging dentro de la VLAN.

Hay un único inconveniente con este diseño. La migración de este tipo de diseño implica generalmente un reprocesamiento del esquema de direccionamiento.

Mantener STP incluso si no es necesario

Aun si pudo quitar todos los puertos bloqueados de su red y no tiene ninguna redundancia física, no deshabilite el STP. El STP, por lo general, no hace un uso muy intensivo del procesador; el switching de paquetes no involucra la CPU en la mayoría de los switches de Cisco. Además, las pocas BPDU que se envían en cada enlace no reducen de forma significativa el ancho de banda disponible. Sin embargo, una red conectada en puente sin STP puede desaparecer en una fracción de segundos si un operador comete un error en un panel de conexiones, por ejemplo. Por lo general, no es aconsejable desactivar el STP en una red conectada en puente.

Mantener la VLAN administrativa sin tráfico y evitar que una única VLAN se expanda por toda la red

Por lo general, un switch de Cisco tiene una sola dirección IP que se vincula con una VLAN, conocida como la VLAN administrativa. En esta VLAN, el switch se comporta como un host IP genérico. El tráfico de difusión, multidifusión y plano de control en la VLAN administrativa puede consumir recursos de CPU, en función del tipo de tráfico, la plataforma, la versión de software y la configuración del plano de control. Un índice alto de paquetes de difusión o multidifusión en la VLAN administrativa, puede afectar negativamente la CPU y su capacidad de procesar las BPDU vitales. Por lo tanto, mantenga el tráfico de usuario fuera de la VLAN administrativa.

En las versiones anteriores, no había forma de quitar la VLAN 1 de un tronco en la implementación de Cisco. En general, la VLAN 1 suele servir como VLAN administrativa, en la que se puede acceder a todos los switches en la misma subred IP. Aunque sea útil, esta configuración podría ser riesgosa porque un bucle de conexión en puente en la VLAN 1 afecta todos los enlaces troncales y puede hacer caer la red completa. Sin duda, el mismo problema existe independientemente de la VLAN que se use. Intente segmentar los dominios de conexión en puente que usen switches de alta velocidad de capa 3.

A partir de la versión 12.1(11b)E del software del IOS de Cisco, puede quitar la VLAN 1 de los troncos. La VLAN 1 sigue presente, pero puede mejorar la seguridad y reducir el tráfico de capa 2 innecesario.

Información Relacionada

• Catálogo de herramientas de soporte de Cisco
• Soporte técnico y descargas de Cisco

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
5.0	09-Sep-2026	Recertificación, formateo y links fijos.
3.0	09-May-2024	Recertificación
2.0	10-Jan-2023	El artículo se creó internamente para coincidir con el artículo que se encuentra actualmente en Cisco.com. Imágenes convertidas a formato .png. Introducción actualizada, texto alternativo, gerundios, etc.
1.0	05-Dec-2017	Versión inicial