Solucionar problemas de IGP Flaps, perda de pacotes ou devolução de túnel em um túnel VPN com EEM e IP SLAs

Introduction

Este documento descreve as etapas a serem seguidas ao experimentar flaps EIGRP/OSPF/BGP sobre um túnel DMVPN/GRE/sVTI/FlexVPN.

Informações de Apoio

Para solucionar esse problema, a primeira pergunta que precisa ser respondida é: "Isso é um problema de VPN, protocolo de roteamento ou ISP?" Para responder à pergunta, os testes de conectividade na parte inferior (geralmente a Internet ou uma WAN privada) e na sobreposição (geralmente o túnel VPN) devem ser realizados durante o tempo da oscilação/interrupção. Infelizmente, esses eventos da aba podem ser transitórios e intermitentes e, como resultado, pode ser difícil executar esses testes durante o tempo do problema. Este documento fornece orientação sobre o uso do Contrato de Nível de Serviço (SLA - Service Level Agreement) IP, rastrear objetos e do Embedded Event Manager (EEM - Embedded Event Manager) para coletar essas informações no momento do problema automaticamente.

Informações do recurso

Os SLAs IP são processos executados no roteador em segundo plano, que testam várias condições de rede. Neste documento, a conectividade IP geral é testada com o comando "icmp-echo" teste.

Um objeto de rastreamento pode então rastrear o estado do SLA IP. Em seguida, com um miniaplicativo EEM, o estado da rede pode ser registrado no buffer de syslog quando o objeto de rastreamento é alterado.

Utilize o estado da rede registrado no histórico de syslogs para entender o estado da rede durante a oscilação/interrupção e determinar se houve um problema de criptografia, transporte ou Interior Gateway Protocol (IGP).

Metodologia

Etapa 1. Definir um SLA para rastrear a base (conectividade com a Internet)

• Opção A
  Endereço IP público para o endereço IP público (172.18.3.52 > 172.20.5.43). Como o peer remoto geralmente responde ao ICMP, esse SLA só precisa ser definido em um dispositivo.
  

  ip sla 100
      icmp-echo 172.20.5.43 source-interface FastEthernet4
      frequency 5
  ip sla schedule 100 life forever start-time now
  

• Opção B

  Note: Em alguns ambientes, os pacotes ICMP (Internet Control Message Protocol) são bloqueados na rede de transporte/sub-camada. Nesses ambientes, udp-echo os pacotes podem ser usados em vez de icmp-echo para IP SLA.

  
  Iniciador de SLA IP (roteador esquerdo)
  

  ip sla 100
   udp-echo 172.20.5.43 1501 source-ip 172.18.3.52 source-port 1501 control disable
   frequency 5
  ip sla schedule 100 life forever start-time now

  Respondedor de SLA IP (roteador certo)
  

  ip sla responder
  ip sla responder udp-echo ipaddress 172.20.5.43 port 1501

Etapa 2. Definir um SLA para rastrear a sobreposição (conectividade de túnel)

• Endereço IP do túnel para o endereço IP do túnel (10.1.12.100 > 10.1.12.1)

  ip sla 200
      icmp-echo 10.1.12.1 source-interface Tunnel100
      frequency 5
  ip sla schedule 200 life forever start-time now

Esses SLAs enviam um único pacote a cada cinco segundos para os peers definidos. Se o peer responder, o SLA será marcado como "OK". Se não responder, está marcado como "Timeout". Os objetos de controle monitoram o estado do SLA.

Etapa 3. Definir objetos de controle para monitorar os estados do SLA

• Submeter o objeto de controle de conectividade
  

  track 100 ip sla 100
     delay down 15 up 15

• Objeto de controle de conectividade de sobreposição
  

  track 200 ip sla 200
     delay down 15 up 15

Quando o objeto de controle é alterado, uma mensagem pode ser inserida nos syslogs.

Etapa 4. Definir um miniaplicativo EEM para gravar quando os objetos de controle mudarem

• Criar um applet EEM para quando o transporte de sobreposição falhar e outro para quando ele se recuperar
  

  event manager applet ipsla100down 
      event track 100 state down
      action 1.0 syslog msg "Underlay SLA probe failed!"
  event manager applet ipsla100up 
     event track 100 state up
     action 1.0 syslog msg "Underlay SLA probe came up!"

• Criar um applet EEM para quando o transporte de sobreposição falhar e outro para quando ele se recuperar
  

  event manager applet ipsla200down 
      event track 200 state down
      action 1.0 syslog msg "Overlay SLA probe failed!"
  event manager applet ipsla200up 
     event track 200 state up
     action 1.0 syslog msg "Overlay SLA probe came up!"

Análise de dados

Quando ocorrer uma interrupção, colete a saída do comando show log comando. Procure as mensagens SLA mostradas na seção anterior.

Há três cenários possíveis:

1. Ambos os SLAs falharam. Isso significa:
   1. A conectividade da Camada 3 através da camada inferior (Internet/MPLS) entre os dois pares foi interrompida. Isso precisa de mais investigação.
   2. Não há problema com o túnel. Falhou porque é vítima da interrupção da parte inferior.
2. O SLA físico não falha, mas o SLA de túnel falha. Isso significa:
   1. A conectividade da camada 3 através da Internet entre os dois pares funciona corretamente.
   2. Há um problema com o túnel. É necessária uma investigação mais aprofundada do túnel.
3. Nenhum dos SLAs falhou. Isso significa:
   1. A conectividade da camada 3 através da Internet entre os dois pares funciona corretamente.
   2. A conectividade unicast da camada 3 através do túnel entre os dois pares funciona corretamente.
   3. A conectividade multicast da camada 3 através do túnel é desconhecida. Para testar isso, faça ping no endereço multicast usado pelo IGP.
   4. Se o teste funcionar, isso indica um problema de aplicativo (EIGRP/OSFP/BGP). É necessária uma investigação mais aprofundada do protocolo.