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 información sobre las mejoras agregadas por RSTP al estándar 802.1D anterior.
El estándar Spanning Tree Protocol (STP) 802.1D fue diseñado en un momento en que la recuperación de la conectividad después de una interrupción de un minuto más o menos se consideraba un rendimiento adecuado. Con la llegada del switching de capa 3 en entornos LAN, el puente compite ahora con soluciones enrutadas en las que protocolos como OSPF (Open Shortest Path First) y EIGRP (Enhanced Interior Gateway Routing Protocol) pueden proporcionar una ruta alternativa en menos tiempo.
Cisco ha mejorado la especificación 802.1D original con funciones como Uplink Fast, Backbone Fast y Port Fast para acelerar el tiempo de convergencia de una red en puente. La desventaja es que estos mecanismos son de propiedad exclusiva y requieren configuración adicional.
El protocolo de árbol de extensión rápido (RSTP; IEEE 802.1w) se puede considerar una evolución del estándar 802.1D más que una revolución. La terminología de 802.1D sigue siendo fundamentalmente la misma. La mayoría de los parámetros no se han modificado para que los usuarios familiarizados con 802.1D pueden configurar rápidamente el nuevo protocolo sin problemas. En la mayoría de los casos, RSTP se desempeña mejor que las extensiones de propiedad exclusiva de Cisco sin ninguna configuración adicional. 802.1w también puede volver a 802.1D para la interoperabilidad con puentes heredados, por puerto. Esto descarta los beneficios que presenta.
La nueva edición del estándar 802.1D, IEEE 802.1D-2004, incorpora los estándares IEEE 802.1t-2001 e IEEE 802.1w.
Esta tabla muestra el soporte de RSTP en algunas familias de switches Catalyst y el software mínimo requerido para dicho soporte.
Plataforma Catalyst | MST con RSTP | RPVST+ (también conocido como PVRST+) |
---|---|---|
Catalyst 2900 XL/3500 XL | No disponible | No disponible |
Catalyst 2940 | 12.1(20)EA2 | 12.1(20)EA2 |
Catalyst 2950/2955/3550 | 12.1(9)EA1 | 12.1(13)EA1 |
Catalyst 2970/3750 | 12.1(14)EA1 | 12.1(14)EA1 |
Catalyst 3560 | 12.1(19)EA1 | 12.1(19)EA1 |
Catalyst 3750 Metro | 12.1(14)AX | 12.1(14)AX |
Catalyst 2948G-L3/4908G-L3 | No disponible | No disponible |
Catalyst 4000/4500 (Cisco IOS®) | 12.1(12c)EW | 12.1(19)EW |
Catalyst 6000/6500 (Cisco IOS) | 12.1(11b)EX, 12.1(13)E, 12.2(14)SX | 12.1(13)E |
Catalyst 8500 | No disponible | No disponible |
El 802.1D se define en estos cinco estados de puerto diferentes:
inhabilitado
escucha
aprendizaje
bloqueo
reenvío
Consulte la tabla de la sección Estados de Puerto de este documento para obtener más información sobre los estados de puerto.
El estado del puerto es combinado, según si bloquea o reenvía el trafico, y la función que tiene en la topología activa (puerto root, puerto designado, etc.). Por ejemplo, desde un punto de vista operativo, no hay diferencia entre un puerto en el estado de bloqueo y un puerto en el estado de escucha. Ambos descartan tramas y no detectan direcciones MAC. La diferencia real está en la función que el spanning tree asigna al puerto. Podemos suponer con seguridad que un puerto de escucha es un puerto designado o root y que se encuentra en camino al estado de reenvío. Desafortunadamente, una vez en el estado de reenvío, no hay manera de deducir del estado de puerto si el puerto es root o designado. Esto contribuye para demostrar la falla de esta terminología basada en estado. RSTP desacopla la función y el estado de un puerto para tratar este problema.
Hay solo tres estado de puerto que quedan en RSTP que corresponden a los tres estado operativos posibles. Los estados de inhabilitado, bloqueo y escucha de 802.1D se fusionan en el único estado de descarte de 802.1w.
Estado de Puerto de STP (802.1D) | Estado de Puerto RSTP (802.1w) | ¿El puerto está incluido en la topología activa? | ¿El puerto detecta direcciones MAC? |
---|---|---|---|
Inhabilitado | Descarte | No | No |
Bloqueo | Descarte | No | No |
Escucha | Descarte | Yes | No |
Learning | Learning | Yes | Yes |
Reenvío | Reenvío | Yes | Yes |
La función de puerto es ahora una variable asignada a un puerto determinado. Las funciones de los puertos root y designado permanecen, mientras que la función del puerto de bloqueo se divide en las funciones de puerto alternativo y de respaldo. El algoritmo de árbol de extensión (STA) determina la función de un puerto en función de las unidades de datos de protocolo de puente (BPDU). Para simplificar las cosas, lo que hay que recordar de una BPDU es que siempre hay un método para comparar dos cualquiera de ellas y decidir si una es más útil que la otra. Esto se basa en el valor almacenado en la BPDU y, en ocasiones, en el puerto en que se recibe. Considerado esto, la información de esta sección explica los enfoques prácticos para las funciones de puerto.
Funciones de Puerto Root
El puerto que recibe la mejor BPDU en un bridge es el puerto root. Este es el puerto más cercano al puente raíz en términos de costo de trayectoria. STA selecciona un solo bridge root de toda la red puenteada (por VLAN). El bridge root envía las BPDU que son más útiles que las que envía cualquier otro bridge. El bridge root es el único bridge en la red que no tiene un puerto root. Todos los demás bridges reciben BPDU en al menos un puerto.
Función de Puerto Designado
Un puerto es designado si puede enviar la mejor BPDU en el segmento al que está conectado. Los bridges 802.1D conectan diversos segmentos entre sí, como segmentos de Ethernet, para crear un dominio puenteado. En un segmento dado, solo puede haber una trayectoria hacia el bridge root. Si hay dos trayectorias, hay un loop de bridge en la red. Todos los bridges conectados a un segmento dado escuchan las BPDU de cada uno y se ponen de acuerdo en qué bridge envía la mejor BPDU y lo convierten en el bridge designado para el segmento. El puerto en el puente que corresponde es el puerto designado para ese segmento.
Funciones de Puerto Alternativo y de Respaldo
Estas dos funciones de puerto corresponden al estado de bloqueo de 802.1d. El puerto bloqueado se define como el que no es designado o puerto raíz. Un puerto bloqueado recibe una BPDU más útil que la que envía de su segmento. Recuerde que un puerto necesita recibir BPDU para permanecer bloqueado. RSTP introduce estas dos funciones para ese propósito.
Un puerto alternativo recibe BPDU más útiles de otro bridge y es un puerto bloqueado. Esto se muestra en este diagrama:
Un puerto de respaldo recibe BPDU más útiles del mismo bridge en el que se encuentra y es un puerto bloqueado. Esto se muestra en este diagrama:
Esta distinción ya se hace internamente dentro de 802.1D. Esto es esencialmente cómo funciona UplinkFast de Cisco. La lógica es que un puerto alternativo proporciona una trayectoria alternativa hacia el bridge root y, por lo tanto, puede reemplazar al puerto root si este falla. Por supuesto, un puerto de respaldo proporciona conectividad redundante al mismo segmento y no puede garantizar una conectividad alternativa al bridge root. Por lo tanto, se excluye del grupo de uplink.
Como resultado, RSTP calcula la topología final para el spanning tree que utiliza los mismos criterios que 802.1D. No hay ningún cambio en la forma en que se utilizan las diferentes prioridades de puertos y puentes. El nombre blocking (bloqueo) se utiliza para el estado de descarte en la implementación de Cisco. Las versiones 7.1 y posteriores del CatOS aún muestran los estados de escucha y aprendizaje. Esto proporciona más información sobre un puerto de la que requiere el estándar IEEE. Sin embargo, la nueva función es que ahora hay una diferencia entre la función que el protocolo determina para un puerto y su estado actual. Por ejemplo, ahora es válido para que un puerto sea designado y bloquee al mismo tiempo. Mientras que esto ocurre típicamente por períodos de tiempo muy cortos, significa que este puerto está en un estado transitorio hacia el estado de reenvío designado.
RSTP ha introducido pocos cambios en el formato BPDU. Solamente dos indicadores, cambio de topología (TC) y reconocimiento de TC (TCA), se definen en 802.1D. Sin embargo, RSTP utiliza los seis bits del byte de indicador que permanecen para realizar:
Codificar la función y el estado del puerto que origina la BPDU
Tratar el mecanismo de propuesta/acuerdo
Para obtener una imagen de mayor resolución, vea diagramas BPDU, IEEE BPDU y BPDU de Cisco.
Nota: El bit 0 (cambio de topología) es el bit menos significativo.
Otro cambio importante es que la BPDU de RSTP ahora es del tipo 2, versión 2. La implicación es que los bridges heredados deben descartar esta nueva BPDU. Esta propiedad facilita que un puente 802.1w detecte los puentes heredados conectados a él.
Las BPDU se envían cada tiempo de saludo y ya no se transmiten simplemente. Con 802.1D, un bridge que no es root genera solamente BPDU cuando recibe una en el puerto root. Un puente transmite las BPDU más de lo que realmente las genera. Ese no es el caso con 802.1w. Un bridge envía una BPDU con su información actual cada <hello-time> segundos (2 de forma predeterminada), incluso si no recibe ninguna del root bridge.
En un puerto dado, si los hellos no se reciben tres veces consecutivas, la información de protocolo puede vencerse inmediatamente (o si expira el vencimiento máximo). Debido a la modificación del protocolo antes mencionada, las BPDU ahora se utilizan como un mecanismo de keepalive entre bridges. Un bridge considera que pierde conectividad a su bridge designado o root vecino directo si faltan las tres BPDU consecutivas. Este rápido envejecimiento de la información permite una rápida detección de fallas. Si un bridge no puede recibir las BPDU de un vecino, es cierto que la conexión a ese vecino se pierde. Esto se opone a 802.1D, donde el problema puede estar en cualquier lugar de la ruta a la raíz.
Nota: Las fallas se detectan aún más rápido en caso de fallas de link físico.
Este concepto conforma el centro del motor de BackboneFast. El comité IEEE 802.1w incorporó un mecanismo similar en RSTP. Cuando un bridge recibe información inferior desde su bridge designado o root, la acepta inmediatamente y reemplaza la almacenada previamente.
Debido a que el Bridge C todavía sabe que la root está activa y bien, envía inmediatamente una BPDU al Bridge B que contiene información sobre el bridge root. Como resultado, el Bridge B no envía sus propias BPDU y acepta el puerto que lleva al Bridge C como el nuevo puerto root.
La transición rápida es la función más importante introducida por 802.1w. El STA heredado esperaba pasivamente la convergencia de la red antes de pasar un puerto al estado de reenvío. El logro de una convergencia más rápida fue una cuestión de cambios realizados en los parámetros predeterminados conservadores (retardo de reenvío y temporizadores max_age) y a menudo puso en riesgo la estabilidad de la red. El nuevo STP rápido es capaz de confirmar activamente que un puerto puede pasar con seguridad al estado de reenvío sin necesidad de depender de ninguna configuración del temporizador. Ahora existe un verdadero mecanismo de retroalimentación entre los bridges en conformidad con RSTP. Para lograr una convergencia rápida en un puerto, el protocolo se basa en dos nuevas variables: puertos de borde y tipo de link.
El concepto de puerto de borde ya es conocido por los usuarios del árbol de expansión de Cisco, ya que básicamente corresponde a la función PortFast. Todos los puertos conectados directamente a las estaciones finales no pueden crear loops de puente en la red. Por lo tanto, el puerto de borde realiza una transición directamente al estado de reenvío y saltea las etapas de escucha y aprendizaje. Ni los puertos de borde ni los puertos habilitados con PortFast generan cambios de topología cuando el link se alterna. Un puerto de borde que recibe una BPDU inmediatamente pierde el estado de puerto de borde y se convierte en un puerto de spanning tree normal. En este punto, hay un valor configurado por el usuario y un valor operacional para el estado del puerto de borde. La implementación de Cisco mantiene que la palabra clave PortFast se debe utilizar para la configuración del puerto de borde. Esto facilita la transición a RSTP.
RSTP puede alcanzar solamente una transición rápida al estado de reenvío en los puertos de borde y links punto a punto. El tipo de link proviene automáticamente del modo dúplex de un puerto. Un puerto que opera en dúplex completo se asume que es punto a punto, mientras que un puerto de dúplex medio se considera como puerto compartido de forma predeterminada. Este valor de tipo de link automático puede ser reemplazado por una configuración explícita. En las redes conmutadas de hoy en día, la mayoría de los links opera en el modo de dúplex completo y son tratados como link punto a punto por RSTP. Esto los convierte en candidatos para la transición rápida al estado de reenvío.
En este diagrama, se ilustra cómo 802.1D se ocupa de un nuevo link que se agrega a una red puenteada:
En esta situación, se agrega un link entre el bridge root y el Bridge A. Supongamos que ya existe una conexión indirecta entre el puente A y el puente raíz (por C - D en el diagrama). El STA bloquea un puerto e inhabilita el loop de bridge. Primero, cuando aparecen, ambos puertos en el link entre la root y el Bridge A se ponen en el estado de escucha. El Bridge A ahora puede escuchar a la root directamente. Propaga inmediatamente sus BPDU en los puertos designados, hacia las hojas del árbol de spanning tree. Tan pronto como los puentes B y C reciben esta nueva información superior del puente A, transmiten inmediatamente la información hacia las hojas. En unos pocos segundos, el Bridge D recibe una BPDU de la root y bloquea de forma instantánea el puerto P1.
El spanning tree es muy eficiente en la manera en que calcula la nueva topología de la red. El único problema ahora es que debe transcurrir el doble de demora de reenvío antes de que el link entre la root y el Bridge A terminen finalmente en el estado de reenvío. Esto significa 30 segundos de interrupción del tráfico (se aíslan las partes enteras A, B y C la red) porque el algoritmo de 8021.D no tiene un mecanismo de retroalimentación para anunciar claramente que la red converge en cuestión de segundos.
Ahora, usted puede ver cómo RSTP se ocupa de una situación similar. Recuerde que la topología final es exactamente la misma que la calculada por 802.1D (es decir, un puerto bloqueado en el mismo lugar que antes). Solamente los pasos utilizados para llegar a esta topología han cambiado.
Ambos puertos en el link entre el Switch A y la raíz se ponen en bloqueo designado tan pronto como aparecen. Hasta el momento, todo se comporta como en un entorno puro de 802.1D. Sin embargo, en esta etapa, ocurre una negociación entre el Switch A y la root. Tan pronto como el Switch A recibe la BPDU de la raíz, bloquea los puertos designados que no son de borde. Esta operación se denomina sincronización. Una vez realizado esto, el Bridge A autoriza explícitamente al bridge root para poner su puerto en el estado de reenvío. En este diagrama, se ilustra el resultado de este proceso en la red. El link entre el Switch A y el bridge root se bloquea y ambos bridges intercambian BPDU.
Una vez que el Switch A haya bloqueado sus puertos designados que no son de borde, el link entre el Switch A y la root se pondrá en el estado de reenvío y usted llegará a la situación:
Todavía no puede haber un loop. En lugar de bloquear antes del Switch A, la red ahora bloquea después del Switch A. Sin embargo, el loop de puente potencial se corta en una ubicación diferente. Este corte viaja por el árbol junto con las nuevas BPDU originadas por la raíz a través del Switch A. En esta etapa, los puertos recientemente bloqueados en el Switch A también negocian una transición rápida al estado de reenvío con sus puertos vecinos en el Switch B y el Switch C que inician una operación de sincronización. Aparte del puerto raíz hacia A, el switch B sólo tiene puertos designados para el borde. Por lo tanto, no tiene ningún puerto para bloquearlo a fin de autorizar al Switch A para pasar al estado de reenvío. Del mismo modo, el Switch C debe bloquear su puerto designado para D. Ahora se llega al estado que se muestra en este diagrama:
Recuerde que la topología final es exactamente la misma que la que se muestra en el ejemplo de 802.1D, lo que significa que el puerto P1 en D termina en bloqueo. Esto significa que se llega a la topología de red final, justo a tiempo para que las nuevas BPDU viajen hacia abajo del árbol. No participa ningún temporizador en esta convergencia rápida. El único nuevo mecanismo introducido por RSTP es el reconocimiento de que un switch puede enviar en su nuevo puerto root para autorizar la transición inmediata al estado de reenvío y omite las etapas de escucha y aprendizaje largas del doble de demora de reenvío. El administrador solo debe recordar esto para beneficiarse de la convergencia rápida:
Esta negociación entre puentes sólo es posible cuando los puentes están conectados por links punto a punto (es decir, links de dúplex completo, a menos que se configure un puerto explícito).
Los puertos de borde tienen una función aún más importante ahora que PortFast se habilita en puertos en 802.1D. Por ejemplo, si el administrador de red no puede configurar correctamente los puertos de borde en el Switch B, su conectividad se verá afectada por el link entre el Switch A y la raíz que aparece.
Cuando el STA selecciona un puerto para convertirse en un puerto designado, 802.1D sigue esperando dos veces <retardo de reenvío> segundos (2 x 15 de forma predeterminada) antes de pasar al estado de reenvío. En RSTP, esta condición corresponde a un puerto con una función designada, pero con un estado de bloqueo. En estos diagramas, se ilustra cómo la transición rápida se alcanza paso a paso. Suponga que se crea un nuevo link entre la root y el Switch A. Se pondrá a ambos puertos en este link en estado de bloqueo designado hasta que reciban una BPDU de su homólogo.
Cuando un puerto designado se encuentra en un estado de descarte o aprendizaje (y solo en este caso), establece el bit de propuesta en las BPDU que envía. Esto es lo que ocurre para el puerto P0 del bridge root, como se muestra en el paso 1 del diagrama anterior. Debido a que el Switch A recibe información superior, sabe inmediatamente que el P1 es el nuevo puerto root. Entonces, el Switch A comienza una sincronización para verificar que todos sus puertos estén sincronizados con esta nueva información. Un puerto está sincronizado si cumple cualquiera de estos criterios:
El puerto está en el estado de bloqueo, que significa descarte en una topología estable.
El puerto es un puerto de borde.
Para ilustrar el efecto del mecanismo de sincronización en diferentes tipos de puertos, suponga que existe un puerto alternativo p2, un puerto de reenvío designado p3 y un puerto de borde p4 en el Switch A. Observe que p2 y p4 ya cumplen con uno de los criterios. Para estar sincronizado (consulte el paso 2 del diagrama anterior), el switch A solo necesita bloquear el puerto p3 y asignarle el estado de descarte. Ahora que todos sus puertos están sincronizados, el Switch A puede desbloquear su puerto root recientemente seleccionado P1 y enviar un mensaje de acuerdo para responder a la root. (Consulte el paso 3). Este mensaje es una copia de la BPDU de propuesta, con el bit de acuerdo configurado, en lugar del bit de propuesta. Esto garantiza que el puerto P0 sepa exactamente a qué propuesta corresponde el acuerdo que recibe.
Una vez que P0 recibe ese acuerdo, puede realizar inmediatamente una transición al estado de reenvío. Este es el paso 4 de la figura anterior. Observe que el puerto P3 queda en un estado de descarte designado después de la sincronización. En el paso 4, ese puerto está en la misma situación que está el puerto P0 en el paso 1. Luego, comienza a proponer a su vecino e intenta realizar una transición rápida al estado de reenvío.
El mecanismo de propuesta/acuerdo es muy rápido, ya que no depende de ningún temporizador. Esta oleada de saludos se propaga rápidamente hacia el extremo de la red y restaura rápidamente la conectividad después de un cambio en la topología.
Si un puerto de descarte designado no recibe un acuerdo después de enviar una propuesta, realiza una transición lenta al estado de reenvío y recurre nuevamente a la secuencia de escucha-aprendizaje tradicional de 802.1D. Esto puede ocurrir si el bridge remoto no comprende las BPDU de RSTP o si el puerto del bridge remoto está bloqueado.
Cisco introdujo una mejora al mecanismo de sincronización que permite que un bridge ponga solamente su puerto root anterior en el estado de descarte cuando realiza la sincronización. Los detalles de cómo funciona este mecanismo no se cubren en este documento. Sin embargo, uno puede asumir con seguridad que está invocado en la mayoría de los casos comunes de reconvergencia. La situación descrita en la sección Convergencia con 802.1w de este documento se convierte en extremadamente eficiente, ya que solo los puertos en la trayectoria hacia el puerto bloqueado final son temporalmente confusos.
Otra forma de transición inmediata al estado de reenvío incluida en RSTP es similar a la extensión de spanning tree de propiedad exclusiva de UplinkFast de Cisco. Básicamente, cuando un puente pierde su puerto raíz, puede poner su mejor puerto alternativo directamente en el modo de reenvío (la aparición de un nuevo puerto raíz también es manejada por RSTP). La selección de un puerto alternativo como el nuevo puerto root genera un cambio de topología. El mecanismo de cambio de topología de 802.1w borra las entradas apropiadas en las tablas de memoria de contenido direccionable (CAM) del bridge de flujo ascendente. Esto elimina la necesidad del proceso de generación de multicast simulado de UplinkFast.
UplinkFast no requiere configuración adicional porque el mecanismo se incluye de forma nativa y se habilita en RSTP automáticamente.
Cuando un bridge de 802.1D detecta un cambio de topología, utiliza un mecanismo confiable para notificar primero al bridge root. Esto se muestra en este diagrama:
Una vez que el puente raíz es consciente de un cambio en la topología de la red, establece el indicador TC en las BPDU que envía, que luego se transmiten a todos los puentes de la red. Cuando un bridge recibe una BPDU con el bit de indicador TC configurado, reduce el tiempo de vencimiento de la tabla de bridge para reenviar los segundos de retraso. Esto garantiza una purga relativamente rápida de la información desactualizada. Este mecanismo de cambio de topología se remodeló considerablemente en RSTP. Tanto la detección de un cambio de topología como su propagación a través de la red se desarrollaron.
En RSTP, solamente los puertos que no son de borde que se mueven al estado de reenvío generan un cambio de topología. Esto significa que una pérdida de conectividad ya no se considera como un cambio de topología, contrariamente a 802.1D (es decir, un puerto que se mueve a bloqueo ya no genera un TC). Cuando un bridge de RSTP detecta un cambio de topología, ocurre esto:
Comienza el temporizador TC While con un valor igual al doble de tiempo hello para todos sus puertos designados que no son de borde y su puerto root, de ser necesario.
Purga las direcciones MAC asociadas con todos estos puertos.
Nota: Mientras el temporizador TC While se ejecute en un puerto, las BPDU enviadas desde ese puerto tienen el bit TC configurado. Las BPDU también se envían en el puerto raíz mientras el temporizador está activo.
Cuando un bridge recibe una BPDU con el bit de TC configurado de un vecino, ocurre esto:
Borra las direcciones MAC detectadas en todos sus puertos, excepto la que recibe el cambio de topología.
Inicia el temporizador TC While y envía BPDU con el bit TC configurado en todos sus puertos designados y en el puerto raíz (RSTP ya no utiliza la BPDU TCN específica, a menos que un puente heredado necesite notificación).
De esta manera, la TCN inunda muy rápidamente toda la red. La propagación de TC es ahora un proceso de un solo paso. De hecho, el iniciador del cambio de topología inunda esta información a través de la red, a diferencia de 802.1D, donde sólo lo hizo el puente raíz. Este mecanismo es mucho más veloz que el equivalente de 802.1D. No es necesario esperar que se notifique al bridge root y luego mantener el estado de cambio de topología para toda la red durante <vencimiento máximo más demora de reenvío> segundos.
En solo unos pocos segundos, o un pequeño múltiplo de los tiempos hello, se purga la mayoría de las entradas en las tablas de CAM de toda la red (VLAN). Este enfoque da como resultado una inundación posiblemente más temporal, pero por otro lado borra posible información desactualizada, lo cual impide la restitución rápida de la conectividad.
RSTP puede interoperar con protocolos STP heredados. Sin embargo, es importante observar que los beneficios de convergencia rápida inherentes de 802.1w se pierden cuando interactúa con bridges heredados.
Cada puerto mantiene una variable que define el protocolo que se ejecutará en el segmento correspondiente. Un temporizador de demora de migración de tres segundos también comienza cuando aparece el puerto. Cuando este temporizador se ejecuta, el modo de RSTP o STP actual asociado con el puerto se bloquea. Tan pronto como expire la demora de migración, el puerto se adaptará al modo que corresponda a la siguiente BPDU que reciba. Si el puerto cambia su modo de operación como resultado de una BPDU recibida, la demora de migración comienza nuevamente. Esto limita la posible frecuencia de cambio de modo.
Por ejemplo, suponga que los puentes A y B de la figura anterior ejecutan RSTP, con el switch A designado para el segmento. Se introduce un Bridge C de STP heredado en este link. Dado que los bridges de 802.1D ignoran las BPDU de RSTP y las descartan, C cree que no hay otros bridges en el segmento y comienza a enviar sus BPDU con formato de 802.1D inferiores. El Switch A recibe estas BPDU y, después del doble del máximo de segundos de tiempo hello, cambia su modo a 802.1D en ese puerto solamente. Como resultado, C ahora comprende las BPDU del Switch A y acepta a A como el bridge designado para ese segmento.
Observe que, en este caso en particular, si se quita el Bridge C, el Bridge A se ejecuta en el modo de STP en ese puerto aunque puede funcionar más eficazmente en el modo de RSTP con su único vecino B. Esto se debe a que A no sabe que el Bridge C se quitó del segmento. Para este en caso particular (raro), se requiere la intervención del usuario para comenzar nuevamente la detección de protocolo del puerto de forma manual.
Cuando un puerto está en modo de compatibilidad 802.1D, también puede manejar las BPDU de notificación de cambio de topología (TCN) y las BPDU con el conjunto de bits TCA o TC.
RSTP (IEEE 802.1w) incluye de forma nativa la mayoría de las mejoras de propiedad exclusiva de Cisco del spanning tree de 802.1D, como BackboneFast, UplinkFast y PortFast. RSTP puede lograr una convergencia mucho más rápida en una red configurada correctamente, a veces en solo unos cientos de milisegundos. Los temporizadores 802.1D clásicos, como el retardo de reenvío y max_age, solo se utilizan como respaldo y no son necesarios si los links punto a punto y los puertos de borde son identificados y configurados correctamente por el administrador. Además, los temporizadores no son necesarios si no hay interacción con los puentes heredados.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
09-Feb-2023 |
Versión inicial |
1.0 |
28-May-2002 |
Versión inicial |