Introducción
Este documento describe el concepto de convergencia con Topology Independent (TI) - Loop-Free Alternative (LFA), que es una función altamente enfocada. Detalla el mecanismo de la convergencia de la ruta de políticas de routing de segmentos (SR) - ingeniería de tráfico (TE) con protección TI-LFA como base con un diagrama de topología basado en los requisitos de las redes XYZ.
Detección de fallas de link
Tenga en cuenta que la convergencia de la ruta de políticas SR-TE y las funciones de TI-LFA son independientes entre sí y funcionan por separado. Sin embargo, la función TI-LFA se agrega para realizar una detección rápida de la falla de la trayectoria de política SR-TE principal y un switching de tráfico inferior a 50 mseg a la trayectoria de respaldo predefinida en condiciones de red ideales. La política SR-TE funcionaría perfectamente sin TI-LFA, sin embargo, en ese escenario el número de convergencia dependería únicamente del protocolo de gateway interior (IGP) y sería mucho mayor que 50 ms.
En el escenario de falla de link, nuestro objetivo es mantener el tiempo de convergencia lo más bajo posible, lo que minimizaría la pérdida de paquetes durante el evento de caída/inestabilidad del link.
La detección del evento de link caído en el nodo de cabecera puede ocurrir principalmente por estos métodos:
1. Detección en la capa física en caso de rotura de enlaces adyacentes.
2. Detección por BFD sobre Bundle en caso de links remotos rotos.
En el primer caso, la detección es más rápida y el tiempo de convergencia es menor que la segunda opción, donde la detección depende del intervalo BFD configurado/temporizador muerto y el punto de red exacto donde el link se desactivó. Sin embargo, una detección muy rápida no significa necesariamente una convergencia tan rápida, ya que la red de la organización XYZ es una estructura de varias capas con tráfico de servicio integral que cubre varios saltos.
Dado que la red de la organización XYZ está contenida dentro de un único AS BGP y un único dominio IGP, aquí las rutas de respaldo predefinidas TI-LFA transportan inmediatamente el tráfico de failover después de una falla de link en todos los escenarios y garantizan una pérdida mínima de paquetes y una cobertura completa de prefijos independientemente del estado de la topología. Las rutas primarias/secundarias definidas por políticas de SR-TE pueden tardar un tiempo en converger debido al IGP y, en última instancia, hacerse cargo del tráfico de servicio de extremo a extremo a través del núcleo que puede o no coincidir con las rutas predefinidas de TI-LFA.
Escenarios de convergencia detallados
Para obtener más información, veamos el ejemplo detallado aquí que explica la ruta de tráfico con las políticas SR-TE e TI-LFA como el mecanismo de convergencia de la red de la organización XYZ.
Configuración SR de ejemplo alineada con los diagramas de topología:
segment-routing
traffic-eng
!
!
segment-list PrimaryPath1
index 10 mpls adjacency 10.1.11.0 --> First Hop (P1 node) of the explicit-path
index 20 mpls adjacency 10.1.3.1 --> Second Hop (P3 node) of the explicit-path
index 30 mpls adjacency 10.3.13.1 --> Third Hop (PE3 node) of the explicit-path
!
policy POL1
source-address ipv4 11.11.11.11 --> Source Node of the explicit-path
color 10 end-point ipv4 33.33.33.33 --> Destination Node of the explicit-path
candidate-paths
preference 100 --> Secondary Path taken care of dynamically by IGP TI-LFA
dynamic
metric
type igp
!
!
!
preference 200
explicit segment-list PrimaryPath1 --> Primary Explicit-Path of the SR-TE policy
!
!
En un escenario normal, el tráfico debe atravesar de PE1 a PE3 a través de una de las dos trayectorias candidatas posibles PE1 > P1 > P3 > PE3
y PE1 > P2 > P4 > PE3
de la política SR-TE, la trayectoria explícita principal configurada por el administrador con la Lista de adyacencia (Adj) - Identificador de segmento (SID) 10.1.11.0, 10.1.3.1, 10.3.13.1
o la trayectoria dinámica secundaria determinada por el IGP en cuestión. El administrador prefiere utilizar la ruta de acceso del candidato principal y sólo retroceder a la ruta de acceso secundaria cuando la principal está inactiva. Por lo tanto, se asigna un valor de preferencia más alto a la trayectoria del candidato principal que indica una trayectoria preferida. Por ejemplo, la ruta del candidato principal puede tener una preferencia de 200
y la ruta del candidato secundario tiene una preferencia de 100
.
Figura 1: Situación de tráfico normal: ruta del candidato principal SR-TE
Cualquier ruta de acceso candidata se utiliza cuando es válida, y el alcance de los SID que la constituyen determina el criterio de validez.
Cuando ambas trayectorias candidatas son válidas y utilizables, la cabecera PE1 selecciona la trayectoria de preferencia más alta e instala la lista SID de esta trayectoria 10.1.11.0, 10.1.3.1, 10.3.13.1
en su tabla de reenvío. En cualquier momento, el tráfico de servicio que se dirige a esta política de SR se envía solamente en la trayectoria seleccionada, cualquier otra trayectoria de candidato dinámica está inactiva.
Se selecciona una ruta de acceso candidata cuando tiene el valor de preferencia más alto entre todas las rutas de acceso candidatas válidas de la directiva SR. La ruta elegida también se denomina "ruta activa" de la política de SR.
Convergencia de fallas de link: la ruta principal pasa al estado inactivo
En algún momento, puede producirse un fallo de enlace en la red. El link fallido puede ser un link entre dos nodos cualesquiera, por ejemplo, P1 y P3. Tan pronto como se detecte la falla por cualquier medio como se describe al principio de la sección, la protección TI-LFA debe garantizar que los flujos de tráfico se redirijan rápidamente a la trayectoria de protección TI-LFA, idealmente dentro de los 50 mseg.
Tenga en cuenta que en este escenario, la trayectoria de respaldo determinada por TI-LFA como se muestra en la Figura 2. es diferente de la trayectoria de política de respaldo convergente en última instancia determinada por IGP en la Figura 3. Esto es bastante normal, ya que la ruta de copia de seguridad de Ti-LFA la determina localmente el nodo de punto de reparación local (PLR) donde se ha producido el error; sin embargo, la ruta de copia de seguridad de la política SR-TE optimizada la determina la convergencia IGP el nodo de cabecera que contiene las decisiones de política SR-TE.
Figura 2: Escenario de tráfico de failover a través de la trayectoria de respaldo TI-LFA
El tráfico continúa fluyendo a través de la trayectoria de protección TI-LFA hasta que, finalmente, la cabecera PE1 detecta a través de la inundación IGP que el SID 10.1.3.1
del link fallido se ha vuelto inválido. A continuación, PE1 evalúa la validez de la lista de SID de la ruta 10.1.11.0, 10.1.3.1, 10.3.13.1
e invalida esta lista debido a la presencia del SID no válido 10.1.3.1
. Invalida simultáneamente la ruta del candidato y vuelve a ejecutar el proceso de selección de ruta de la política SR-TE. PE1, posteriormente, selecciona otra trayectoria candidata válida con el siguiente valor de preferencia más alto e instala la lista SID 10.2.11.0, 10.2.4.1, 10.4.13.1
de la nueva trayectoria candidata secundaria en la tabla de reenvío. Sin embargo, esta ruta secundaria del candidato es de naturaleza dinámica, determinada por IGP Open Shortest Path First (OSPF), y no tiene control administrativo. Hasta este paso, el tráfico fluye a través de la ruta protegida TI-LFA; pero después de esto, se dirige a la ruta secundaria recientemente preferida de la política SR-TE.
Figura 3: Escenario de tráfico de conmutación por fallo a través de la ruta del candidato secundario SR-TE
Pasos de resumen:
1. Sobre el punto de fallo:
- La capa 1/BFD señala la ruta principal hasta la FIB
- FIB envía al hardware la ruta de respaldo establecida con TI-LFA
- Interrupción de tráfico esperada:
- Enlace caído: ~50 ms
- Pérdida de peer de BFD: tiempo muerto de BFD + ~50 ms
- El peering OSPF sobre el link perdido deja de funcionar
2. Todos los routers OSPF en el dominio se enteran de la pérdida de SID a través de la inundación de Link State Advertisement (LSA)
3. En la cabecera SR-TE PE1:
- OSPF converge
- La lista SID de ruta principal de la política SR-TE se invalida
- La ruta del candidato principal deja de funcionar
- Se valida la lista SID de la ruta de acceso del candidato secundario y se activa
- El tráfico se envía a través de una ruta secundaria sin ninguna pérdida de tráfico de servicio
Reconvergencia de fallo de enlace: ruta principal de vuelta al estado activo
Mientras tanto, una vez restaurado el vínculo principal con error, la ruta principal original con preferencia (200) vuelve a ser válida y, por lo tanto, el encabezado PE1 realiza el procedimiento de selección de la ruta de acceso de la directiva SR-TE, selecciona la ruta de acceso candidata explícita válida con la preferencia más alta y actualiza su tabla de reenvío con la lista SID de la ruta principal original. El tráfico de servicio que se dirige a esta política SR se envía de nuevo en la trayectoriaPE1 > P1 > P3 > PE3
original.
Figura 4: Escenario de tráfico reconvergente
Pasos de resumen:
1. La Capa 1/BFD señala la trayectoria primaria de respaldo y se notifica a OSPF.
2. El tráfico se sigue reenviando a través de la ruta candidata de respaldo de políticas SR-TE.
3. Después de un tiempo, la lista SID de la ruta candidata principal de la política SR-TE se valida a través de la inundación OSPF LSA.
4. El tráfico se conmuta de la trayectoria del candidato de respaldo de políticas SR-TE a la trayectoria del candidato principal de políticas SR-TE con pérdida de tráfico cero.
Para concluir, estos escenarios proporcionan una explicación teórica del proceso de convergencia y los números de convergencia ideales; sin embargo, necesita probar los números de convergencia reales en el laboratorio que imitan la red de producción y la configuración lo más cerca posible y disparan diferentes puntos de falla en la red que uno puede prever.
Precaución: Tenga en cuenta que este documento explica solamente los escenarios de Protección de link ya que la Protección de nodo no funciona con las trayectorias explícitas SR-TE si la trayectoria explícita definida toca nodos intermedios. Esto se debe a que TI-LFA toma cada salto intermedio configurado como el nodo de destino y, en caso de que cualquiera de estos falle, no puede resolver el destino final. Se trata de una limitación tecnológica y no está restringida a ninguna plataforma o versión de imagen. La solución para esta limitación se ha tratado en la Parte 2 de este documento, como se menciona en la sección Información Relacionada.
Software utilizado
El software utilizado para probar y validar la solución es Cisco IOS®XR 7.3.2.
Información Relacionada