Cómo Comprender los Cambios de Topología de Protocolo de Spanning Tree

Transcripción

1 Cómo Comprender los Cambios de Topología de Protocolo de Spanning Tree Interactivo: Este documento ofrece un análisis personalizado de su dispositivo Cisco. Contenido Introducción prerrequisitos Requisitos Componentes Utilizados Convenciones Propósito del mecanismo de cambio de topología Principio de operación Notifique el Root Bridge Transmita el evento a la red Qué se debe hacer cuando existen muchos cambios de tipología en la red? Tráfico inundado Problema en entornos conectados con puente ATM LANE Evite la generación de TCN con el comando portfast Realizar un seguimiento de la fuente de un TCN Conclusión Información Relacionada Introducción Cuando usted monitorea las operaciones del Spanning-Tree Protocol (STP), usted puede ser referido cuando usted ve a los contadores de cambio en la topología que incrementan en el registro de las estadísticas. Los cambios de topología son normales en STP. Pero, demasiados de ellos pueden tener un impacto en los rendimientos de la red. Este documento explica que el propósito de esta topología es: Cambie el mecanismo en el Por VLAN Spanning Tree (PVST) y los entornos PVST+. Determine qué dispara el cambio en la topología. Describa los problemas relacionados con el Mecanismo de cambio de la topología. prerrequisitos Requisitos No hay requisitos específicos para este documento. Componentes Utilizados 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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando. Convenciones Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco. Propósito del mecanismo de cambio de topología Aprendiendo de los marcos que recibe, un Bridge crea una tabla que asocie a un puerto los Media Access Control (MAC) Address de los host que

2 se pueden alcanzar a través de este puerto. Esta tabla se usa para enviar tramas directamente a sus respectivos puertos de destino. Por lo tanto, se evita una sobrecarga. El tiempo de envejecimiento predeterminado para esta tabla es 300 segundos (cinco minutos). Sólo después de que un host ha estado en silencio durante cinco minutos, su entrada desaparece de la tabla del puente. Aquí está un ejemplo que muestra porqué usted podría quisiera que este envejecimiento fuera más rápido: En esta red, asuma que el Bridge B1 está bloqueando su link al B4. A y B son dos estaciones que tienen una conexión establecida. El tráfico de A a B va al B1, al B2, al B3, y entonces al B4. El esquema muestra las direcciones MAC aprendidas por los cuatro puentes en esta situación: Ahora, asuma que el link entre el B2 y el B3 falla. La comunicación entre A y B se interrumpe por lo menos hasta que el B1 ponga su puerto al B4 en el modo de reenvío (un máximo de 50 segundos con los parámetros predeterminados). Sin embargo, cuando A quiere enviar una trama a B, el B1 todavía tiene una entrada que ése lleva al B2 y el paquete se envía a un agujero negro. Lo mismo se aplica cuando B desea alcanzar a A. La comunicación se pierde durante cinco minutos, hasta que venzan las entradas para las direcciones MAC de A y B. Las bases de datos de reenvío implementadas por los puentes son muy eficaces en una red estable. Pero, hay muchas situaciones donde el tiempo de envejecimiento de cinco minutos está un problema después de que la topología de la red haya cambiado. El mecanismo de cambio de topología es una solución alternativa para esa clase de problema. Tan pronto como un Bridge detecte un cambio en la topología de la red (un link que va abajo o va al envío), hace publicidad del evento a la red interligada en su totalidad. La sección Principio de funcionamiento explica cómo se implementa prácticamente. Cada Bridge después se notifica y reduce el tiempo de envejecimiento al forward_delay (15 segundos por abandono) por cierto período de tiempo (max_age + forward_delay). Es más beneficioso reducir el tiempo de envejecimiento en vez de borrar la tabla porque actualmente - los host activos, eso transmiten con eficacia el tráfico, no se borran de la tabla. En este ejemplo, tan pronto como el Bridge B2 o B3 detecte el link el ir abajo, envía las notificaciones del cambio de la topología. Todos los Bridges son enterados del evento y reducen su tiempo de envejecimiento a 15 segundos. Pues el B1 no recibe ningún paquete de B en su puerto que lleva al B2 en quince segundos, envejece hacia fuera la entrada para B en este puerto. Sucede lo mismo con la entrada para A en el puerto que conduce a B3 o B4. Más adelante cuando el link entre el B1 y el B4 va al envío, el tráfico se inunda y se vuelve a aprender inmediatamente en este link. Principio de operación Esta sección explica cómo un Bridge anuncia un cambio de la topología a nivel del Bridged Protocol Data Unit (BPDU).

3 Se ha explicado ya abreviadamente cuando un Bridge la considera detectada un cambio de la topología. La definición exacta es: Cuando un puerto que estaba reenviando se desconecta (bloqueo, por ejemplo). Cuando un puerto transiciona a reenvío y el puente tiene un puerto designado. (Esto significa que el Bridge no es independiente.) El proceso para enviar una notificación a todos los puentes en la red incluye dos pasos: El puente avisa al puente de la raíz del árbol de expansión. El Root Bridge transmite la información en la red completa. Notifique el Root Bridge En la operación STP normal, un Bridge guarda el recibir de los BPDU de configuraciones del Root Bridge en su puerto raíz. Pero, nunca envía un BPDU hacia el Root Bridge. Para alcanzar eso, un BPDU especial llamado el Topology Change Notification (TCN) BPDU se ha introducido. Por consiguiente, cuando un puente necesita señalizar un cambio de topología, comienza a enviar TCN en su propio puerto raíz. El puente designado recibe la TCN, la reconoce y genera otra para su propio puerto raíz. El proceso continúa hasta que TCN encuentra el puente raíz. TCN es una BDPU muy simple sin información alguna que un puente envía cada hello_time segundos (esto es hello_time configurado de manera local, no hello_time especificado en las BDPU de configuración). El puente designado reconoce al TCN enviando inmediatamente de regreso una configuración BPDU normal con el conjunto de bits del Reconocimiento de cambio de topología (TCA). El puente que notifica el cambio de topología no deja de enviar su TCN hasta que el puente designado lo reconoce. Por lo tanto, el Bridge designado contesta al TCN aunque no recibe el BPDU de configuración de su raíz. Transmita el evento a la red Una vez que la raíz es consciente que ha habido un evento de cambio de la topología en la red, comienza a enviar sus BPDU de configuraciones con el conjunto de bits del cambio de la topología (TC). Estas BPDU son retransmitidas por cada puente en la red con este conjunto de bits. Como consecuencia todos los Bridges son enterados de la situación del cambio de la topología y puede reducir su tiempo de envejecimiento al forward_delay. Los Bridges reciben el cambio de la topología BPDU en la expedición y los puertos de bloqueo. El bit de TC está definido por la raíz de un período de antigüedad máxima + retardo de reenvío en segundos, que es 20+15=35 segundos de forma predeterminada. Qué se debe hacer cuando existen muchos cambios de tipología en la red?

4 Aquí están algunos de los problemas que se pueden generar por el TCN. Es seguido por una cierta información sobre cómo limitar los cambios de la topología y el hallazgo de donde vienen. Si usted tiene la salida de un comando show-tech support de su dispositivo de Cisco, usted puede utilizar el Output Interpreter (clientes registrados solamente) para visualizar los problemas potenciales y los arreglos. Para usar Output Interpreter (sólo para clientes registrados), debe estar registrado como cliente, conectado y tener habilitado JavaScript. Tráfico inundado Cuantos más hosts haya en la red, más serán las probabilidades de lograr un cambio en la topología. Por ejemplo, un host directamente asociado acciona un cambio de la topología cuando es poder completado un ciclo. En las redes muy grandes (y planas), una punta puede ser alcanzada donde está la red perpetuo en un estatus del cambio de la topología. Esto es como si el tiempo de envejecimiento se configure a quince segundos, que lleva a un nivel elevado de inundación. Aquí está un peor de los casos que sucedió a un cliente que hacía un cierto backup del servidor. La desactualización de la entrada para el dispositivo que recibe la copia de respaldo fue desastrosa ya que hizo que los usuarios recibieran un volumen de tráfico muy pesado. Vea la generación de TCN del evitar con la sección de comando portfast para más información sobre cómo evitar la generación de TCN. Problema en entornos conectados con puente ATM LANE Este caso es más crítico que la inundación normal del tráfico implicada por una desactualización rápida. En el recibo de un cambio de la topología para un VLA N, un switch de Catalyst tiene sus cuchillas del LAN Emulation (LANE) que reconfirman su tabla LE-ARP para la correspondencia LAN emulada (ELAN). Mientras que cada Tarjeta LANE en el ELAN publica al mismo tiempo la misma petición, puede poner una alta tensión en el LAN Emulation Server (LES) si hay muchas entradas a reconfirmar. Los problemas de conectividad se han considerado en este escenario. Si la red es sensible a un cambio de la topología, el problema real es no el cambio de la topología sí mismo sino el diseño de la red. Se recomienda que usted limita tanto cuanto sea posible la generación de TCN para salvar el CPU del LES (por lo menos). Vea la generación de TCN del evitar con la sección de comando portfast para más información sobre cómo limitar la generación de TCN. Evite la generación de TCN con el comando portfast La característica portfast es un cambio propietario de Cisco en la implementación de STP. Este comando se aplica a puertos específicos y tiene dos efectos: Los puertos que aparecen se colocan directamente en el modo STP de reenvío, en lugar de atravesar el proceso de escucha y aprendizaje. El STP aún se ejecuta en los puertos con portfast. El Switch nunca genera un TCN cuando va un puerto configurado para el portfast hacia arriba o hacia abajo. Habilite el portfast en los puertos donde están muy probables los host conectados traer su link hacia arriba y hacia abajo (típicamente las estaciones terminales que los usuarios accionan con frecuencia el ciclo). Esta función no debe ser necesaria para los puertos de servidores. Debe ser evitada definitivamente en los puertos que llevan al Hubs u otro interliga. Un puerto que las transiciones al estado de reenvío en un link redundante pueden causar directamente el bridging temporal coloca. Los cambios de topología pueden ser útiles, por lo tanto, no habilite PortFast en un puerto en el que un link ascendente o descendente sea un evento importante para la red.

5 Realizar un seguimiento de la fuente de un TCN En sí mismo, un Topology Change Notification no es una mala cosa, sino como un buen administrador de la red, es mejor conocer su origen en la orden para estar seguro que no están relacionados con un problema real. La identificación del Bridge que publicó el cambio de la topología no es una tarea fácil. Sin embargo, no es técnico compleja. La mayoría de la cuenta de los Bridges solamente el número de TCN que han publicado o recibido. Los Catalyst 4500/4000, 5500/5000 y 6500/6000 son capaces de mostrar el puerto y la ID del puente que envió la última modificación de topología que recibieron. A partir de la raíz, es entonces posible ir rio abajo al Bridge del iniciador. Para obtener más información, consulte el comando show spantree statistics. Si usted tiene la salida de un comando show spantree statistics de su dispositivo de Cisco, utilice el Output Interpreter (clientes registrados solamente) para visualizar los problemas potenciales y los arreglos. Para usar Output Interpreter (sólo para clientes registrados), debe estar registrado y tener habilitado JavaScript. Conclusión Un punto importante a considerar aquí es que un TCN no comienza un recálculo de STP. Este miedo viene del hecho de que los TCN están asociados a menudo a los entornos STP inestables; Los TCN son una consecuencia de esto, no una causa. El TCN tiene solamente un impacto en el tiempo de envejecimiento. No cambia la topología ni crea un loop. El número o la velocidad de los cambios en la topografía no representan un problema en sí. El problema es conocer lo que significa el cambio de la topología. Una red ítegra puede experimentar una alta velocidad de cambio de la topología. Pero, un cambio de la topología se debe relacionar idealmente con un evento importante en la red como un servidor que vaya hacia arriba o hacia abajo o un link que las transiciones. Esto se consigue habilitando portfast en los puertos que se activan y desactivan como parte de su funcionamiento normal. Información Relacionada Notas Técnicas de Troubleshooting Cisco Systems Inc. Todos los Derechos Reservados. Fecha de Generación del PDF: 16 Enero