Resolución de problemas de falla de OMP y acción de TLOC

Introducción

Este documento describe la solución de problemas de escenarios de falla del Protocolo de administración de superposición (OMP) y las prácticas recomendadas para proporcionar resistencia de red en Cisco SD-WAN.

Prerequisites

Requirements

Cisco recomienda que conozca la solución de red de área extensa definida por software (SD-WAN) de Cisco.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Cisco IOS Catalyst SD-WAN Manager (vManage)
• Cisco IOS Catalyst SD-WAN Validator (vBond)
• Cisco IOS Catalyst SD-WAN Controller (vSmart)
• Dispositivos vEdge

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si su red está activa, asegúrese de comprender el impacto potencial de cualquier comando.

Descripción general de OMP

Como sabe, el dispositivo Cisco SD-WAN Edge sólo comparte las rutas con el controlador Catalyst SD-WAN. Para que una ruta sea válida e instalada en su tabla de reenvío:

• El localizador de transporte de siguiente salto (TLOC) debe ser accesible; es decir, el dispositivo perimetral debe tener una ruta válida para el TLOC.
• El TLOC al que apunta está activo. Para que un TLOC esté activo, se debe asociar una sesión de reenvío bidireccional (BFD) activa a dicho TLOC. Las sesiones BFD son establecidas por cada dispositivo, lo que crea una sesión BFD independiente con cada uno de los TLOC remotos. Si una sesión BFD se vuelve inactiva, el controlador Cisco Catalyst SD-WAN elimina todas las rutas OMP que apuntan a ese TLOC de la tabla de reenvío.
• La ruta OMP se debe calcular como mejor.

Aunque todas estas sentencias son lógicas y directas, existe una diferencia significativa entre los protocolos de routing tradicionales y OMP, como el protocolo de routing de gateway interior mejorado (EIGRP) y el protocolo de ruta de acceso más corta primero (OSPF), en situaciones de fallos.

Escenario de falla EIGRP

En la siguiente red, hay tres sitios, a saber, Site1, Site3 y Site4, que tienen routers RTR1/RTR2, RTR3 y RTR4, respectivamente, con una única conexión WAN. El protocolo de routing tradicional EIGRP se ejecuta a través de IPSec e IP1, IP2, IP3 e IP4 son las direcciones IP de la interfaz WAN en las ubicaciones respectivas.

La red debe estar averiada, con un enfoque en RTR3 y RTR4 por ahora. En RTR3, la ruta para alcanzar el 10.1.4.0/24 es a través de un túnel directo entre RTR3-RTR4. Si el túnel se desactiva, ¿cómo reacciona EIGRP en este caso? Tan pronto como el túnel deja de funcionar, EIGRP ejecutará y enviará una consulta a los routers vecinos para la red 10.1.4.0/24, y basándose en las respuestas recibidas, lo examinará e instalará la nueva trayectoria para el destino en la tabla de ruteo después del cálculo de la mejor trayectoria.

Esta es una explicación muy simple del proceso de convergencia del protocolo de ruteo tradicional. Por lo tanto, los protocolos de routing tradicionales en general, como EIGRP, son capaces de realizar el recálculo de la red:

• Cuando la ruta actual a un destino deja de funcionar
• Cuando no hay sucesores factibles para un destino
• Cuando se produce un cambio de topología

Escenario de falla de OMP

Los dos escenarios de falla para OMP se discuten aquí:

1. Falla directa
2. Fallo Indirecto

Falla directa

En la siguiente topología, hay tres sitios con una única conexión de transporte.

Suponga que todo está configurado en forma predeterminada en el controlador Catalyst SD-WAN. Los dispositivos vEdge comparten la información de routing directamente con el controlador Catalyst SD-WAN y el controlador la comparte con todos los dispositivos vEdge. La siguiente topología muestra la tabla de ruteo para todos los routers:

Actualmente, todas las sesiones de BFD están activas.

vEdge-DC1# show bfd sessions
                                      SOURCE TLOC      REMOTE TLOC                                      DST PUBLIC                      DST PUBLIC         DETECT      TX
SYSTEM IP        SITE ID  STATE       COLOR            COLOR            SOURCE IP                       IP                              PORT        ENCAP  MULTIPLIER  INTERVAL(msec) UPTIME          TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1                 1        up          mpls             mpls             60.1.1.1                        20.1.1.1                        12346       ipsec  7           1000           0:00:03:12      0
2.2.2.2                 1        up          mpls             mpls             60.1.1.1                        10.10.20.2                    12406       ipsec  7           1000           0:06:28:51      0
4.4.4.4                 2        up          mpls             mpls             60.1.1.1                        30.1.1.1                        12386       ipsec  7           1000           0:00:00:51      0
                    

vEdge-DC1# show omp routes vpn 20 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                                            PATH                      ATTRIBUTE
VPN    PREFIX              FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
20     10.1.1.0/24        2.2.2.2          43     1005        C,I,R          installed      1.1.1.1                  mpls                           ipsec  -
                                      2.2.2.2          37     1006        C,I,R            installed     2.2.2.2                  mpls                           ipsec  -
20     10.1.3.0/24        0.0.0.0          66     1005     C,Red,R        installed      3.3.3.3                  mpls                           ipsec  -
20     10.1.4.0/24        2.2.2.2          45     1006         C,I,R          installed       4.4.4.4                 mpls                           ipsec  - 

Si la conectividad entre vEdge3 y vEdge4 está desactivada, cuando el túnel deja de funcionar, tanto vEdge3 como vEdge4 también tendrán caídas sus sesiones BFD. Esto hace que marquen las rutas respectivas como 'Inválidas' y 'TLOC sin resolver'. Puede ver esto en el siguiente resultado:

vEdge3# show bfd sessions
                                      SOURCE TLOC      REMOTE TLOC                                      DST PUBLIC                      DST PUBLIC         DETECT      TX           
SYSTEM IP        SITE ID  STATE       COLOR            COLOR            SOURCE IP                       IP                              PORT        ENCAP  MULTIPLIER  INTERVAL(msec) UPTIME           
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1                 1        up          mpls             mpls                     60.1.1.1                         20.1.1.1                      12386       ipsec          7                    1000                0:05:57:27                         
2.2.2.2                 1        up          mpls             mpls                     60.1.1.1                         10.10.20.2                  12426       ipsec           7                   1000               0:05:57:27                         
4.4.4.4                 4        down     mpls             mpls                     60.1.1.1                         30.1.1.1                      12406       ipsec          7                    1000                 NA                                     



vEdge3# show omp routes vpn 20 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                                            PATH                      ATTRIBUTE
VPN    PREFIX              FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1     10.1.1.0/24          2.2.2.2          43     1005        C,I,R                installed       1.1.1.1                  mpls                           ipsec  -
                                      2.2.2.2          37     1006        C,I,R                installed       2.2.2.2                  mpls                          ipsec  -
1    10.1.3.0/24           0.0.0.0          66     1005        C,Red,R           installed       3.3.3.3                 mpls                           ipsec  -
1     10.1.4.0/24          2.2.2.2          45     1006        Inv,U                installed       4.4.4.4                 mpls                           ipsec  - 

Fallo Indirecto

Para comprender la 'Falla indirecta', asuma que la política de control se define para cambiar el siguiente salto en vEdge3 para la ruta 10.1.4.0/24 a través de vEdge2, y en vEdge4 el siguiente salto para 10.1.3.0/24 se cambia a vEdge1. En otras palabras, para el tráfico entre vEdge 3 y 4, vEdge 2 y 1 se insertaron como saltos intermedios. Puede ver esto en el siguiente diagrama:

Si se produce un fallo de red que provoca una pérdida de conectividad entre vEdge2 y vEdge4, mientras el túnel de superposición entre T2-T4 está inactivo, vEdge3 sigue teniendo una ruta válida para 10.1.4.0 a través de T2. Por lo tanto, envía tráfico a vEdge2. vEdge2 no tiene un túnel válido con vEdge4, por lo que las rutas ya no estarán activas en él y, por lo tanto, se descartará el tráfico.

Sobre la base de los registros y ensayos anteriores, puede concluirse que:

• Con OMP, no hay detección automática de pares de ruteo y saltos siguientes 
• No hay recálculo de topología cuando un túnel deja de funcionar
• Las rutas OMP a un prefijo de destino nunca cambian cuando un túnel deja de funcionar. El único cambio que ocurre es la disponibilidad al salto siguiente, es decir, TLOC.
• En caso de falla de superposición directa, se debe proporcionar una redundancia de túnel con Múltiples Túneles al mismo destino.
• Se debe tener especial cuidado al introducir saltos/saltos intermedios en la trayectoria de superposición y se debe proporcionar redundancia de túnel para evitar el agujero de falta de tráfico.

Ahora ya sabe que, de forma predeterminada, OMP no vuelve a calcular ni a enrutar en caso de error de superposición. Para superar este problema, puede habilitar una función llamada 'TLOC-Action' a través de una política de control.

Acción de TLOC

• En Cisco SD-WAN, una 'acción TLOC' dentro de una política de control permite la inserción de un salto intermedio (TLOC) que se utilizará para el reenvío de tráfico mientras se mantiene la visibilidad en la ruta completa desde el origen hasta el destino. Esto significa que al establecer la opción de acción TLOC, el controlador Cisco Catalyst SD-WAN Controller puede realizar un seguimiento integral de la ruta al dispositivo de destino final. Si esa trayectoria deja de funcionar, el controlador informa a los routers periféricos WAN que recibieron esta ruta OMP.
• Proporciona una ruta de copia de seguridad en caso de fallo del enlace principal, lo que mejora la resistencia de la red y la tolerancia a fallos dentro de la red SD-WAN superpuesta. Es una manera de controlar cómo se rutea el tráfico a través de la red manipulando los TLOC usados para alcanzar un destino.
• Cuando se define una Acción TLOC en una política, se indica al controlador SD-WAN que inserte un TLOC intermedio en el cálculo de la ruta, lo que significa que el tráfico irá primero a esta ubicación de 'respaldo' especificada antes de alcanzar el destino final si es necesario.
• Esto es especialmente útil para escenarios en los que se desea garantizar la conectividad incluso si un link principal deja de funcionar, mediante el reenrutamiento automático del tráfico a través de una trayectoria diferente (a través del TLOC especificado).

En la siguiente topología, centrémonos en vEdge2, vEdge3 y vEdge4 para comprenderla mejor. Actualmente, no se ha definido ninguna política y el tráfico de datos para 10.1.4.0/24 en vEdge3 está atravesando un túnel directo entre T3 y T4.

Para proporcionar tolerancia a fallos y resistencia de red, la política de control se configura para volver a enrutar el tráfico a través de una ruta diferente (a través del TLOC especificado).

• vEdge4 envía la actualización de OMP para su red conectada directamente 10.1.4.0/24 con Next-Hop T4 a Catalyst SD-WAN Controller como '10.1.4.0/24 vía T4'.
• Esta ruta coincide con una política de control configurada en el controlador SD-WAN y establece un nuevo TLOC y TLOC-Actions según la política definida en él, es decir, inserta el nuevo 'TLOC intermedio'.
• El controlador anuncia la ruta OMP a vEdge1 con dos saltos siguientes ahora: TLOC intermedio (T3, 3.3.3.3) y TLOC final (salto siguiente-T4 de la ruta original). Esto proporciona inteligencia a vEdge1 de que el prefijo de destino 10.1.4.0/24 es accesible a través de T2 y T4.

Ahora, basándose en la acción TLOC definida vEdge1, reenvía el tráfico para 10.1.4.0/24. De modo que puede definir estos cuatro tipos de acciones TLOC en la política del plano de control:

1. Estricto (predeterminado): el 'estricto de acción TLOC' define que el tráfico entre vEdge1 y vEdge4 debe ser a través de T3 (salto intermedio) y el tráfico debe descartarse si el túnel entre vEdge1 y vEdge4 deja de funcionar.
2. Primario: 'TLOC-Action primary' define que el tráfico entre vEdge1 y vEdge4 pasa a través del salto intermedio T3 (3.3.3.3) y si este túnel superpuesto deja de funcionar, el controlador SD-WAN informa a vEdge1 y el tráfico ruteado a través del túnel directo a T4.
3. Copia de seguridad: la "copia de seguridad de acción TLOC" define que el tráfico entre vEdge1 y vEdge4 va directamente a la última LOC (siguiente salto -T4 de la ruta original) y, si el túnel de superposición directa entre vEdge1 y vEdge4 deja de funcionar, el controlador SD-WAN informa a vEdge1 y el tráfico pasa a través de la ruta intermedia T3.
4. Equal-Cost Multi-Path (ECMP): 'TLOC-Action ECMP' especifica que, en circunstancias normales, la comunicación entre vEdge1 y vEdge4 se equilibra mediante la carga a través del salto intermedio T3 y el salto final T4.