Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Protección de vínculo de borde del proveedor en VPN de capa 3

En este tema, se describen y se proporcionan ejemplos sobre cómo configurar una ruta de protección precomputada, que proporciona protección de vínculo y una ruta de respaldo entre un enrutador CE y un enrutador de PE alternativo.

Descripción del reenrutamiento rápido del host

El reenrutamiento rápido de host (HFRR) agrega una ruta de protección precomputada al motor de reenvío de paquetes (PFE), de modo que si un vínculo entre un dispositivo perimetral del proveedor y una granja de servidores deja de ser útil 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 precomputada se denomina a menudo una ruta de reparación o una ruta de respaldo.

HfRR es una tecnología que protege los puntos de conexión IP en interfaces multipunto, como Ethernet. Esta tecnología es importante en los centros de datos, donde la restauración rápida del servicio para los puntos de conexión del servidor es fundamental. Después de que una interfaz o un vínculo fallan, 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: Reenrutamiento Host Fast Reroute rápido del host

Los dispositivos de enrutamiento crean entradas de reenvío de ruta de host desencadenadas por el Protocolo de resolución de direcciones (ARP) y el protocolo de descubrimiento de vecinos IPv6 (NDP). HFRR aumenta las rutas de host con los próximos saltos de respaldo proporcionados 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 de borde del proveedor, PE1 y PE2, hasta los host A y B. Este tráfico está protegido con HFRR. Si el vínculo falla entre el dispositivo PE2 y los servidores host, el tráfico se reenruta a través del dispositivo PE1 a los servidores host. En la topología, el host A y el host B representan las PC LAN, conocidas colectivamente como una granja de servidores. Los dispositivos PE son enrutadores con una VPN de capa 3 configurada entre ellos. El dispositivo PE1 aprende sobre los hosts conectados directamente a través de ARP o el NDP IPv6.

El dispositivo PE2 también tiene información sobre la red de la granja de servidores y anuncia esta información en el dispositivo PE1. Este anuncio se transmite a través de la VPN de capa 3 mediante 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 las máquinas host de la granja de servidores. Si el vínculo entre el dispositivo PE1 y la granja de servidores se interrumpe y si la HFRR no está configurada, el dispositivo de enrutamiento encuentra la siguiente mejor ruta, que es la ruta IBGP. Esta implementación da como resultado la pérdida de tráfico durante un intervalo hasta que se produce la actualización y la red vuelve a converger. La HFRR configurada en el dispositivo PE1 resuelve este problema mediante el aumento de las rutas ARP y NDP con una ruta de respaldo para que el tráfico pueda continuar reenviando sin interrupción.

La ruta de copia de seguridad en esta topología en particular es la ruta DE 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 directamente conectada, y el dispositivo PE1 puede anunciar la accesibilidad a la granja de servidores a través de sí misma mediante las rutas VPN de capa 3 al dispositivo PE2. Por lo tanto, la HFRR debe habilitarse en los dispositivos PE1 y PE2. Además, los dispositivos PE1 y PE2 deben anunciar la accesibilidad a la granja de servidores a través del BGP.

Se puede desarrollar un bucle de enrutamiento temporal entre los dispositivos de PE si, por ejemplo, el vínculo entre el dispositivo PE1 con la granja de servidores y el vínculo entre el dispositivo PE2 y la granja de servidores se cae al mismo tiempo. El bucle puede continuar hasta que el BGP de ambos extremos aprenda que la subred de la granja de servidores está desactivada y retire las rutas del BGP.

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

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

El límite de prefijo ARP se aplica a cada perfil HFRR. No limita el recuento total de todas las rutas ARP/HFRR de 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 de prefijo ARP, una en el nivel de jerarquía global [edit routing-options host-fast-reroute] y la otra en el [edit routing-instances instance-name routing-options interface interface-name] nivel de 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 reemplaza el global-arp-prefix-limit perfil HFRR de 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 la caché ARP (tiempo de espera del kernel) + el temporizador de apagón suplementario.

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

Cuando caduca el temporizador de apagón, 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 de prefijo ARP, las rutas HFRR estarán activa.

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

Candidatos a ruta principal y ruta de respaldo

La ruta principal para el próximo salto de HFRR la proporcionan las rutas ARP y NDP IPv6. Estas son rutas /32 o /128. La ruta de copia de seguridad es una coincidencia exacta de 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 la selección de la ruta de copia de seguridad.

Las restricciones para la selección de rutas de respaldo 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 ruta (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 para que sea una ruta de copia de seguridad.

  • Si hay otra ruta en la tabla de enrutamiento aprendida por otro protocolo con una coincidencia de prefijo más larga para la ruta /32 o /128 (ARP o NDP), esa ruta no está seleccionada para ser candidata de copia de seguridad. Por ejemplo, suponga que la dirección de interfaz local es 10.0.0.5/24. Suponga 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 mejor para ciertos prefijos de la subred, Junos OS no considera que 10.0.0.0.0/28 sea un candidato de copia de seguridad. La ruta del IBGP se convierte en la candidata 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 ruta de respaldo

Solo se tienen en cuenta las rutas VPN de capa 3 para la selección de respaldo. HFRR usa el algoritmo habitual de selección de ruta del BGP para seleccionar una mejor ruta de respaldo. Solo se ha seleccionado una ruta de copia de seguridad. En caso de que haya varias rutas de respaldo candidatas, el algoritmo de selección selecciona la mejor ruta de copia de seguridad. HfRR proporciona solo dos rutas, una principal y una copia de seguridad en cualquier momento. Si la ruta de copia de seguridad seleccionada tiene dos rutas, la primera ruta de ese salto siguiente 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 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 usa routing-instance-name.inet.0. Para IPv6, Junos OS se ve en routing-instance-name.inet6.0.

Características de las rutas de HFRR

La ruta de 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 la longitud del prefijo. En el caso de plataformas con motores de enrutamiento dual, 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 de HFRR a una tabla de enrutamiento hasta que la copia de seguridad se convierte en la principal después de una conmutación del 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 de reenvío de ruta inversa (uRPF) de unidifusión.

Eliminación de rutas de HFRR

Las rutas de HFRR se eliminan si la interfaz protegida se elimina o desactiva en la configuración, si HFRR está configurada en una instancia de enrutamiento y la instancia de enrutamiento está desactivada o eliminada, o cuando la instrucción que habilita HFRR (link-protection (Host Fast Reroute)) se elimina o desactiva. Las rutas de HFRR se eliminan y se leen 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 respaldo. como cuando BGP retira rutas o cuando BGP se desactiva o elimina.

Después de que una interfaz protegida falla y si hfRR se elimina o desactiva, un temporizador comienza con un tiempo de espera de 20 segundos. La eliminación de ruta HFRR se produce después de que caduca el temporizador. Esto es para asegurarse de que, si la interfaz está aleteando (subiendo y bajando rápidamente), Junos OS no realice eliminaciones de rutas ni adiciones innecesariamente que causen pérdida de tráfico. Este temporizador solo se usa cuando la interfaz está inactiva o cuando la ruta HFRR se elimina o desactiva.

Las rutas de HFRR se purgan de inmediato en los siguientes casos:

  • Una ruta de respaldo cae y no hay otras rutas de respaldo potenciales.

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

  • El proceso de enrutamiento (rpd) termina.

Interfaces compatibles con HFRR

La HFRR solo se permite en interfaces Ethernet. La operación de confirmación falla si configura HFRR en interfaces de punto a punto.

Solo se aceptan interfaces configuradas bajo instancia de enrutamiento de tipo VPN de enrutamiento y reenvío (VRF). La operación de confirmación falla 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 se marca inactiva en la salida del show hfrr profiles comando:

  • La 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 de HFRR se deben configurar en el [edit interfaces] nivel jerárquico y también se deben adjuntar 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 estar marcada como inactiva en la salida del show hfrr profiles comando es cuando la interfaz está migrando de una instancia a otra y la configuración de HFRR se encuentra en la instancia de enrutamiento anterior.

La 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 RPD_ASSERT.