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

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
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).
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?
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.
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
© 1992-2016 Cisco Systems Inc. Todos los Derechos Reservados.
Fecha de Generación del PDF: 16 Enero 2016
http://www.cisco.com/cisco/web/support/LA/102/1024/1024739_17.html