Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Protecciones de vínculos de borde del proveedor en VPN de capa 3

En este tema se describen y proporcionan ejemplos sobre la configuración de rutas de protección precalculadas, que proporcionan protección de vínculos y una ruta de respaldo entre un enrutador CE y un enrutador PE alternativo.

Descripción del redireccionamiento rápido del host

El reenrutamiento rápido de host (HFRR) agrega una ruta de protección precalculada en el motor de reenvío de paquetes (PFE), de modo que si un vínculo entre un dispositivo perimetral de proveedor y una granja de servidores queda inutilizable para el reenvío, el PFE puede usar otra ruta sin tener que esperar a que el enrutador o los protocolos proporcionen información de reenvío actualizada. Esta ruta de protección precalculada suele denominarse ruta de reparación o de copia de seguridad.

HFRR es una tecnología que protege los puntos finales IP en interfaces multipunto, como Ethernet. Esta tecnología es importante en los centros de datos donde es fundamental restaurar rápidamente los servicios de los puntos de conexión del servidor. Después de que una interfaz o un vínculo deja de funcionar, HFRR permite que el tiempo de reparación local sea de aproximadamente 50 milisegundos.

Considere la topología de red que se muestra en la figura 3.

Figura 3: Redireccionamiento Network topology with MPLS L3VPN cloud, PE1 and PE2 routers connecting customer networks. rápido del host

Los dispositivos de enrutamiento crean entradas de reenvío de rutas de host desencadenadas por el Protocolo de resolución de direcciones (ARP) y el Protocolo de detección de vecinos (NDP) IPv6. HFRR aumenta las rutas del host con los próximos saltos de respaldo suministrados por los protocolos de enrutamiento. Estos próximos saltos de respaldo permiten que el tráfico que llega siga fluyendo mientras la red vuelve a converger.

El tráfico fluye desde las redes conectadas a los dispositivos perimetrales del proveedor, PE1 y PE2, hacia el host A y el host B. Este tráfico está protegido con HFRR. Si el vínculo deja de funcionar entre el dispositivo PE2 y los servidores host, el tráfico se redirige a través del dispositivo PE1 a los servidores host. En la topología, el host A y el host B representan equipos LAN, conocidos colectivamente como una granja de servidores. Los dispositivos PE son enrutadores con una VPN de capa 3 configurada entre ellos. El dispositivo PE1 aprende acerca de los hosts conectados directamente mediante ARP o IPv6 NDP.

El dispositivo PE2 también tiene información sobre la red de la granja de servidores y anuncia esta información al dispositivo PE1. Este anuncio se transmite a través de la VPN de capa 3 utilizando BGP interno (IBGP). En los dispositivos PE1 y PE2, esta ruta se considera una ruta directa a la subred de la granja de servidores.

El dispositivo PE1 usa las rutas de host aprendidas a través de ARP y NDP para enviar tráfico a los equipos host de la granja de servidores. Si se interrumpe el vínculo entre el dispositivo PE1 y la granja de servidores y si HFRR no está configurado, el dispositivo de enrutamiento encuentra la siguiente mejor ruta, que es la ruta IBGP. Esta implementación provoca la pérdida de tráfico durante un intervalo hasta que se produce la actualización y la red vuelve a converger. HFRR configurado en el dispositivo PE1 resuelve este problema aumentando las rutas ARP y NDP con una ruta de respaldo para que el tráfico pueda continuar reenviándose sin interrupción.

La ruta de respaldo en esta topología en particular es la ruta VPN de capa 3 de IBGP. En una implementación real, el dispositivo PE2 también puede configurar la protección de vínculos para su red de granja de servidores conectada directamente, y el dispositivo PE1 puede anunciar la accesibilidad a la granja de servidores a través de sí mismo mediante las rutas VPN de capa 3 al dispositivo PE2. Por lo tanto, HFRR debe estar habilitado tanto en el dispositivo PE1 como en el dispositivo PE2. Además, tanto el dispositivo PE1 como el dispositivo PE2 deben anunciar la accesibilidad de la granja de servidores a través de BGP.

Se puede desarrollar un bucle de enrutamiento temporal entre los dispositivos PE si, por ejemplo, el vínculo entre el dispositivo PE1 a la granja de servidores y el vínculo entre el dispositivo PE2 a la granja de servidores deja de funcionar al mismo tiempo. El bucle puede continuar hasta que BGP en ambos extremos sepa que la subred de la granja de servidores está inactiva y retire las rutas BGP.

Límite de prefijo ARP y tiempo de espera suplementario de apagón

Al configurar perfiles HFRR, un límite de prefijo ARP opcional establece un máximo para el número de rutas ARP y, por lo tanto, las rutas FRR creadas para cada perfil HFRR de la tabla de enrutamiento. Este límite evita que los ataques ARP agoten la memoria virtual en los dispositivos de enrutamiento. El límite del prefijo ARP no limita las rutas ARP en la tabla de reenvío. Sin embargo, limita el número de rutas ARP que Junos OS lee para un perfil y, por lo tanto, limita el número de rutas HFRR que el proceso de enrutamiento (rpd) crea en la tabla de enrutamiento y la tabla de reenvío.

El límite del prefijo ARP se aplica a cada perfil HFRR. No limita el recuento total de todas las rutas ARP/HFRR en la tabla de enrutamiento. Solo limita el número de rutas ARP/HFRR para cada perfil HFRR.

Hay dos instrucciones de configuración ( global-arp-prefix-limit y arp-prefix-limit ) que establecen el límite del prefijo ARP, una en el nivel de jerarquía global [edit routing-options host-fast-reroute] y la otra en el nivel de [edit routing-instances instance-name routing-options interface interface-name] jerarquía, respectivamente. La instrucción global global-arp-prefix-limit establece un límite de prefijo ARP predeterminado para todos los perfiles HFRR configurados en el dispositivo de enrutamiento. La arp-prefix-limit instrucción anula el global-arp-prefix-limit perfil for that HFRR para esa interfaz protegida.

Cuando el número de rutas ARP en un perfil HFRR alcanza el 80% del límite de prefijo ARP configurado, se envía un mensaje de advertencia al registro del sistema. El mensaje de advertencia se muestra para cualquier ruta ARP posterior agregada a ese perfil HFRR si los prefijos ARP permanecen en más del 80% del valor configurado.

Cuando el número de rutas ARP en un perfil HFRR alcanza el 100% del límite de prefijo ARP configurado para un perfil HFRR, se envía otro mensaje de advertencia al registro del sistema. Cuando el número cruza el umbral del 100%, el perfil HFRR se desactiva. Cuando esto sucede, todas las rutas ARP/FRR se eliminan de la tabla de enrutamiento. Las rutas FRR también se eliminan de la tabla de reenvío.

Después de desactivar el perfil HFRR, se inicia un temporizador de apagón. El valor de tiempo de espera de este temporizador es el tiempo de espera de caché ARP (tiempo de espera del kernel) + el temporizador de bloqueo suplementario.

Existen instrucciones CLI globales y por HFRR ( global-supplementary-blackout-timer y supplementary-blackout-timer ). El valor global está en el nivel de [edit routing-options host-fast-reroute] jerarquía y se aplica a todos los perfiles HFRR del dispositivo de enrutamiento. El temporizador de bloqueo suplementario configurado para la interfaz de instancia de enrutamiento en el nivel de [edit routing-instances instance-name routing-options interface interface-name] jerarquía invalida el valor global solo para ese perfil HFRR.

Cuando el temporizador de apagón caduca, el perfil HFRR se reactiva y Junos OS vuelve a aprender las rutas ARP y vuelve a crear las rutas HFRR. Si no se vuelve a superar el límite del prefijo ARP, las rutas HFRR estarán activas.

Si un perfil HFRR está bloqueado en la lista y se encuentra en el estado desactivado, se realiza una reevaluación del estado ARP durante cada operación de confirmación o cada vez que se reinicia el proceso de enrutamiento (rpd) con el restart routing comando.

Candidatos de ruta principal y ruta de respaldo

La ruta principal para el próximo salto HFRR la proporcionan las rutas ARP e IPv6 NDP. Estas son las rutas /32 o /128. La ruta de copia de seguridad es una coincidencia exacta del prefijo de la dirección configurada en la interfaz local. Por ejemplo, si la dirección local configurada es 10.0.0.5/24, el dispositivo de enrutamiento busca una coincidencia exacta del prefijo 10.0.0.0 con una longitud de prefijo de 24 para seleccionar la ruta de copia de seguridad.

Las restricciones para la selección de rutas de copia de seguridad son las siguientes:

  • Debe ser un prefijo que coincida con la misma dirección de subred configurada en la interfaz habilitada para HFRR del dispositivo de enrutamiento.

  • El extremo remoto no debe tener configurada la agregación de rutas (también conocida como resumen). Por ejemplo, si el extremo remoto combina dos o más subredes /24 para anunciar una subred con una longitud de prefijo menor que /24, Junos OS no selecciona esta ruta resumida como ruta de reserva.

  • Si hay otra ruta en la tabla de enrutamiento aprendida por otro protocolo con una coincidencia de prefijo más largo para la ruta /32 o /128 (ARP o NDP), esa ruta no se selecciona para ser candidata a copia de seguridad. Por ejemplo, supongamos que la dirección de la interfaz local es 10.0.0.5/24. Supongamos también que la tabla de enrutamiento contiene una ruta IBGP con un prefijo de 10.0.0.0/24 y una ruta OSPF con un prefijo de 10.0.0.0/28. Aunque la ruta /28 es una ruta mejor para ciertos prefijos de la subred, Junos OS no considera que 10.0.0.0/28 sea un candidato para copia de seguridad. La ruta IBGP se convierte en el candidato de respaldo para todas las rutas de host. Sin embargo, después de la reparación global, la ruta OSPF se utiliza para el reenvío.

En resumen, el candidato de copia de seguridad debe ser una ruta con el mismo prefijo que la interfaz local de subred que está protegiendo con HFRR.

Política de selección de rutas de copia de seguridad

Solo se consideran las rutas VPN de capa 3 para la selección de copias de seguridad. HFRR utiliza el algoritmo habitual de selección de ruta BGP para seleccionar la mejor ruta de copia de seguridad. Solo se selecciona una ruta de copia de seguridad. En caso de que haya varios candidatos de ruta de respaldo, el algoritmo de selección selecciona la mejor ruta de respaldo. HFRR proporciona solo dos rutas, una principal y una de respaldo en cualquier momento. Si la ruta de copia de seguridad seleccionada tiene dos rutas, la primera ruta de ese próximo salto de copia de seguridad se utiliza como el siguiente salto de copia de seguridad para la ruta HFRR.

La ruta principal se instala con un peso de uno. La ruta de copia de seguridad se instala con un peso de 0x4000. Obviamente, la ruta de copia de seguridad debe ser una ruta a través de una interfaz que no sea la misma que la interfaz principal.

La ruta de copia de seguridad solo se busca en la tabla de enrutamiento a la que pertenece la interfaz. Para IPv4, Junos OS utiliza routing-instance-name.inet.0. Para IPv6, Junos OS se ve en routing-instance-name.inet6.0.

Características de las rutas HFRR

La ruta HFRR es una ruta de solo reenvío y no se utiliza para la resolución de rutas. Las rutas HFRR tienen direcciones de host, lo que significa que tienen /32 o /128 como longitud del prefijo. En el caso de plataformas con motores de enrutamiento duales, el proceso de enrutamiento de respaldo (rpd) también crea rutas HFRR. Sin embargo, el proceso de salida de copia de seguridad (rpd) no instala rutas HFRR a una tabla de enrutamiento hasta que la copia de seguridad se convierte en la principal después de un cambio de motor de enrutamiento.

Tenga en cuenta también que si una ruta HFRR está presente en la tabla de enrutamiento, la ruta HFRR se utiliza para el cálculo del reenvío de ruta inversa de unidifusión (uRPF).

Eliminación de rutas HFRR

Las rutas HFRR se eliminan si la interfaz protegida se elimina o desactiva en la configuración, si HFRR está configurado en una instancia de enrutamiento y la instancia de enrutamiento está desactivada o eliminada, o cuando se elimina o desactiva la instrucción que habilita HFRR ( link-protection (Host Fast Reroute) ). Las rutas HFRR se eliminan y se vuelven a agregar cuando hay una operación catastrófica en el enrutamiento de la instancia, como cuando se reinicia el proceso de enrutamiento. Las rutas HFRR también se eliminan si se eliminan todas las rutas de reserva. como cuando BGP retira rutas o cuando BGP está desactivado o eliminado.

Después de que una interfaz protegida deja de funcionar y si se elimina o desactiva HFRR, se inicia un temporizador con un tiempo de espera de 20 segundos. La eliminación de la ruta HFRR se produce después de que expire el temporizador. Esto es para garantizar que si la interfaz oscila (sube y baja rápidamente), Junos OS no realice innecesariamente eliminaciones y adiciones de rutas que causen pérdida de tráfico. Este temporizador sólo se utiliza cuando la interfaz está inactiva o cuando la ruta HFRR se elimina o desactiva.

Las rutas HFRR se purgan inmediatamente en los siguientes casos:

  • Una ruta de copia de seguridad deja de funcionar y no hay otras rutas de copia de seguridad potenciales.

  • Se recibe un mensaje de eliminación de ARP.

  • El proceso de enrutamiento (rpd) termina.

Interfaces compatibles con HFRR

HFRR solo se permite en interfaces Ethernet. Se produce un error en la operación de confirmación si configura HFRR en interfaces punto a punto.

Solo se aceptan interfaces configuradas en una instancia de enrutamiento del tipo Enrutamiento y reenvío VPN (VRF). Se produce un error en la operación de confirmación si configura HFRR en otros tipos de instancias de enrutamiento.

Cuando no se cumplen los siguientes requisitos, la operación de confirmación no falla. Sin embargo, la interfaz no está protegida por HFRR y la interfaz está marcada como inactiva en la salida del show hfrr profiles comando:

  • HFRR solo se permite en interfaces numeradas, lo que significa que se debe asignar una dirección a la interfaz. No puede, por ejemplo, configurar IPv4 en la interfaz con una dirección e IPv6 sin una dirección.

  • Las interfaces configuradas para la protección HFRR deben configurarse en el nivel de [edit interfaces] jerarquía y también deben estar asociadas a la instancia de enrutamiento.

  • La instancia de enrutamiento debe tener una interfaz de túnel virtual (VT) o la vrf-table-label instrucción incluida.

Otra razón por la que la interfaz puede marcarse como inactiva en la show hfrr profiles salida del comando es cuando la interfaz está migrando de una instancia a otra y la configuración de HFRR está en la instancia de enrutamiento anterior.

HFRR no se admite en unidades lógicas superpuestas si pertenecen a la misma instancia de enrutamiento, como se muestra aquí:

Si configura subredes superpuestas como se muestra aquí y si habilita HFRR en ambas subredes superpuestas, el proceso de protocolo de enrutamiento (RPD) genera un error de RPD_ASSERT.