Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción de la redundancia de pseudocables Escenarios de retorno móvil

Con la creciente demanda de servicios de banda ancha móvil, los proveedores de telecomunicaciones están viendo un fuerte aumento en los requisitos de ancho de banda. Para mantener el ritmo de la demanda, los operadores están desplegando redes de retorno basadas en paquetes que ofrecen una mayor capacidad a un menor costo, al tiempo que proporcionan la confiabilidad del servicio necesaria y la calidad de experiencia 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 MDT posteriores a sus estaciones base cuando han sido necesarios para lidiar con escenarios de restricción de ancho de banda. Este modelo de expansión ha demostrado ser ineficiente para las demandas de tráfico sin precedentes requeridas por los servicios de 3G y de 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 pseudocables transporten contenido del 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 resiliencia 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 de pseudocable para aquellas 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.

Figura 1: Topología de ejemplo de backhaul móvil de redundancia de pseudocable Metro MPLS ring connects Layer 2 routers A1 to An with Layer 3 PE routers PE1 to PE4 and CE routers CE2 and CE3 via Core MPLS cloud.

Beneficios de la redundancia de pseudocables Retorno móvil

Las capacidades de redundancia de 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 los siguientes escenarios posibles:

    • Fallas en vínculos de acceso

    • Fallas de nodos

    • Fallas del plano de control

  • La interrupción del tráfico es mínima después de que se completa la restauración de la falla.

Estado del circuito virtual de capa 2 Extensión TLV

El estado de pseudocable TLV 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 red con respecto a la ruta principal por la que se debe enviar el tráfico. Con este objetivo en mente, el estado TLV se extiende para abordar este requisito.

Nota:

El estado de pseudocable TLV no es compatible con la línea ACX5000 de enrutadores.

Al tener los estados activo y en espera definidos por los enrutadores de acceso, Junos OS mitiga las posibles colisiones de rutas primarias, ya que hay un elemento de red único que dicta la ruta de reenvío preferible que se elegirá. Como valor añadido, esto permite a los operadores de red cambiar las rutas de reenvío bajo demanda, lo que es bastante útil para la resolución de problemas y el mantenimiento de la red.

Los estados activo y en espera se comunican a los enrutadores de agregación mediante el uso de un indicador de estado de pseudocable adicional.

La Tabla 1 incluye una lista de las banderas de estado del pseudocable.

Tabla 1: Código de estado de pseudocable para el estado de pseudocable TLV

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 de múltiples chasis (MC-LAG), este mismo indicador de PW_FWD_STDBY se utiliza para anunciar a dispositivos de PE remotos qué circuito de conexión (CA) se está utilizando como el activo. A la llegada de este indicador, el dispositivo de PE receptor deja caer cualquier pseudocable construido hacia el enrutador que origina este estado. Como podemos ver, este comportamiento denota una semántica ligeramente diferente para la marca PW_FWD_STDBY. Como consecuencia, puede configurar la hot-standby-vc-on instrucción para controlar si el pseudocable se debe construir al llegar el indicador de PW_FWD_STDBY (en el caso de pseudocable de espera activa) o simplemente destruirlo (en el caso de MC-LAG).

Cómo funciona

La solución utiliza 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.

Figura 2: Solución de retorno móvil de redundancia de pseudocable Network topology showing MPLS and Layer 3 VPN architecture. Features Metro MPLS Ring, Core MPLS Cloud, PE and CE devices, L3VPN VRF, logical tunnel interfaces, primary and standby virtual circuits, and shared VIP 10.1.1.1/24.

Un pseudocable de capa 2 termina en una de las interfaces de túnel lógico (x), definidas 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) e (y) están emparejadas. 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 él. Lo mismo se aplica al extremo remoto, donde se debe definir una interfaz equivalente con capacidades de 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 se configura en el contexto de una VPN de capa 3 RFC 2547.

En el ámbito 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 de PE de agregación, el proceso de enrutamiento crea un pseudocable hacia los enrutadores de acceso, y esto sucede independientemente del estado activo o en 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 conexión (CA) es un circuito físico o virtual (VC) que conecta un dispositivo CE a un dispositivo PE. La preferencia local se usa para proporcionar mejor información que la que proporciona el valor del discriminador de salida múltiple (MED) para la selección de ruta de un paquete. Puede configurar el atributo de preferencia local de forma que tenga un valor más alto para los prefijos recibidos de un enrutador que proporciona una ruta deseada que para 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 más frecuencia en la práctica para expresar preferencias por un conjunto de rutas sobre otro.

Si el circuito de capa 2 es primario, el dispositivo de PE correspondiente anuncia la subred del CA con la preferencia local más alta. Todos los dispositivos de PE de agregación anuncian inicialmente la subred del 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 el indicador CCC_Down. Cuando esto sucede, el dispositivo de PE correspondiente retira la subred de CA que se anunció inicialmente. La dirección LT(y) se comparte entre los dispositivos de PE de agregación como un puerto de instancia virtual (VIP). No se intercambian mensajes de saludo VRRP. Ambos dispositivos PE asumen la función principal.

Los VC de capa 2 primarios y en espera se mantienen abiertos para reducir la interrupción del tráfico en las transiciones de respaldo a principal. La hot-standby-vc-on instrucción de configuración permite la activación manual.

La resistencia en el dominio de capa 2 se proporciona a través de la redundancia de pseudocable simple para conexiones consecutivas. Para otras topologías, se utiliza la comprobación de conectividad de circuito virtual (VCCV) de pseudocable.

La resistencia en el dominio de capa 3 se proporciona mediante el reenrutamiento rápido de MPLS y la restauración de servicio de extremo a extremo. Un temporizador de restauración impide que los VC en la ruta secundaria se vuelvan a conmutar a la ruta principal inmediatamente después de restaurar el dispositivo de 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 TLV de estado 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 IPv4 LT(y). En este punto, el BGP procede a anunciar este cambio de preferencia local al resto de los miembros dentro del dominio de capa 3, que luego reelegirá el dispositivo de PE de reenvío designado mediante la dependencia de los mecanismos de selección de ruta del BGP.

Un comportamiento similar se produce cuando llega un mensaje TLV de estado que indica un estado activo de VC de capa 2. En este caso, el dispositivo de PE receptor cambia la preferencia local correspondiente a la subred del 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.