Descripción de escenarios de retorno móvil de redundancia pseudocable
Con la creciente demanda de servicios de banda ancha móvil, los proveedores de telecomunicaciones están viendo un fuerte aumento de los requisitos de ancho de banda. Para mantener el ritmo de la demanda, los operadores están implementando redes de retorno basadas en paquetes que ofrecen una mayor capacidad a un costo más bajo, a la vez que proporcionan la confiabilidad del servicio y la calidad de experiencia necesarias que los usuarios esperan.
La mayor parte de la infraestructura de retorno heredada se ha construido tradicionalmente sobre microondas PDH, TDM T1/E1 o enlaces ATM-over-DSL. Tradicionalmente, los proveedores de servicios han agregado enlaces TDM posteriores a sus estaciones base cuando es necesario para lidiar con situaciones de limitaciones de ancho de banda. Este modelo de expansión ha demostrado ser ineficiente para las demandas de tráfico sin precedentes que requieren los servicios de 3G y evolución a largo plazo (LTE). Como consecuencia directa, los operadores están migrando gradualmente a una infraestructura de mayor capacidad basada en Ethernet en la parte de retorno de las topologías 3G y LTE. Las estaciones base modernas ahora ofrecen conectividad de retorno Ethernet, lo que permite que las tecnologías de pseudocable transporten contenido de usuario final al destino deseado. Como parte de esta transición de Ethernet, los proveedores de servicios exigen cada vez más mejores mecanismos de resistencia para cubrir la brecha de existencia con las características proporcionadas por las tecnologías heredadas anteriores. Con ese objetivo en mente, Junos OS ofrece capacidades eficientes de redundancia pseudocable a esas topologías en las que los segmentos de capa 2 y capa 3 están interconectados.
Topología de ejemplo
La Figura 1 muestra una topología de ejemplo.
Beneficios del retorno móvil de redundancia pseudocable
Las capacidades de redundancia pseudocable de Junos OS son las siguientes:
Rutas redundantes sin bucles para interconectar dominios de capa 2 y capa 3.
Los dominios de capa 2 y capa 3 se sincronizan con respecto a la ruta de datos elegida.
La interrupción del tráfico es mínima en las siguientes situaciones posibles:
Fallas de vínculo de acceso
Errores de nodo
Fallas en el plano de control
La interrupción del tráfico es mínima después de completar la restauración de la falla.
Extensión del estado TLV del circuito virtual de capa 2
El TLV de estado de pseudocable se utiliza para comunicar el estado de un pseudocable entre enrutadores de borde de proveedor (PE). Para evitar posibles discrepancias en la ruta principal, debe haber un mecanismo que permita sincronizar todos los elementos de la red con respecto a la ruta principal a la que se debe enviar tráfico. Con este objetivo en mente, el estado TLV se extiende para abordar este requisito.
La TLV de estado de pseudocable no es compatible con la línea de enrutadores ACX5000.
Al tener los estados activos y de espera definidos por los enrutadores de acceso, Junos OS mitiga las posibles colisiones de ruta principal, ya que hay un elemento de red único que dicta la ruta de reenvío preferible que se debe elegir. Como valor agregado, esto permite a los operadores de red cambiar de ruta de reenvío a pedido, lo cual es muy útil para fines de resolución de problemas y mantenimiento de red.
Los estados activos y de espera se comunican a los enrutadores de agregación mediante el uso de una marca de estado pseudocable adicional.
La tabla 1 incluye una lista de las marcas de estado pseudocables.
Bandera |
Código |
|---|---|
L2CKT_PW_STATUS_PW_FWD |
0x00000000 |
L2CKT_PW_STATUS_PW_NOT_FWD |
0x00000001 |
L2CKT_PW_STATUS_AC_RX_FAULT |
0x00000002 |
L2CKT_PW_STATUS_AC_TX_FAULT |
0x00000004 |
L2CKT_PW_STATUS_PSN_RX_FAULT |
0x00000008 |
L2CKT_PW_STATUS_PSN_TX_FAULT |
0x00000010 |
L2CKT_PW_STATUS_PW_FWD_STDBY |
0x00000020 Indica el estado de espera. |
L2CKT_PW_STATUS_SWITCH_OVER |
0x00000040 |
En escenarios basados en LAG (MC-LAG) de varios chasises, esta misma marca de PW_FWD_STDBY se utiliza para anunciar a los dispositivos de PE remotos cuyo circuito de adjunto (AC) se utiliza como activo. Al llegar a esta marca, el dispositivo pe receptor deja caer cualquier pseudocable creado hacia el enrutador que origina este estado. Como podemos ver, este comportamiento indica una semántica ligeramente diferente para la marca de PW_FWD_STDBY. Como consecuencia, puede configurar la hot-standby-vc-on instrucción para controlar si el pseudocable debe construirse al llegar el indicador de PW_FWD_STDBY (en la situación de pseudocable en espera activa) o simplemente destruirlo (en el escenario MC-LAG).
Cómo funciona
La solución usa interfaces emparejadas de túnel lógico (lt-) para unir los dominios de capa 2 y capa 3.
La figura 2 muestra un diagrama que muestra cómo funciona la redundancia de pseudocable en un escenario de retorno móvil.
Un pseudocable de capa 2 termina en una de las interfaces de túnel lógico (x), definida con la familia de direcciones de conexión cruzada de circuito (CCC) configurada. Una VPN de capa 3 (RFC 2547) termina la segunda interfaz de túnel lógico (y), definida con la familia de direcciones IPv4 (inet). La interfaz de túnel lógico (x) y (y) se emparejan. Los pseudocables de capa 2 establecidos entre cada enrutador de acceso y sus correspondientes dispositivos de PE de agregación terminan en la interfaz de túnel lógico definida dentro de cada dispositivo de PE. Esta interfaz de túnel lógico se utiliza para establecer un circuito virtual (VC) de capa 2 hacia el extremo remoto. En consecuencia, la familia de direcciones CCC debe configurarse en ella. Lo mismo se aplica al extremo remoto, en el que se debe definir una interfaz equivalente con capacidades CCC.
Esta interfaz de túnel lógico CCC creada en los dispositivos pe de agregación se empareja con una segunda interfaz de túnel lógico en la que está habilitada la familia de direcciones INET. Esta segunda interfaz de túnel lógico está configurada en el contexto de una VPN rfc 2547 de capa 3.
Dentro del alcance de este documento, nos referimos a las interfaces de túnel lógico CCC e INET como LT(x) y LT(y), respectivamente.
El proceso de protocolo de enrutamiento (rpd) de Junos OS permite la unión necesaria para interconectar el VC de capa 2 que termina en LT(x) y el LT(y) asociado.
En los enrutadores pe de agregación, el proceso de enrutamiento crea un pseudocable hacia los enrutadores de acceso, y esto ocurre independientemente del estado activo o de espera del pseudocable. Lo mismo ocurre en los enrutadores de acceso, donde el estado de control y reenvío está preestablecido tanto en el motor de enrutamiento como en el motor de reenvío de paquetes para mitigar la interrupción del tráfico durante los períodos de convergencia.
Un circuito de datos adjuntos (AC) es un circuito físico o virtual (VC) que conecta un dispositivo CE a un dispositivo PE. La preferencia local se utiliza para proporcionar mejor información que el valor discriminador de salida múltiple (MED) que proporciona para la selección de ruta de un paquete. Puede configurar el atributo de preferencia local de modo que tenga un valor mayor para los prefijos recibidos de un enrutador que proporciona una ruta deseada que los prefijos recibidos de un enrutador que proporciona una ruta menos deseable. Cuanto mayor sea el valor, más preferida será la ruta. El atributo de preferencia local es la métrica que se utiliza con mayor frecuencia en la práctica para expresar preferencias para un conjunto de rutas sobre otra.
Si el circuito de capa 2 es principal, el dispositivo PE correspondiente anuncia la subred de la CA con la preferencia local más alta. Todos los dispositivos pe de agregación anuncian inicialmente la subred de AC con la misma preferencia local. Puede configurar una política de enrutamiento para permitir que se anuncie un valor de preferencia local más alto si el VC de capa 2 está activo.
Si un pseudocable está inactivo, LT(x) se etiqueta con la marca CCC_Down. Cuando esto sucede, el dispositivo de PE correspondiente retira la subred de AC que se anunció inicialmente. La dirección LT(y) se comparte entre los dispositivos pe de agregación como un puerto de instancia virtual (VIP). No se intercambian mensajes de saludo VRRP. Ambos dispositivos de PE asumen la función principal.
Las VCs de capa 2 principales y en espera se mantienen abiertas para reducir la interrupción del tráfico en las transiciones de copia de seguridad a primaria. La hot-standby-vc-on instrucción de configuración permite la activación manual.
La resistencia en el dominio de la capa 2 se proporciona a través de redundancia pseudocable simple para conexiones de espalda a otra. Para otras topologías, se utiliza la verificación de conectividad de circuito virtual pseudocable (VCCV).
La resistencia en el dominio de la capa 3 la proporciona el reenrutamiento rápido de MPLS y la restauración de servicio de extremo a extremo. Un temporizador de restauración impide que las VCs en la ruta secundaria vuelvan a cambiar a la ruta principal inmediatamente después de restaurar el dispositivo PE principal.
Los enrutadores de acceso pueden indicar a los enrutadores de agregación qué VC de capa 2 se considera activo. Al llegar a LT(x) de un mensaje de estado TLV que comunica un estado de espera, el proceso de enrutamiento disminuye el valor de preferencia local del BGP de la subred directa representada por la dirección LT(y) IPv4. En este punto, BGP procede a anunciar este cambio de preferencia local al resto de los miembros dentro del dominio de capa 3, que luego reeleccionarán el dispositivo de PE del reenviador designado confiando en los mecanismos de selección de rutas del BGP.
Un comportamiento similar ocurre al llegar un mensaje de estado TLV que indica un estado vc de capa 2 activo. En este caso, el dispositivo PE receptor cambia la preferencia local correspondiente a la subred de LT(y). El valor que se utilizará para disminuir o aumentar el valor de preferencia local de la subred se configura manualmente mediante una política.