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)
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
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:
- Ambos os SLAs falharam. Isso significa:
- A conectividade da Camada 3 através da camada inferior (Internet/MPLS) entre os dois pares foi interrompida. Isso precisa de mais investigação.
- Não há problema com o túnel. Falhou porque é vítima da interrupção da parte inferior.
- O SLA físico não falha, mas o SLA de túnel falha. Isso significa:
- A conectividade da camada 3 através da Internet entre os dois pares funciona corretamente.
- Há um problema com o túnel. É necessária uma investigação mais aprofundada do túnel.
- Nenhum dos SLAs falhou. Isso significa:
- A conectividade da camada 3 através da Internet entre os dois pares funciona corretamente.
- A conectividade unicast da camada 3 através do túnel entre os dois pares funciona corretamente.
- 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.
- Se o teste funcionar, isso indica um problema de aplicativo (EIGRP/OSFP/BGP). É necessária uma investigação mais aprofundada do protocolo.