Troubleshooting de Falha de OMP e TLOC-Action

Introdução

Este documento descreve a solução de problemas de cenários de falha do Overlay Management Protocol (OMP) e as práticas recomendadas para fornecer resiliência de rede no Cisco SD-WAN.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento da solução de rede de longa distância definida por software (SD-WAN) da Cisco.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Cisco IOS Catalyst SD-WAN Manager ou vManage
• Cisco IOS Catalyst SD-WAN Validator ou vBond
• Controlador Cisco IOS Catalyst SD-WAN ou vSmart
• Dispositivos vEdge

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Visão geral do OMP

Como você sabe, o dispositivo Cisco SD-WAN Edge compartilha apenas as rotas com o controlador Catalyst SD-WAN. Para que uma rota seja válida e instalada em sua tabela de encaminhamento:

• O localizador de transporte do próximo salto (TLOC) deve estar acessível, ou seja, o dispositivo de borda deve ter uma rota válida para o TLOC.
• O TLOC para o qual ele aponta está ativo. Para que um TLOC fique ativo, uma sessão de encaminhamento bidirecional (BFD) ativa deve ser associada a esse TLOC. As sessões BFD são estabelecidas por cada dispositivo que cria uma sessão BFD separada com cada um dos TLOCs remotos. Se uma sessão BFD se tornar inativa, o controlador Cisco Catalyst SD-WAN removerá da tabela de encaminhamento todas as rotas OMP que apontam para esse TLOC.
• A rota OMP deve ser calculada da melhor forma possível.

Embora todas essas instruções sejam lógicas e diretas, há uma diferença significativa entre o OMP e os protocolos de roteamento tradicionais, como o Enhanced Interior Gateway Routing Protocol (EIGRP) e o Open Shortest Path First (OSPF) durante os cenários de falha.

Cenário de Falha do EIGRP

Na próxima rede, há três sites, ou seja, Site1, Site3 e Site4, com os roteadores RTR1/RTR2, RTR3 e RTR4, respectivamente, com uma única conexão WAN. O protocolo de roteamento tradicional EIGRP é executado sobre IPSec e IP1, IP2, IP3 e IP4 são os endereços IP da interface WAN nos respectivos locais.

A rede deve ser dividida, com foco em RTR3 e RTR4 por enquanto. Em RTR3, a rota para acessar 10.1.4.0/24 é através de um túnel direto entre RTR3-RTR4. Se o túnel for desativado, como o EIGRP reage nesse caso? Assim que o túnel for desativado, o EIGRP será executado e enviará uma consulta aos roteadores vizinhos para a rede 10.1.4.0/24 e, com base nas respostas recebidas, ele o examinará e instalará o novo caminho para o destino na tabela de roteamento para publicar o cálculo do melhor caminho.

Esta é uma explicação muito simples do processo de convergência do protocolo de roteamento tradicional. Portanto, os protocolos de roteamento tradicionais em geral, como o EIGRP, são capazes de executar a recomputação da rede:

• Quando a rota atual para um destino é desativada
• Quando não houver sucessores viáveis para um destino
• Quando ocorre uma alteração de topologia

Cenário de falha de OMP

Os dois cenários de falha do OMP são discutidos aqui:

1. Falha Direta
2. Falha Indireta

Falha Direta

Na próxima topologia, há três locais com uma única conexão de transporte.

Suponha que tudo esteja definido como padrão no controlador Catalyst SD-WAN. Os dispositivos vEdge compartilham as informações de roteamento diretamente com o controlador Catalyst SD-WAN e o controlador as compartilha com todos os dispositivos vEdge. A próxima topologia mostra a tabela de roteamento para todos os roteadores:

No momento, todas as sessões de BFD estão ativas.

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  - 

Se a conectividade entre vEdge3 e vEdge4 estiver desativada, quando o túnel for desativado, tanto vEdge3 como vEdge4 também terão suas sessões BFD desativadas. Isso faz com que eles marquem as respectivas rotas como 'Inválido' e 'TLOC Não Resolvido'. Você pode ver isso na próxima saída:

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  - 

Falha Indireta

Para entender "Falha indireta", suponha que a política de controle seja definida para alterar o próximo salto no vEdge3 para a rota 10.1.4.0/24 via vEdge2, e no vEdge4 o próximo salto para 10.1.3.0/24 seja alterado para vEdge1. Em outras palavras, para o tráfego entre vEdge 3 e 4, vEdge 2 e 1 foram inseridos como saltos intermediários. Você pode ver isso no próximo diagrama:

Se houver uma falha de rede que resulte em perda de conectividade entre vEdge2 e vEdge4, enquanto o túnel de sobreposição entre T2-T4 estiver inoperante, o vEdge3 ainda terá uma rota válida para 10.1.4.0 via T2. Portanto, ele envia tráfego para o vEdge2. O vEdge2 não tem um túnel válido com vEdge4, portanto, as rotas não estarão mais ativas nele, descartando o tráfego.

Com base nos registros e testes anteriores, pode-se concluir que:

• Com o OMP, não há descoberta automática de pares de roteamento e próximos saltos 
• Não há recálculo de topologia quando um túnel é desativado
• As rotas OMP para um prefixo de destino nunca são alteradas quando um túnel é desativado. A única alteração que ocorre é a acessibilidade ao próximo salto, ou seja, TLOC.
• Em caso de falha de sobreposição direta, uma redundância de túnel com vários túneis para o mesmo destino deve ser fornecida.
• Deve-se tomar um cuidado extra ao introduzir saltos/saltos intermediários no caminho de sobreposição e deve-se fornecer redundância de túnel para evitar a falta de tráfego.

Agora, você sabe que, por padrão, o OMP não recalcula nem redireciona em caso de falha de sobreposição. Para superar esse problema, você pode habilitar um recurso chamado 'TLOC-Action' através de uma Política de Controle.

TLOC-ação

• No Cisco SD-WAN, uma 'Ação TLOC' dentro de uma política de controle permite a inserção de um salto intermediário (TLOC) a ser usado para o encaminhamento de tráfego enquanto mantém a visibilidade do caminho completo da origem ao destino. Isso significa que a configuração da opção de ação TLOC permite que o Controlador Cisco Catalyst SD-WAN execute o rastreamento de ponta a ponta do caminho para o dispositivo destino final. Se esse caminho cair, o controlador informará os roteadores de borda da WAN que receberam essa rota OMP.
• Ele fornece um caminho de backup em caso de falha do link primário, aumentando assim a resiliência da rede e a tolerância a falhas dentro da rede de sobreposição SD-WAN. É uma forma de controlar como o tráfego é roteado através da rede, manipulando os TLOCs usados para alcançar um destino.
• Quando uma Ação TLOC é definida em uma política, ela instrui o controlador SD-WAN a inserir um TLOC intermediário no cálculo da rota, o que significa que o tráfego irá primeiro para esse local de 'backup' especificado antes de chegar ao destino final, se necessário.
• Isso é particularmente útil para cenários em que você deseja garantir a conectividade, mesmo se um enlace principal for desativado, redirecionando automaticamente o tráfego por um caminho diferente (através do TLOC especificado).

Na próxima topologia, vamos nos concentrar em vEdge2, vEdge3 e vEdge4 para entendê-lo melhor. No momento, nenhuma política está definida e o tráfego de dados para 10.1.4.0/24 no vEdge3 está passando por um túnel direto entre T3 e T4.

Para oferecer tolerância a falhas e resiliência da rede, a política de controle é configurada para redirecionar o tráfego por um caminho diferente (através do TLOC especificado).

• O vEdge4 envia a atualização OMP para sua rede diretamente conectada 10.1.4.0/24 com próximo salto T4 para o controlador Catalyst SD-WAN como '10.1.4.0/24 via T4'.
• Essa rota corresponde a uma política de controle configurada no controlador SD-WAN e define um novo TLOC e ações TLOC de acordo com a política definida nele, ou seja, ela insere o novo 'TLOC intermediário'.
• O controlador anuncia a rota OMP para vEdge1 com dois próximos saltos agora - TLOC intermediário (T3, 3.3.3.3) e TLOC final (próximo salto-T4 da rota original). Isso fornece inteligência ao vEdge1 de que o prefixo de destino 10.1.4.0/24 pode ser acessado via T2 e via T4.

Agora, com base no vEdge1 definido como TLOC-Action, encaminhe o tráfego para 10.1.4.0/24. Assim, você pode definir esses quatro tipos de ações TLOC na política do plano de controle:

1. Estrito (padrão) - O 'TLOC-Action strict' define que o tráfego entre vEdge1 e vEdge4 deve ser via T3 (salto intermediário) e o tráfego deve ser descartado se o túnel entre vEdge1 e vEdge4 for desativado.
2. Primário - O 'TLOC-Action primary' define que o tráfego entre o vEdge1 e o vEdge4 passa pelo salto intermediário T3 (3.3.3.3) e, se esse túnel de sobreposição for desativado, o controlador SD-WAN informará o vEdge1 e o tráfego roteado pelo túnel direto para T4.
3. Backup - O 'backup TLOC-Action' define que o tráfego entre vEdge1 e vEdge4 vai diretamente para a LOC final (próximo salto -T4 da rota original) e se o túnel de sobreposição direta entre vEdge1 e vEdge4 for desativado, o controlador SD-WAN informará vEdge1 e o tráfego vai através do salto intermediário T3.
4. Equal-Cost Multi-Path (ECMP) - O 'TLOC-Action ECMP' especifica que, em circunstâncias normais, a comunicação entre vEdge1 e vEdge4 é balanceada por meio do salto intermediário T3 e do salto final T4.