Problemas del Spanning Tree Protocol y consideraciones de diseño relacionadas

Transcripción

1 Problemas del Spanning Tree Protocol y consideraciones de diseño relacionadas Este documento contiene animaciones Flash. Interactivo: Este documento ofrece un análisis personalizado de su dispositivo Cisco. Contenidos Introducción Requisitos previos Requisitos Componentes utilizados Convenciones Antecedentes Error del Spanning Tree Protocol Convergencia del árbol de expansión Discordancia dúplex Enlace unidireccional Corrupción de paquetes Errores de recursos Error de configuración de PortFast Ajuste complicado de parámetros STP y problemas de diámetro Errores de software Resolución de problemas producidos por errores Utilice el diagrama de la red Identificación de un bucle de conexión en bridge Restaurar rápidamente la conectividad y prepararse para otro momento Verificación de los puertos Búsqueda de errores de recursos Inhabilitación de funciones innecesarias Comandos útiles Diseño de STP para evitar inconvenientes Conocer la ubicación de la raíz Conozca dónde existe redundancia Minimizar la cantidad de puertos bloqueados Mantener STP incluso si no es necesario Mantener la VLAN administrativa sin tráfico y evitar que una única VLAN se expanda por toda la red Información relacionada Introducción Este documento presenta una lista de recomendaciones para facilitar la implementación de una red segura con respecto a una conexión en bridge para los switches Catalyst de Cisco que ejecutan el software Catalyst OS (CatOS) y el software Cisco IOS. Este documento analiza algunas de las razones comunes de error del Protocolo del árbol de expansión (STP) y la información que se debe buscar para identificar el origen del problema. El documento también muestra el tipo de diseño que minimiza los problemas relacionados con el árbol de expansión que es fácil de solucionar. Requisitos previos Requisitos No hay requisitos específicos para este documento.

2 Componentes utilizados Este documento no tiene restricciones específicas en cuanto a versiones de software y hardware. Convenciones Para obtener más información sobre las convenciones del documento, consulte las Convenciones sobre consejos técnicos de Cisco. Antecedentes Este documento no hace referencia al funcionamiento básico de STP. Para obtener información acerca de cómo funciona STP, consulte este documento: Introducción y configuración del Spanning Tree Protocol (STP) en los switches Catalyst Este documento no analiza el STP rápido (RSTP) definido en la norma IEEE 802.1w. Por tanto, este documento no analiza el Protocolo del á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 los siguientes documentos: Understanding Multiple Spanning Tree Protocol (802.1s) (Introducción al Spanning Tree Protocol múltiple (802.1s)) Introducción al Protocolo de árbol transversal rápido (802.1w) Para obtener información más específica sobre la resolución de problemas del STP para los switches Catalyst que ejecutan el software Cisco IOS, consulte el documento Troubleshooting STP on Catalyst Switch Running Cisco Integrated IOS (Native Mode) (Resolución de problemas de STP en switches Catalyst que ejecutan el IOS integrado de Cisco (modo nativo)). Error del Spanning Tree Protocol 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 bridge. El STP funciona en la Capa 2 del modelo de Interconexión de sistemas abiertos (OSI). Mediante las unidades de datos del protocolo del bridge (BPDU) que se intercambian entre los bridges, el STP selecciona los puertos, que eventualmente, 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, en función del diseño de la red. En esta área determinada, usted desempeña la parte más importante del proceso de resolució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 bridge. La mayoría de clientes que llaman al Soporte técnico de Cisco por problemas en el árbol de expansión sospechan que se ha producido un error de funcionamiento, pero ésta es raramente la causa. Incluso si el software es el problema, un bucle de conexión en bridge en un entorno STP aún proviene de un puerto que debería estar bloqueando tráfico, pero que en cambio lo está reenviando Convergencia del árbol de expansión Consulte la animación flash del árbol de expansión para obtener un ejemplo que explique cómo converge inicialmente el árbol de expansión. El ejemplo también explica por qué una puerto bloqueado pasa al modo de reenvío debido a una pérdida excesiva de BPDU, lo que resulta en un error 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 Si configura manualmente el modo dúplex completo en un lado del enlace y deja el otro lado en modo de negociación automática, el enlace termina en semidúplex. (Un puerto configurado con modo dúplex completo ya no negocia más).

3 El peor de los escenarios se produce cuando un bridge que envía BPDU tiene configurado el modo semidúplex en un puerto, pero el puerto de par del otro final del enlace tiene configurado el modo dúplex completo. En el ejemplo mencionado, la discordancia dúplex en el enlace entre el bridge A y el B puede conducir fácilmente a un bucle de conexión en bridge. Debido a que el bridge 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 bridge B empieza a enviar tramas, incluso si el bridge A ya está utilizando el enlace. Esta situación supone un problema para A; el bridge A detecta una colisión y ejecuta el algoritmo de rango de espera (backoff) antes de que el bridge vuelva a intentar la transmisión de la trama. Si hay suficiente tráfico de B a A, cada paquete que envía A, que incluye las BPDU, es sometido a un aplazamiento o colisión y, eventualmente, se descarta. Desde el punto de vista de STP, puesto que el bridge B ya no recibe las BPDU desde A, el bridge B ha perdido el bridge raíz. En consecuencia, B desbloquea el puerto conectado al bridge C, lo que crea el bucle. Siempre que haya una discordancia dúplex, aparecen estos mensajes de error en las consolas de los switches Catalyst que ejecutan el software CatOS y Cisco IOS: CatOS CDP-4-DUPLEXMISMATCH: Full/half duplex mismatch detected on port [mod]/[port] Software Cisco IOS %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet5/1 (not half duplex), with TBA (Cat6K-B) 4/1 (half duplex). Controle los ajustes de dúplex y, si la configuración de dúplex no coincide, configúrela de forma adecuada. Para obtener más información sobre cómo solucionar una discordancia dúplex, consulte el documento Configuración y resolución de problemas de negociación automática semidúplex/dúplex completo de Ethernet 10/100/1000Mb. Enlace unidireccional Los enlaces unidireccionales son una causa común del bucle de conexión en bridge. En los enlaces de fibra, un error no detectado suele ocasionar enlaces unidireccionales. También puede provocar un problema con un transceptor. Todo lo que pueda provocar 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 descarta el tráfico desde A hacia B mientras transmite tráfico desde B hacia A. Suponga que el bridge B estaba bloqueando antes de que el enlace se convirtiera en unidireccional. No obstante, un puerto sólo puede bloquear si recibe BPDU desde un bridge con una prioridad más alta. En este caso, como todas las BPDU que provienen de A se han perdido, es posible que el bridge B cambie su puerto hacia A al estado de reenvío y reenvíe el tráfico. De esta forma, se crea un bucle. Si este error 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 bridges no tiene ningún efecto. Para detectar los enlaces unidireccionales antes de que se cree un bucle de reenvío, Cisco ha diseñado e implementado el protocolo de Detección de enlace unidireccional (UDLD). Esta función puede detectar un cableado incorrecto o enlaces unidireccionales en la Capa 2 e interrumpir automáticamente los bucles resultantes desactivando algunos puertos. Ejecute UDLD siempre que sea posible en un entorno con bridges. Si desea obtener más información sobre el uso de UDLD, consulte el documento Understanding and Configuring the Unidirectional Link

4 Detection Protocol Feature (Introducción y configuración de la función del Protocolo de detección de enlace unidireccional). Corrupción de paquetes La corrupción de paquetes también puede conducir a la misma clase de error. Si un enlace tiene un gran número de errores físicos, puede perder una gran 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 necesita perder las BPDU durante 50 segundos antes de cambiar al estado de reenvío. La transmisión con éxito de una sola BPDU interrumpe el bucle. Este caso ocurre habitualmente cuando los parámetros de STP se han ajustado sin tener cuidado. Un ejemplo de ajuste es la reducción de edad máxima. La discordancia dúplex, los cables defectuosos o la longitud incorrecta de los cables pueden provocar la. corrupción del paquete. Consulte el documento Troubleshooting Switch Port and Interface Problems (Resolución de problemas de la interfaz y del puerto del switch) para obtener una explicación del resultado de los contadores de errores del software CatOS y Cisco IOS. Errores de recursos STP se implementa en el software, incluso en switches de alta capacidad que realizan la mayoría de las funciones de conmutación en el hardware mediante circuitos integrados específicos de la aplicación (ASIC). Si, por cualquier motivo, se produce un uso excesivo de la CPU del bridge, es posible que los recursos sean inadecuados para la transmisión de las BPDU. El STA generalmente no hace un uso intensivo del procesador y tiene prioridad por encima de otros procesos. La sección Búsqueda de errores de recursos de este documento aporta algunas pautas sobre el número de ejemplos de STP que puede gestionar una plataforma específica. Error de configuración de PortFast PortFast es una función que normalmente se habilita sólo para un puerto o interfaz que conecta a un host. Cuando el enlace se presenta en este puerto, el el bridge omite las primeras etapas del STA y pasa directamente al modo de reenvío. Precaución: No utilice la función PortFast en los puertos de switch o en las interfaces que conectan a otros switches, concentradores o routers. De lo contrario, se puede crear un bucle de red. En este ejemplo, el dispositivo A es un bridge con un puerto p1 que ya reenvía. El puerto p2 tiene una configuración para PortFast. El dispositivo B es un concentrador. En cuanto haya conectado 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 recibe una BPDU que coloca a uno de estos dos puertos en modo de bloqueo. Pero existe un problema con este tipo de bucle transitorio. Si el tráfico de bucle es muy intenso, es probable que el bridge tenga problemas para enviar con éxito la BPDU que detiene el bucle. Este problema puede retrasar la convergencia de manera considerable o, en casos extremos, hacer que la red se cuelgue. 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 Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays (Uso de Portfast y otros comandos para solucionar retrasos de conectividad al iniciar la estación de trabajo). Incluso con la configuración de PortFast, el puerto o la interfaz sigue participando en STP. Si se conecta un switch con una prioridad de bridge más baja que la del bridge raíz actual activo al puerto o a la interfaz configurada para PortFast, puede ser seleccionado como bridge raíz. Este cambio de bridge raíz puede afectar negativamente a 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 BPDU desactiva un puerto o una interfaz configurada para PortFast, si el puerto o la interfaz recibe una BPDU. Para obtener más información sobre el uso de la función de Protección BPDU en los switches que ejecutan el software CatOS y Cisco IOS, consulte el documento Ampliación de la seguridad en el árbol de expansión Portfast BPDU. Ajuste complicado de parámetros STP y problemas de diámetro Un valor radical para el parámetro de edad máxima y el retraso de envío puede conducir a una topología STP muy inestable. En estos casos, la pérdida de algunas BPDU puede tener como consecuencia la aparición de un bucle. Otro problema, que no es muy conocido, está relacionado con el diámetro de la red con bridges. Los valores predeterminados conservadores de los temporizadores STP imponen un diámetro máximo de red de

5 siete. Este diámetro máximo de red limita la distancia posible entre los bridges de la red. En este caso, dos bridges distintos no deben estar a más de siete saltos de distancia entre sí. Parte de esta restricción proviene del campo de edad que tienen las BPDU. Cuando una BPDU se propaga del bridge raíz hacia las hojas del árbol, el campo de edad aumenta cada vez que la BPDU pasa por un bridge. Eventualmente, el bridge descarta la BPDU cuando el campo de edad supera la edad máxima. Si la raíz está demasiado lejos de algunos bridges de la red, puede producirse este problema. 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 de STP. Puede modificar la prioridad de bridge para seleccionar el bridge raíz y cambiar el costo de puerto o la prioridad del parámetro para controlar la redundancia y el balance de carga. El software Catalyst de Cisco pone a su disposición unas macros que ajustan con precisión los parámetros STP más importantes: El set spantree root [secondary] comando macro disminuye la prioridad de bridge, por lo que se convierte en raíz (o raíz alternativa). Hay disponible otra opción de este comando que consiste en el ajuste de los temporizadores STP especificando el diámetro de la red. Aunque se lleve a cabo correctamente, el ajuste del temporizador no mejora de una manera significativa el tiempo de convergencia y aporta ciertos riesgos de inestabilidad a la red. Asimismo, 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 de red. El comando set spantree uplinkfast para CatOS o el comando spanning-tree uplinkfast para el software Cisco IOS aumenta la prioridad del switch, por lo que éste no puede ser raíz. El comando aumenta el tiempo de convergencia de STP en el caso de error del enlace ascendente. Utilice este comando en un switch de distribución con conexión dual con switches de núcleo. Consulte el documento Understanding and Configuring the Cisco UplinkFast Feature (Introducción y configuración de la función UplinkFast de Cisco). El comando set spantree backbonefast enable para CatOS o el comando spanning-tree backbonefast para el software Cisco IOS puede aumentar el tiempo de convergencia de STP del switch en el caso de un error del enlace indirecto. BackboneFast es una función patentada de Cisco. Consulte el documento Understanding and Configuring Backbone Fast on Catalyst Switches (Introducción y configuración de Backbone Fast en switches Catalyst). Para obtener más información sobre los temporizadores STP y las reglas para ajustarlos, en caso absolutamente necesario, consulte el documento Understanding and Tuning Spanning Tree Protocol Timers (Introducción y ajuste de los temporizadores del protocolo del á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 función 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 ahora han sido tratados. Una cantidad indeterminada de factores diferentes puede llevar a un error de funcionamiento del software y tener varios efectos. No hay manera de describir adecuadamente los problemas que pueden iniciar un error de funcionamiento. La situación más peligrosa que puede resultar de los errores de software se puede dar si usted ignora algunas BPDU o, por lo general, si se produce el cambio de un puerto bloqueado a reenvío. Resolución de problemas producidos por errores 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 bridge 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 la resolución de problemas presupone una conectividad a los diferentes dispositivos de la red conectada con bridge. Esta conectividad implica que se tiene acceso a la consola local. Por ejemplo, durante un bucle de conexión en bridge probablemente no pueda realizar una conexión Telnet. Si tiene el resultado de un comando show-tech support del dispositivo Cisco, podrá utilizar la herramienta intérprete de resultados (solamente clientes registrados) para mostrar posibles problemas y sus soluciones. Utilice el diagrama de la red Antes de solucionar un bucle de conexión en bridge, como mínimo debe conocer estos problemas: La topología de la red conectada con bridge La ubicación del bridge raíz 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 es la red cuando funciona correctamente. La mayoría de los pasos para la resolución de problemas simplemente utilizan show comandos para intentar identificar las condiciones del error. Tener conocimientos sobre la red le ayudará a concentrarse en los puertos críticos de los principales dispositivos. Identificación de un bucle de conexión en bridge

6 Antes, solía ocurrir que una tormenta de difusión podía tener un efecto desastroso en la red. Actualmente, con los enlaces de alta velocidad y los dispositivos que permiten la conmutación a nivel de hardware, no es probable que un único host, por ejemplo, un servidor, haga caer la red debido a las difusiones. La mejor manera de identificar un bucle de conexión en bridge es capturando el tráfico en un enlace saturado y comprobar si se observan paquetes similares varias veces. Sin embargo, en realidad, si todos los usuarios de un dominio de bridge concreto tienen problemas de conectividad al mismo tiempo, puede sospecharse que se trata de un bucle de conexión en bridge. Verifique la utilización de los puertos de sus dispositivos y busque valores anormales. Consulte la sección Verificación de la utilización de los puertos de este documento. En los switches Catalyst que ejecutan CatOS, se puede comprobar con facilidad el uso de la placa global de interconexiones con el comando show system. El comando proporciona el uso actual de la placa de interconexiones del switch y también especifica el uso pico y la fecha en que se realizó. Un uso pico inusual le indica si ha habido alguna vez un bucle de conexión en bridge en ese dispositivo. Restaurar rápidamente la conectividad y prepararse para otro momento Desactive los puertos para interrumpir el bucle Los bucles de conexión en bridge acarrean consecuencias extremadamente graves en una red con bridges. Los administradores, en general, no tienen tiempo para buscar la causa del bucle y prefieren restaurar la conectividad lo antes posible. La salida más fácil en este caso es inhabilitar manualmente cada uno de los puertos que proporcionan redundancia en la red. Si puede identificar una parte de la red que se vea más afectada, empiece a inhabilitar los puertos de esa área. O, si es posible, primero desactive los puertos que la deberían estar bloqueando. Cada vez que desactive un puerto, verifique que hay conectividad restaurada en la red. Al identificar qué puertos desactivados interrumpen el bucle, también se identifica el trayecto redundante en el que se ubica el puerto. Si este puerto debería haber sido el causante del bloqueo, quizás haya encontrado el enlace en el que apareció el error. 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, active el registro de eventos STP en los bridges y switches de la red que experimenta el error. Si desea limitar el número de dispositivos para configurar, active este registro por lo menos en los dispositivos que alojan puertos de bloqueo; 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 comando de modo de configuración general logging buffered para capturar la 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 relacionan el STP con el nivel de depuración. Asegúrese de registrar un número máximo de mensajes en los búferes del switch utilizando el comando set logging buffer 500. También puede intentar enviar el resultado de la depuración a un dispositivo syslog. Desgraciadamente, cuando se produce un bucle de conexión en bridge, pocas veces se mantiene la conectividad con un servidor syslog. Verificación de los puertos Los puertos críticos que deben analizarse primero son los puertos de bloqueo. Esta sección proporciona una lista con lo que se debe buscar en los diferentes puertos, con una descripción rápida de los comandos que se deben ejecutar para los switches que ejecutan el software CatOS y Cisco IOS. Verificación de los puertos bloqueados que reciben BPDU Especialmente en los puertos de bloqueo y en los puertos raíz, se debe comprobar que reciben BPDU de forma periódica. Existen varios problemas que pueden llevar a un error del puerto para recibir los paquetes o las BPDU. Software Cisco IOS: en la versión 12.0 o posterior del Software Cisco IOS, el resultado del comando show spanning-tree bridge-group # tiene un campo BPDU. Este campo le indica el número de BPDU recibidas en cada interfaz. Ejecute el comando una o dos veces más para determinar si el dispositivo recibe las 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 las 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 de utilizar es el show spantree statistics module#/port# vlan#. Este comando muestra la cantidad exacta de BPDU de configuración recibidas por un puerto específico, en una VLAN específica. Un puerto puede pertenecer a varias VLAN, en caso de conexión troncal. Véase la sección Comando de CatOS adicional de este documento. Comprobación de discordancias dúplex Para buscar una discordancia dúplex, debe comprobar cada lado del enlace punto a punto. Software Cisco IOS: ejecute el comando show interfaces [interface interface-number] status para comprobar la velocidad y el estado dúplex del puerto específico. CatOS: las mismas primeras líneas del resultado del comando show port module#/port# indican la velocidad y el dúplex de acuerdo con la configuración del puerto.

7 Verificación de la utilización de los 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. Software Cisco IOS: utilice el comando show interfaces para determinar el uso de una interfaz. Hay varios campos que le pueden ayudar a llevar a cabo esta determinación, como la carga y la entrada/salida de paquetes. Consulte el documento Resolución de problemas del puerto del switch y de la interfaz para una explicación del resultado del comando show interfaces. CatOS: el comando show mac module#/port# muestra las estadísticas sobre los paquetes que un puerto recibe y envía. El comando show top evalúa automáticamente el uso del puerto en un intervalo de 30 segundos y muestra el resultado. El comando clasifica los resultados en porcentajes de uso del ancho de banda, aunque hay disponibles otras opciones de clasificación de los resultados. Además, el comando show system ofrece una indicación sobre el uso de la placa de interconexiones, aunque el comando no hace referencia a un puerto específico. Verificar el daño de paquetes Software Cisco IOS: busque aumentos de errores en el contador de errores de entrada del comando show interfaces Los contadores de errores abarcan recuentos de fragmentos minúsculos y gigantes, falta de búfer, CRC, trama, excesoy recuentos ignorados.. Consulte el documento Resolución de problemas del puerto del switch y de la interfaz para obtener una explicación del resultado del comando show interfaces. CatOS: el comando show port module#/port# ofrece información sobre los campos Align-Err, FCS-Err, Xmit-Err, Rcv- Err y Undersize (tamaño inferior al normal). El comando show counters module#/port# proporciona estadísticas todavía más detalladas. Comando de CatOS adicional El comando show spantree statistics module#/port# vlan# ofrece 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 a 0 a medida que el puerto se desactiva y activa. Por lo tanto, un valor superior a 1 indica que la transición que ha experimentado 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 la edad máxima caduca en este enlace. Básicamente, un puerto que recibe BPDU espera durante la edad máxima antes de considerar que el bridge designado se ha perdido. La edad máxima predeterminada son 20 segundos. Cada vez que ocurre este evento, el contador aumenta. Cuando el valor no es 0, indica que el bridge designado para esta LAN es inestable o tiene un problema con la transmisión de las BPDU. 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 elevada12:33 10/11/2006 para los switches Catalyst de la serie 4500/4000 que ejecutan el software CatOS o Cisco IOS, consulte el documento Utilization on Catalyst 4500/4000, 2948G, 2980G, and 4912GSwitches (Utilización de la CPU en switches Catalyst 4500/4000, 2948G, 2948G y 4912G). CatOS: ejecute el comando show proc cpu para mostrar la información referente a la utilización 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 puede gestionar un Supervisor Engine. 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 de Supervisor Engine y configuración de memoria. Ejecute el comando show spantree summary para switches que ejecutan el software CatOS o el comando show spanning-tree summary totals para switches que ejecutan el software Cisco IOS. Estos comandos muestran el número de puertos lógicos o interfaces por VLAN en la columna STP activa. 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 soportada por cada tipo de Supervisor Engine. Nota: La fórmula para calcular la suma de puertos lógicos del 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

8 Para obtener un resumen de las restricciones para STP que se aplican a los switches Catalyst consulte los siguientes documentos: Plataforma Catalyst 6500/6000 Supervisor Engine I y II Restricciones de STP para CatOS Resolución de problemas de STP Restricciones de STP para el software Cisco IOS Resolución de problemas del árbol de expansión Catalyst 6500/6000 Supervisor Engine 720 Resolución de problemas de STP Catalyst 5500/5000 Árbol de expansión Catalyst 4500/4000 Árbol de expansión Resolución de problemas del árbol de expansión Resolución de problemas del árbol de expansión Catalyst 3750 Configuración STP Catalyst 3550 Configuración de STP Catalyst 2970 Configuración STP Catalyst 2950/2955 Configuración de STP Catalyst 2940 Configuración de STP Catalyst 2900/3500XL Configuración de STP Inhabilitación de funciones innecesarias La resolución de problemas trata de identificar lo que no funciona inadecuadamente en la red. Deberá inhabilitar tantas funciones como sea posible. Esto le ayudará a simplificar la estructura de la red y le facilitará 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 desactivación de esta función durante la resolución de problemas tiene sentido. Como regla general, cuanto más simple es la configuración más sencilla es la resolución de cualquier problema. Comandos útiles Comandos del software Cisco IOS show interfaces show spanning-tree show bridge show processes cpu debug spanning-tree logging buffered Comandos de CatOS 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] set spantree uplinkfast set logging level set logging buffered Diseño de 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 en el momento de la resolución de problemas. No deje que sea el STP el que decida qué bridge es el raíz. Por cada VLAN, normalmente se puede identificar qué switch puede servir mejor de raíz. Ello depende del diseño de la red. En general, seleccione un bridge potente en el medio de la red. Si coloca el bridge raíz en el centro de la red con conexión directa a los servidores y routers, por lo general, reducirá la distancia promedio de los clientes a los servidores y routers.

9 Este diagrama indica: Si B es el bridge raíz, el enlace A hacia C está bloqueado en el bridge A o 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 bridge C pueden acceder al servidor y al router en tres saltos. La distancia promedio es de dos saltos y medio. Si A es el bridge raíz, se puede llegar al router y al servidor en dos saltos para los dos hosts que se conecten 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 bridge raíz y el bridge raíz de respaldo con una reducción del valor de la prioridad del parámetro STP. O bien puede utilizar 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 bloquean. Por lo general, este ajuste no es necesario si dispone de un diseño jerárquico y de un bridge raíz en una buena ubicación. Nota importante: Para cada VLAN, conozca qué puertos deberían actuar como bloqueos en la red estable. Tenga a disposición un diagrama de red que muestre con claridad cada bucle físico de la red y qué puertos bloqueados interrumpen los bucles. El conocimiento de la ubicación de los enlaces redundantes ayuda a identificar un bucle de conexión en bridge accidental y la causa. Además, el conocimiento de la ubicación de los puertos de bloqueo 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. A Un solo puerto de bloqueo que cambie a reenvío por equivocación puede fundir una gran parte de la red. Una buena manera para limitar el riesgo inherente del 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 se necesitan más de dos enlaces redundantes entre dos nodos en una red con bridges. De todas formas, este tipo de configuración es habitual: Los switches de distribución están vinculados en forma dual a dos switches de núcleo. Los usuarios conectados en switches de distribución sólo

10 se encuentran disponibles en un subconjunto de VLAN de la red. En este ejemplo, los usuarios conectados en Dist 2 se encuentran todos en VLAN 2; Dist 3 sólo conecta a los usuarios en VLAN 3. De manera predeterminada, las conexiones troncales transportan todas las VLAN definidas en el dominio del Protocolo de troncal VLAN (VTP). Sólo 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 son tres trayectos redundantes entre el núcleo A y el B. Esta redundancia tiene como consecuencia más puertos bloqueados y una mayor probabilidad de creación de un bucle. Nota importante: Separe cualquier VLAN que no necesite de las conexiones troncales. El recorte de VTP puede ser útil, pero este tipo de función Plug and Play no es necesaria en el núcleo de la red. En este ejemplo, únicamente se utiliza un acceso VLAN 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 eliminar enlaces redundantes en sólo un paso si se cierra el núcleo A o B. Use la conmutación de Capa 3 La conmutación de Capa 3 significa un ruteo aproximadamente a la velocidad de conmutación. Un router realiza dos funciones principales: Un router crea una tabla de reenvíos. El router generalmente intercambia información con los pares mediante protocolos de ruteo. Un router recibe paquetes y los reenvía a la interfaz correcta sobre la base de la dirección de destino. Ahora los switches de Capa 3 de alta capacidad 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 ruteo y crea una segmentación adicional de la red, no se aplica penalidad en la velocidad. El diagrama utiliza el ejemplo de la sección Separar las VLAN que no se utilizan 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 conectados en bridge entre el núcleo A y el B, por lo que no existe la posibilidad de crearse un bucle STP. La redundancia todavía está presente, con una dependencia a los protocolos de ruteo de la Capa 3. El diseño asegura una nueva convergencia que incluso es más rápida que una convergencia nueva con STP. Ya no hay ningún puerto que bloquee STP. Por consiguiente, no es posible la creación de un bucle de conexión en bridge. No se aplica penalidad de velocidad, ya que abandonar la VLAN mediante conmutación de Capa 3 es tan rápido como realizar una conexión en bridge dentro de la VLAN.

11 Hay un único inconveniente con este diseño. La migración a este tipo de diseño implica generalmente una reactualización del esquema de direccionamiento. Mantener STP incluso si no es necesario Aunque haya realizado correctamente la eliminación de todos los puertos de bloqueo de su red e incluso si no tiene ninguna redundancia física, no desactive STP. El STP, por lo general, no hace un uso muy intensivo del procesador; la CPU no participa en en la conmutación de paquetes en la mayoría de switches de Cisco. Además, las pocas BPDU enviadas a cada enlace no reducen de forma significativa el ancho de banda disponible. No obstante, una red con bridges sin STP puede desaparecer en fracciones de segundos a raíz de un error cometido por el operador en un panel de conexiones, por ejemplo. Por lo general, no es aconsejable inhabilitar el STP en una red con bridges. 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 dirigida a una VLAN, que a menudo se denomina 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 tráfico de difusión y multidifusión en la VLAN administrativa puede afectar negativamente a la CPU y a su capacidad para procesar las BPDU importantes. 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 una conexión troncal en la implementación de Cisco. La VLAN 1 normalmente desempeña la función de VLAN administrativa, en la que todos los switches tienen acceso a la misma subred IP. Aunque sea útil, esta configuración puede ser peligrosa porque un bucle de conexión en bridge en la VLAN 1 afecta a todas las conexiones troncales, lo cual puede provocar la caída de toda la red. Sin duda, el mismo problema existe independientemente de la VLAN que utilice. Intente segmentar los dominios de conexión en bridge que utilicen switches de alta velocidad de Capa 3. En la versión 5.4 de CatOS y en la versión 12.1(11b)E del software Cisco IOS, puede eliminar la VLAN 1 de las conexiones troncales. La VLAN 1 sigue existiendo, pero bloquea el tráfico, por lo que evita cualquier posibilidad de bucle Cisco Systems Inc. Todos los Derechos Reservados. Fecha de Generación del PDF: 19 Mayo