Backbone Fast es una función propietaria de Cisco que, una vez habilitada en todos los switches de una red de Bridge, permite que un Switch ahorre hasta 20 segundos (max_age, intervalo máximo) cuando se recupera de una falla de link indirecto.
Después de una revisión rápida de algunos fundamentos de STP (Spanning-Tree Protocol), podrá ver el escenario de falla exacto al que se aplica la función Backbone Fast y cómo configurarlo para los switches Catalyst que ejecutan el software CatOS y Cisco IOS®.
Switches Cisco Catalyst que usan esta característica
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- Catalyst 2950 Series Switch que funcionan con el Cisco IOS Software Release12.1(6)EA2 y posterior
- Catalyst 3550 Series Switch que funcionan con el Cisco IOS Software Release12.1(4)EA1 y posterior
- Catalyst 4000 Series Switch que ejecutan CatOS 5.1(1a) y posterior
- Switches de las 4500/4000 Series del Catalyst que funciona con el Cisco IOS Software Release 12.1(8a)EW y Posterior
- Series Switch del Catalyst 5500/5000 que funcionan con la versión CatOS 4.1(1) y posterior
- Catalyst 6500/6000 Series Switch que funcionan con la versión CatOS 5.1(1)CSX y posterior
- Catalyst 6500/6000 Series Switch que funcionan con el Cisco IOS Software Release 12.0-7XE y Posterior
BPDUs y como compararlos
Las Unidades (BPDU) se pueden clasificar estrictamente por los campos que llevan.
Entre estos campos están el Root Bridge ID, el costo del trayecto a la raíz, y el ID de Bridge de envío. Un BPDU se considera mejor que otro BDPU por estas razones:
- Cuando un BPDU lleva un mejor Root Bridge ID que otro. Cuanto más bajo es el valor, mejor.
- Cuando los valores de ID del puente raíz son iguales, entonces es mejor el BPDU con el costo de trayecto más bajo a la raíz.
- Cuando los valores de ID de Root Bridge son iguales y los costes a la raíz son lo mismo, después el BPDU con el mejor ID de Bridge de envío es mejor. Cuanto más bajo es el valor, mejor.
Hay otras variables que entonces pueden actuar como elementos para desempate.
Sin embargo, cuanto mejor sea un BPDU, mejor es el acceso al Root Bridge.
Un Bridge que recibe un mejor BPDU en un puerto que el que él envía, pone este puerto en el modo de bloqueo a menos que sea su puerto raíz.
Esto significa que en el segmento conectado a este puerto existe otro puente que constituye un puente designado. Un Bridge guarda el valor del BPDU en un puerto enviado por el Bridge designado actual.
¿Cómo se recupera STP de una falla de link indirecto?
A continuación se ilustra cómo el STP se comporta cuando tiene que recalcular después de una falla de link indirecto, es decir, cuando un Bridge tiene que cambiar el estatus de algunos de sus puertos debido a un error en un link que no está directamente conectado a él.
Considere este diagrama, que implica tres Switches R, B, y S en una topología de malla completa. Asuma que R es el Root Bridge y B es el Root Bridge de backup. S bloquea su puerto P y B es el Bridge designado para el link L3.
- Si link L1 se interrumpe, el switch B detecta inmediatamente el error y asume que es el puente raíz. Comienza a enviar los BPDU a S y demanda ser la nueva raíz de la topología.
- Cuando S recibe esta nueva BPDU desde B, se da cuenta de que es inferior a la que ya tiene almacenada para el puerto P y la ignora.
- Después de que expire el temporizador del max_age (20 segundos por defecto), el BPDU almacenado en S para el puerto P expira. El puerto cambia inmediatamente al estado STP "escuchar" y S comienza a enviar su mejor BPDU a B.
- Tan pronto como B recibe el BPDU de S, detiene el envío de su BPDU.
- El puerto P pasa al estado de "reenvío" a través de los estados de "escuchar" y "aprender". Esto requiere el doble del valor fw_delay, un tiempo adicional de 30 segundos. La conectividad total entonces se restablece.
El tiempo que total que fue necesario para recuperarse de esta falla de link indirecto fue el valor del max_age (20 segundos) más dos veces el valor fw_delay (2x15 segundos ) . Esto es 50 segundos con los parámetros predeterminados.
La característica del Backbone Fast propone ahorrar el max_age (20 segundos).
Para hacer esto, expira el temporizador inmediatamente después que el puerto recibe los BPDU inferiores.
Mejoras en Backbone (Troncal principal) rápidas en STP estándar
Con el ejemplo anterior, el STP invalida la información que llega a ser incorrecta debido a una falla de link indirecto. Para hacer esto, espera pasivamente el max_age. Para librarse del retardo del max_age, el Backbone Fast introduce dos mejoras:
- La capacidad de detectar una falla de link indirecto lo antes posible. Esto se logra siguiendo los BPDU inferiores que un Bridge designado envía cuando experimenta una falla de link directo.
- Introduce un mecanismo que permite un control inmediato si la información de BPDU almacenada en un puerto es todavía válida. Esto se implementa mediante una nueva unidad de datos del protocolo (PDU) y el Root Link Query, explicados en este documento, el RLQ PDU.
Detección de fallas de link indirecto
Si un BPDU inferior se recibe en un puerto de nuestro Bridge designado, después este Bridge se tiene:
- Perdió el enlace hacia el puente raíz y comienza a publicar una raíz con un Bridge ID más alto, una raíz peor que las almacenadas en los otros equipos.
- O bien, el trayecto a la raíz ha aumentado por encima del valor almacenado.
1 - En este caso, el Switch B pierde conexión al Root R y envía un BPDU con su propio BID como Root, costo del enlace en 0 y el BridgeID en B. Este es inferiór al que el Switch S tenía almacenado, porque el BID de R es mejor que B.
2 - En este caso, B todavía tiene a R como Root, pero la falla implica que el costo del enlace crezca de 10 a 100. Entonces el BPDU enviado es, nuevamente, inferior al que estaba almacenado en S.
La conducta habitual según las especificaciones del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) es simplemente : ignorar cualquier BPDU inferior.
El Backbone Fast lo utiliza porque tan pronto como se reciba uno, es cierto que un error ocurrió en la trayectoria a la raíz y que se debe expirar por lo menos un puerto.
Nota: Una falla de link indirecto puede suceder sin ninguna generación del BPDU inferior en la red. Simplemente agregue un hub en el diagrama anterior:
La falla de link ocurre entre el Root Bridge R y el concentrador. B no detecta que el link va abajo y espera el max_age antes de que demande ser la nueva raíz.
Recuerde que el mecanismo trabaja solamente si un Bridge detecta una falla de link directo.
Sólo realiza el seguimiento de BPDU inferiores enviadas por el puente designado. Dado que ésta es la BPDU que está almacenada en el puerto.
Si, por ejemplo, un Bridge nuevamente insertado comienza a enviar el BPDU inferior, no comienza la característica del Backbone Fast.
Reacción frente a fallas de links indirectas
Cuando un BPDU inferior se detecta en un puerto no designado, la segunda fase de Backbone Fast se acciona. En vez del max_age pasivo que espera para expirar los puertos que se pueden afectar por la falla, participan de un modo proactivo y los prueban inmediatamente mediante el RLQ PDU.
RLQ se utiliza para lograr un tipo de "ping" para la raíz en un puerto no designado y permite rápidamente confirmar si la BPDU almacenada en un puerto aún es válida o necesita ser descartada.
Al recibir una BPDU inferior desde un puente designado, se envía una PDU de RLQ en todos los puertos no designados, excepto el puerto donde recibió la BPDU inferior y los puertos de loop intrínseco.
Éste es para indicar que usted todavía oye de la raíz en los puertos donde se solían recibir los BPDU. El puerto en donde usted recibió el BPDU inferior se excluye porque usted ya está consciente que sufrió un error, volver a colocar y señalar los puertos no es útil, pues no llevan a la raíz.
Al recibir una respuesta RLQ en un puerto, si la respuesta es negativa, el puerto perdió la conexión a la raíz y usted puede expirar de la table su BPDU.
Además, si el resto de los puertos no designados recibieron ya una respuesta negativa, el Bridge del conjunto pierde la raíz y puede comenzar el cálculo de STP desde el principio.
Si la respuesta confirma que usted puede todavía acceder el Root Bridge vía este puerto, usted puede expirar inmediatamente el puerto en el cual recibimos inicialmente el BPDU inferior.
En este ejemplo, tenemos A hacia el lado de izquierdo, B, D, y E son puertos no designados para el Switch S. A es el puerto raíz y lo otros están bloqueados.
Cuando E recibe un BPDU (1) inferior, la estructura básica rápida comienza a acelerar el cálculo STP.
S envía una petición RLQ, que busca la raíz R en todos los puertos no designados excepto por E (2).
Las respuestas especifican qué la raíz es accesible a través de estos puertos. La respuesta RLQ que recibe D especifica que D perdió su trayecto a la raíz R. Entonces hace que su BPDU expire inmediatamente (3).
Los Puertos A y B reciben confirmación de que aún cuentan con un trayecto a R (4).
Por consiguiente, como el switch S aún tiene conectividad con la raíz, hace que el puerto E expire inmediatamente y continúa con las reglas STP habituales (5).
En un caso donde el Switch recibe solamente las respuestas con una raíz diferente de R, considere la raíz como perdida desde el principio y se recalcula el STP inmediatamente. Observe que este caso también ocurre cuando el único puerto no señalado (y no auto colocado) en el Bridge es el puerto raíz y usted recibe un BPDU inferior en este puerto.
PDU de consulta de link raíz
Las dos formas de RLQ son consulta RLQ y respuestas RLQ.
La consulta RLQ se envía en un puerto en donde usted recibe generalmente los BPDU, para marcar que usted todavía tiene Conectividad a la raíz a través de este puerto. Se especifica en la petición que el Bridge es su raíz y la respuesta RLQ se vuelve eventual con un Root Bridge que se pueda acceder a través de este puerto. Si las dos raíces son lo mismo, se pierde la Conectividad está todavía viva, él.
Un Bridge que recibe una Consulta RLQ responde inmediatamente si sabe que ha perdido la conexión a la raíz consultada porque tiene un Root Bridge diferente al que está especificado en la consulta RLQ, y si es este el ROOT.
En caso contrario, entonces, él reenvía la interrogación hacia la raíz a través de su puerto raíz.
Las respuestas RLQ son inundadas a los puertos designados.
El emisor de la solicitud RLQ coloca su identificador de puente BID en la PDU. Esto es para garantizar que, cuando reciba una respuesta a su consulta, no se inunde la respuesta en sus puertos designados.
El RLQ PDU tiene la misma estructura de paquete que un STP BPDU normal. La única diferencia es que dos diferentes direcciónes SNAP especificadas por Cisco son usadas: una para la solicitud y otra para la respuesta.
Esto el formato BPDU estándar:
| DA | SA | Longitud | DSAP | SSAP | CNTL | SNAP | PDU |
|---|
El campo PDU contiene:
| Identificador de Protocolo | Versión | Tipo de mensaje | Indicadores | ID de raíz | Costo de trayecto raíz |
|---|---|---|---|---|---|
| ID del emisor | Identificación del puerto | Antigüedad del mensaje | max age | tiempo de saludo | demora de reenvío |
El Tipo de mensaje usado en el PDU es también diferente del BPDU estándar.
Los únicos campos usados son el ID de RAÍZ y el ID de Bridge de envío.
Esta característica de Cisco tiene que ser configurada en todos los Switches en la red para que puedan procesar estas PDUs.
Ejemplo de situación con la función Backbone Fast habilitada
Este escenario se basa en el primer ejemplo, pero, este vez con el Backbone Fast habilitado en los tres Switches.
- La primera etapa es igual a la que se explicó anteriormente.
- Tan pronto como S reciba el BPDU inferior de B, comienza a reconfirmar sus puertos no designados en vez del esparar el temporizador max_age. Envía una Consulta RLQ en su puerto raíz para el Root Bridge R.
- El Root Bridge R recibe la Consulta RLQ y la contesta inmediatamente con una respuesta RLQ que especifica que allí sigue existiendo un Root Bridge R en esa dirección.
- S ya ha verificado todos sus puertos no designados y aún posee conectividad a la raíz. Puede entonces expirar inmediatamente la información salvada en las transiciones de P. El puerto P cambia al estado "escuchar" y comienza a enviar los BPDU. En esa etapa, ya se ha ahorrado los segundos del max_age, y el Algoritmo del Spanning-Tree (STA) estándar es aplicado.
- B recibe un mejor BPDU de S (una mejor ROOT BID R que B) y ahora considera los puertos que llevan al L3 como su puerto raíz.
Configurar el Backbone Fast para CatOS y el Cisco IOS
Cuando está utilizado, el Backbone Fast se debe habilitar en todo el Switches en la red porque el Backbone Fast requiere el uso del mecanismo de la petición y de la contestación RLQ para informar al Switches la estabilidad del trayecto raíz.
El protocolo RLQ es activo solamente cuando el Backbone Fast se habilita en un Switch. Además, la red puede también ejecutarse en los problemas con la inundación RLQ, si el Backbone Fast no se habilita en todo el Switches. Por abandono, se inhabilita el Backbone Fast.
El Backbone Fast no se soporta en los Catalyst 2900XL y 3500XL Switches. Usted necesita generalmente habilitar el Backbone Fast si el dominio del Switch contiene este Switches además de otros switches de Catalyst que soportan.
Cuando usted implementa el Backbone Fast en los entornos con los switches XL, bajo topologías estrictas, usted puede habilitar la característica donde está el Switch más reciente de la línea y está conectado solamente el switch XL con la base en dos lugares. No implemente esta característica si la arquitectura de los switches XL está en la manera de la cadena margarita.
Usted no necesita configurar el Backbone Fast con el RSTP o el IEEE 802.1W porque el mecanismo se incluye nativo y se habilita automáticamente en el RSTP. Para más información sobre el RSTP o el IEEE 802.1W, refiera al Spanning-tree del PVST+ al ejemplo de configuración de la migración Rápido-PVST.
Configuración para CatOS
Para los Catalyst 4000, 5000 y 6000 Series Switch que ejecutan CatOS, utilice estos comandos para habilitar el Backbone Fast global para todos los puertos y verificar la configuración.
Console> (enable) set spantree backbonefast enable
Backbonefast enabled for all VLANs
Console> (enable) show spantree backbonefast
! This command show that the backbonefast feature is enabled.
Backbonefast is enabled.
Console> (enable)
Para visualizar las estadísticas del Backbone Fast:
Console> (enable) show spantree summary
Summary of connected spanning tree ports by vlan
Uplinkfast disabled for bridge.
Backbonefast enabled for bridge.
Vlan Blocking Listening Learning Forwarding STP Active
----- -------- --------- -------- ---------- ----------
1 0 0 0 1 1
Blocking Listening Learning Forwarding STP Active
----- -------- --------- -------- ---------- ----------
Total 0 0 0 1 1
BackboneFast statistics
! The show spantree summary command displays all backbonefast statistics.
-----------------------
Number of inferior BPDUs received (all VLANs): 0
Number of RLQ req PDUs received (all VLANs): 0
Number of RLQ res PDUs received (all VLANs): 0
Number of RLQ req PDUs transmitted (all VLANs): 0
Number of RLQ res PDUs transmitted (all VLANs): 0
Console> (enable)
Configuración para el Cisco IOS
Para los switches de Catalyst que se ejecutan con el Cisco IOS Software, utilice estos comandos para habilitar el Backbone Fast global para todas las interfaces.
CAT-IOS# configure terminal
CAT-IOS(config)# spanning-tree backbonefast
CAT-IOS(config)# end
CAT-IOS#
Para verificar que el Backbone Fast esté habilitado y mostrar las estadísticas:
CAT-IOS# show spanning-tree backbonefast
BackboneFast is enabled
BackboneFast statistics
-----------------------
Number of transition via backboneFast (all VLANs) : 0
Number of inferior BPDUs received (all VLANs) : 0
Number of RLQ request PDUs received (all VLANs) : 0
Number of RLQ response PDUs received (all VLANs) : 0
Number of RLQ request PDUs sent (all VLANs) : 0
Number of RLQ response PDUs sent (all VLANs) : 0
CAT-IOS#
Tomado de: http://www.cisco.com/cisco/web/support/LA/102/1024/1024740_18.html con aportes del editor del BLOG ccnabolivia.blogspot.com
