El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe las recomendaciones para implementar una red segura sobre la conexión en puente de los switches Cisco Catalyst que ejecutan el software Cisco IOS®.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
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. 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:
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:
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.
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 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.
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 configura manualmente el modo dúplex en Completo en un lado del link y deja el otro lado en modo de negociación automática, el link 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 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 es un problema para A; el bridge A detecta una colisión y ejecuta el algoritmo de backoff antes de que el bridge intente otra transmisión de la trama. 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:
%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.
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 dúplex, un reinicio ayuda temporalmente; pero en este caso, un reinicio de los puentes no tiene absolutamente 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 Configuración de la Función de Protocolo UDLD.
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. 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.
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.
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 utilice la función PortFast en puertos de switch o interfaces que se conectan a otros switches, hubs o routers. De lo contrario, 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 bucle se detiene apenas p1 o p2 reciben una BPDU que coloca 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.
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 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 spanning-tree uplinkfast para Cisco IOS Software aumenta la prioridad del switch de modo que el switch no pueda ser root. 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 spanning-tree backbonefast para Cisco IOS Software puede aumentar 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.
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.
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.
Nota: Solo los usuarios registrados de Cisco tienen acceso a la información y las herramientas internas de Cisco.
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 show comandos para intentar identificar 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. 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, inhabilite inicialmente los puertos que pueden estar bloqueando. 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 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 el número de dispositivos a 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 loop.
-
Cisco IOS Software-Ejecute el comando exec debug spanning-tree events para habilitar la información de depuración STP. Ejecute el comando general config mode logging buffered para capturar esta información de depuración en los buffers del dispositivo.
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-En Cisco IOS Software Release 12.0 o posterior, la salida del show spanning-tree vlan <vlan-id> detail comando 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
-
Cisco IOS Software-Busque incrementos de error en el contador de errores de entrada del show interfaces comando. 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 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:
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 |
Inhabilitación de funciones innecesarias
Al resolver problemas, intenta identificar qué hay actualmente mal 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 STP agrupe lógicamente varios links diferentes en un solo link; la inhabilitación de esta función durante el proceso de solución de problemas tiene sentido. Como regla general, hacer la configuración lo más simple posible hace que el proceso de solución de problemas del problema sea mucho más fácil.
Comandos útiles
Comandos del Cisco IOS Software
-
show interfaces
-
show spanning-tree
-
show bridge
-
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 bridge B es root, el link A a C está bloqueado en el bridge A o en el bridge 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 A es el puente de ruta, se puede llegar al router y al servidor 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, incluya en el código duro el puente raíz y el puente raíz de respaldo una reducción en el valor del parámetro de prioridad STP. O bien, puede usar la macro set spantree root.
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
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 el Dist 2 están todos en la VLAN 2; el Dist 3 sólo conecta a los usuarios en la VLAN 3. De forma predeterminada, los trunks transportan todas las VLAN definidas en el dominio VLAN Trunk Protocol (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: Elimine cualquier VLAN que no necesite de sus troncos.
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.
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. 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 garantiza una reconvergencia que es incluso más rápida que la reconvergencia 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 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 generalmente no hace un uso intensivo del procesador; el switching de paquetes no involucra a 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. 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.
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 aún existe, pero bloquea el tráfico, lo que evita cualquier posibilidad de bucle.
Información Relacionada
Revisión | Fecha de publicación | Comentarios |
---|---|---|
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 |