Este documento presenta una lista de recomendaciones que ayuda a implementar una red segura en lo que respecta a la conexión en puente para los switches Cisco Catalyst que ejecutan Catalyst OS (CatOS) y el software Cisco IOS®. Este documento explica algunas de las razones comunes por las que puede fallar Spanning Tree Protocol (STP) y la información que debe examinar para identificar el origen del problema. El documento también muestra la clase de diseño que minimiza los problemas relacionados con el árbol de expansión y cuyo Troubleshooting resulta fácil.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Este documento no hace referencia al funcionamiento básico de STP. Para obtener información acerca de cómo funciona STP, consulte este documento:
Este documento no analiza el STP rápido (RSTP) definido en la norma IEEE 802.1w. Además, este documento no analiza el protocolo de árbol de expansión múltiple (MST), definido en la norma IEEE 802.1s. Para obtener más información sobre RSTP y MST, consulte estos documentos:
Para obtener un documento de solución de problemas de STP más específico para los switches Catalyst que ejecutan software Cisco IOS, consulte el documento Solución de problemas de STP en el switch Catalyst que ejecuta Cisco IOS integrado (modo nativo).
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 opera 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 solucionar los problemas de la situación resultante puede ser muy difícil, según el diseño de la red. En esta área particular, usted realiza la parte más importante del proceso de solución de problemas antes de que el problema ocurra.
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 bucle de puente en un entorno STP aún proviene de un puerto que debería estar bloqueando el tráfico, pero en su lugar, lo está reenviando.
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.
La discordancia dúplex en un enlace punto a punto es un error de configuración muy habitual Si establece manualmente el modo dúplex en Completo en un lado del enlace y deja el otro lado en el modo de autonegociación, el enlace termina en semidúplex. (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 el B puede fácilmente conducir 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 empieza a enviar marcos, incluso si el puente A ya está usando el enlace. 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 haya una discrepancia de dúplex, se ven estos mensajes de error en las consolas de los switches Catalyst que ejecutan el software Cisco IOS y CatOS:
CDP-4-DUPLEXMISMATCH: Full/half duplex mismatch detected on port [mod]/[port]
%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 solucionar los problemas de discrepancia de dúplex, consulte el documento Configuración y solución de problemas de autonegociación de dúplex completo/semidúplex de Ethernet 10/100/1000 MB.
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 link descarta el tráfico de A a B mientras el link transmite el tráfico de B a A. Suponga que el puente B estaba bloqueando antes de que el link se volviera 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. Esta función puede detectar cableado incorrecto o enlaces unidireccionales en la capa 2 e interrumpir automáticamente los bucles resultantes al deshabilitar algunos puertos. Ejecute UDLD siempre que sea posible en un entorno de puente.
Para obtener más información sobre el uso de UDLD, consulte el documento Comprensión y configuración de la función del protocolo de detección de enlaces unidireccionales.
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. El puerto de bloqueo debe perder BPDU por 50 segundos antes de la transición al reenvío. 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. Consulte el documento Solución de problemas del puerto para switch y la interfaz para obtener una explicación de la salida del contador de errores del software CatOS y Cisco IOS.
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 cualquier motivo, hay un uso excesivo de la CPU del puente, es posible que los recursos sean 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.
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: No use la función PortFast en los puertos para switch o interfaces que se conecten con otros switches, concentradores o routers. De lo contrario, se puede crear un bucle de red.
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 enchufe el segundo cable en A, el puerto p2 pasa al modo de reenvío y crea un bucle 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 software CatOS y Cisco IOS, consulte el documento Uso de PortFast y otros comandos para resolver retrasos en la 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 que se produzca esta situación, la mayoría de switches Catalyst que ejecutan el software CatOS y Cisco IOS disponen de una función denominada Protección BPDU. 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 de protección de BPDU en los switches que ejecutan el software CatOS y Cisco IOS, consulte el documento Mejora de la protección de BPDU de Portfast del árbol de expansión.
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. No hay peligro si intenta obtener 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 macro set spantree root [secondary] disminuye la prioridad del puente d modo que se convierte en el puerto de ruta (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 set spantree uplinkfast para CatOS o el comando spanning-tree uplinkfast para el software Cisco IOS aumenta la prioridad del switch para que el switch no pueda ser raíz. El comando aumenta el tiempo de convergencia de STP en el caso de error del enlace ascendente. Use este comando en un switch de distribución con conexión dual con switches de núcleo. Consulte el documento Comprensión y configuración de la función UplinkFast de Cisco.
El comando set spantree backbonefast enable para CatOS o el comando spanning-tree backboneafast para el software Cisco IOS pueden aumentar el tiempo de convergencia de STP del switch en caso de una falla de enlace indirecto. BackboneFast es una función patentada de Cisco. Consulte el documento Comprensión y configuración de Backbone Fast en switches Catalyst.
Para obtener más información sobre los temporizadores de STP y las reglas para ajustarlos cuando sea absolutamente necesario, consulte el documento Comprensión y ajuste de los temporizadores de protocolo de árbol de expansión.
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 omite algunas BPDU o, por lo general, que tiene un puerto de bloqueo en transición a reenvío.
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 de solución de problemas suponen conectividad a los diferentes dispositivos de la red de puente. Esta conectividad significa que tiene acceso a la consola. Por ejemplo, durante un loop de conexión en puente probablemente no pueda realizar una conexión Telnet.
Si tiene la salida de un comando show-tech support del dispositivo Cisco, puede usar la herramienta Analizador de Cisco CLI (solo para clientes registrados) para mostrar posibles problemas y correcciones.
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 de solución de problemas simplemente utilizan comandos show para intentar identificar condiciones de error. Tener conocimientos sobre la red lo ayuda a concentrarse en los puertos críticos de los principales dispositivos.
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.
En los switches Catalyst que ejecutan CatOS, se puede verificar fácilmente el uso de la placa de circuito general con el comando show system. El comando proporciona el uso actual de la placa de circuito del switch y también especifica los picos de uso y la fecha de estos. Un pico de uso inusual le indica si ha habido alguna vez un bucle de conexión en puente en ese dispositivo.
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. La salida fácil en este caso es deshabilitar manualmente todos los puertos que proporcionan redundancia en la 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, primero deshabilite los puertos que deberían bloquearse. Cada vez que deshabilite un puerto, verifique si ha restaurado la conectividad en la red. Al identificar el puerto deshabilitado que detiene el bucle, también se identifica la ruta redundante en la que está ubicado el puerto. Si este puerto debería haber estado bloqueando, quizás haya encontrado el link en donde apareció la falla.
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.
Software Cisco IOS: Ejecute el comando exec debug spanning-tree events para habilitar la información de depuración de STP. Ejecute el registro de comandos de modo de configuración general logging buffered para capturar esta información de depuración en los búferes del dispositivo.
CatOS:El comando set logging level spantree 7 default aumenta el nivel predeterminado de eventos que se relacionan con STP en el nivel de depuración. Asegúrese de registrar un número máximo de mensajes en los búferes del switch con el comando set logging buffer 500 .
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.
Los puertos críticos que deben analizarse primero son los puertos de bloqueo. Aquí se presenta una lista de lo que puede buscar en los distintos puertos, con una descripción rápida de los comandos a ejecutar para switches que ejecutan el software CatOS y Cisco IOS.
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.
Software Cisco IOS: En la versión 12.0 o posterior de software Cisco IOS, el resultado del comando show spanning-tree bridge-group # 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.
Si no tiene el campo BPDU en el resultado del comando show spanning-tree, puede habilitar la depuración de STP con el comando debug spanning-tree para verificar la recepción de BPDU.
CatOS: El comando show mac module/port le indica el número de paquetes de multidifusión que recibe un puerto específico. Pero el comando más simple que se debe usar es el comando show spantree statistics module#/port# vlan#. Este comando muestra la cantidad exacta de BDPU de configuración recibida por un puerto específico, en una VLAN específica. Un puerto puede pertenecer a varias VLAN, si es troncal. Consulte la sección Un comando de CatOS adicional de este documento.
Para buscar una discordancia de dúplex, debe comprobar cada lado del enlace punto a punto.
Software Cisco IOS: ejecute el comando show interfaces [interface interface-number] status para verificar la velocidad y el estado de dúplex del puerto específico.
CatOS: Las primeras líneas del resultado del comando show port module#/port# le dan la velocidad y el dúplex según la configuración del puerto.
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.
Software Cisco IOS: Utilice el comando show interfaces para determinar el uso en una interfaz. Existen varios campos que lo ayudan en esta determinación, como carga y entrada/salida de paquetes. Consulte el documento Solución de problemas del puerto para switch y la interfaz para obtener una explicación de la salida del comando show interfaces.
CatOS: El comando show mac module#/port# muestra las estadísticas sobre los paquetes que recibe y envía un puerto. El comando show top evalúa automáticamente el uso del puerto en un período de 30 segundos y muestra el resultado. El comando clasifica los resultados según el porcentaje de uso del ancho de banda, si bien hay otras opciones disponibles para la clasificación de los resultados. Además, el comando show system proporciona una indicación del uso de la placa de circuito, si bien el comando no apunta a un puerto específico.
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.
Consulte el documento Solución de problemas del puerto para switch y la interfaz para obtener una explicación de la salida del comando show interfaces.
CatOS: El comando show port module #/port# proporciona algunos detalles con los campos Align-Err, FCS-Err, Xmit-Err, Rcv-Err y Undersize. El comando show counters module #/port# proporciona estadísticas aun en mayor detalle.
El comando show spantree statistics module#/port# vlan# proporciona información muy precisa sobre un puerto específico. Ejecute este comando en los puertos que crea oportunos y preste especial atención a estos campos:
Forward trans count: Este contador registra cuántas veces el puerto pasa de aprendizaje a reenvío. En una topología estable, este contador siempre muestra 1. Este contador se restablece en 0 a medida que se desactiva y activa el puerto. Por lo tanto, un valor mayor que 1 indica que la transición experimentada por el puerto es el resultado de un nuevo cálculo de STP. La transición no es el resultado de un error de enlace directo.
Max age expiry count: Este contador registra el número de veces que caduca la duración máxima en este enlace. Básicamente, un puerto que espera BPDU espera la duración máxima antes de considerar que se perdió el puente designado. La edad máxima predeterminada son 20 segundos. Cada vez que ocurre este evento, el contador se incrementa. Cuando el valor no es 0, indica que el puente designado para esta LAN es inestable o tiene un problema con la transmisión de BPDU.
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. Para los switches de la serie 4500/4000 de Catalyst que ejecutan CatOS o el software Cisco IOS, consulte el documento Uso de la CPU en los switches Catalyst 4500/4000, 2948G, 2980G y 4912G.
CatOS: Ejecute el comando show proc cpu para mostrar la información referente al uso de la 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 comando show spantree summary para los switches que ejecutan CatOS o el comando show spanning-tree summary totals para los switches que ejecutan el software Cisco IOS. Estos comandos muestran la cantidad de puertos lógicos o interfaces por VLAN en la columna activa de STP. 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 los puertos lógicos en el switch es:
(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:
Plataforma | Restricciones de STP para CatOS | Restricciones de STP para el software Cisco IOS |
---|---|---|
Motor de supervisión I y II Catalyst 6500/6000 | Solución de problemas de STP | |
Motor supervisor 720 Catalyst 6500/6000 | Solución de problemas de STP | Solución de problemas de árbol de expansión |
Catalyst 4500/4000 | Spanning Tree | Solución de problemas de árbol de expansión |
Catalyst 3750 | Configuración de STP |
La solución de problemas trata de identificar lo que no funciona correctamente en la red. Deberá inhabilitar tantas funciones como sea posible. La dehabilitación permite simplificar la estructura de la red y facilita la identificación del problema. Por ejemplo, EtherChanneling es una función que requiere que el STP agrupe lógicamente varios enlaces diferentes dentro de uno solo; la deshabilitación de esta función durante la solución de problemas tiene sentido. Como regla general, cuanto más simple es la configuración, más sencilla es la solución de cualquier problema.
show interfaces
show spanning-tree
show bridge
show processes cpu
debug spanning-tree
logging buffered
show port
show mac
show spantree
show spantree statistics
show spantree blockedports
show spantree summary
show top
show proc cpu
show system
show counters
set spantree root [secondary]
configura el link ascendente rápido del árbol de expansión
set logging level
set logging buffered
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 bridge A es root, el router y el servidor son accesibles 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 importante: Para cada VLAN, codifique el puente de ruta y el puente de ruta de respaldo con una reducción en el valor del parámetro de prioridad STP. O bien, puede usar la macro set spantree root.
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 importante: Para cada VLAN, sepa qué puertos deben bloquearse en la red estable. Obtenga un diagrama que muestre con claridad cada bucle físico de la red y qué puertos bloqueados interrumpen los bucles.
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.
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.
No necesita más de dos enlaces redundantes entre dos nodos en una red conectada en puente. De todas formas, este tipo de configuración es común:
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; El dest 3 sólo conecta usuarios en la VLAN 3. De forma predeterminada, los troncales llevan todas las VLAN definidas en el dominio de protocolo de enlace troncal de VLAN (VTP). Solo Dist 2 recibe tráfico de difusión y de multidifusión innecesario para VLAN 3, pero también bloquea uno de sus puertos para VLAN 3. El resultado es tres rutas redundantes entre el núcleo A y el núcleo B. Esta redundancia tiene como consecuencia más puertos bloqueados y una mayor probabilidad de bucle.
Nota importante: Quite las VLAN que no necesite de los enlaces troncales.
El recorte VTP puede facilitar esto, pero en realidad ese tipo de función plug and play no se necesita en el núcleo de la red.
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.
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.
Ahora, los switches de Capa 3 de última generación de Cisco son capaces de realizar esta segunda función a la misma velocidad que la función de conmutación 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. La VLAN 2 y VLAN 3 ya no están conectadas en puente entre el núcleo A y el B, por lo que no existe la posibilidad de crear un bucle de STP.
La redundancia aún está presente, con una dependencia en los protocolos de routing de la Capa 3. El diseño asegura una nueva convergencia que incluso es más rápida que la nueva convergencia con STP.
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 existe penalidad de velocidad, ya que abandonar la VLAN 3 mediante conmutación de Capa 3 es tan rápido como realizar una conexión en puente 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.
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.
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. En particular, cada paquete de difusión o multidifusión se envía a la CPU. 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.
Hasta hace poco, no se podía eliminar la VLAN 1 desde un enlace troncal en una 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 5.4 de CatOS y la versión 12.1(11b)E del software del IOS de Cisco, puede quitar la VLAN 1 de los troncales. La VLAN 1 aún existe, pero bloquea el tráfico, lo que evita cualquier posibilidad de bucle.