Solución de Problemas de Inestabilidad de IGP, Pérdida de Paquetes o Rebote de Túnel a través de un Túnel VPN con EEM y IP SLAs

Introducción

Este documento describe los pasos a seguir cuando experimenta inestabilidad EIGRP/OSPF/BGP sobre un túnel DMVPN/GRE/sVTI/FlexVPN.

Antecedentes

Para resolver este problema, la primera pregunta que debe responderse es "¿Se trata de un problema de VPN, protocolo de ruteo o ISP?" Para responder a la pregunta, las pruebas de conectividad en la capa inferior (normalmente Internet o una WAN privada) y superposición (normalmente el túnel VPN) deben realizarse durante el momento de la inestabilidad/interrupción. Desafortunadamente, estos eventos de inestabilidad pueden ser transitorios e intermitentes y, como resultado, puede ser difícil realizar estas pruebas durante el momento del problema. Este documento proporciona orientación sobre el uso del IP Service Level Agreement (SLA), los objetos de seguimiento y Embedded Event Manager (EEM) para recopilar esta información automáticamente en el momento del problema.

Información sobre la Función

Los SLA de IP son procesos que se ejecutan en el router en segundo plano, que prueban una serie de condiciones de red. En este documento, la conectividad IP general se prueba con el "icmp-echo" prueba.

A continuación, un objeto de seguimiento puede realizar un seguimiento del estado de IP SLA. Luego, con un applet EEM, el estado de la red se puede registrar en el búfer syslog cuando cambia el objeto de seguimiento.

Utilice el estado de red registrado en el historial de registros del sistema para comprender el estado de la red durante la inestabilidad/interrupción y determinar si hubo un problema de cifrado, transporte o protocolo de gateway interior (IGP).

Metodología

Paso 1. Definir un SLA para realizar el seguimiento de los elementos subyacentes (conectividad a Internet)

• Opción A
  Dirección IP pública a dirección IP pública (172.18.3.52 > 172.20.5.43). Dado que el par remoto suele responder al ICMP, este SLA sólo debe definirse en un dispositivo.
  

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

• Opción B

  Nota: En algunos entornos, los paquetes de protocolo de mensajes de control de Internet (ICMP) se bloquean en la red subyacente/de transporte. En estos entornos, udp-echo los paquetes se pueden utilizar en lugar de icmp-echo para IP SLA.

  
  Iniciador de IP SLA (router izquierdo)
  

  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 IP SLA (router derecho)
  

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

Paso 2. Definir un SLA para realizar el seguimiento de la superposición (conectividad de túnel)

• Dirección IP del túnel para la dirección IP del 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

Estos SLA envían un solo paquete cada cinco segundos a los pares definidos. Si el par responde, el SLA se marca "OK". Si no responde, se marca "Timeout". Los objetos de seguimiento supervisan el estado del SLA.

Paso 3. Definir objetos de seguimiento para supervisar los estados de SLA

• Objeto de pista de conectividad subyacente
  

  track 100 ip sla 100
     delay down 15 up 15

• Objeto de pista de conectividad superpuesta
  

  track 200 ip sla 200
     delay down 15 up 15

Cuando cambia el objeto de seguimiento, se puede insertar un mensaje en los syslogs.

Paso 4. Definir un applet EEM para grabar cuando cambian los objetos de pista

• Cree un applet EEM para cuando falle el transporte subyacente y otro para cuando se recupere
  

  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!"

• Cree un applet EEM para cuando falle el transporte superpuesto y otro para cuando se recupere
  

  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álisis de datos

Cuando se produce una interrupción, recopile el resultado del show log comando. Busque los mensajes SLA que se muestran en la sección anterior.

Existen tres escenarios potenciales:

1. Ambos SLA fallan. Esto significa:
   1. Se interrumpió la conectividad de capa 3 en la capa subyacente (Internet/MPLS) entre los dos peers. Esto requiere una investigación más a fondo.
   2. No hay problema con el túnel. Fracasó porque es víctima de la interrupción de la capa inferior.
2. El SLA físico no falla, pero el SLA de túnel lo hace. Esto significa:
   1. La conectividad de Capa 3 a través de Internet entre los dos peers funciona correctamente.
   2. Hay un problema con el túnel. Es necesario investigar más el túnel.
3. Ninguno de los SLA falla. Esto significa:
   1. La conectividad de Capa 3 a través de Internet entre los dos peers funciona correctamente.
   2. La conectividad de unidifusión de capa 3 a través del túnel entre los dos peers funciona correctamente.
   3. Se desconoce la conectividad de multidifusión de capa 3 a través del túnel. Para probar esto, haga ping a la dirección multicast utilizada por el IGP.
   4. Si la prueba funciona, esto indica un problema de aplicación (EIGRP/OSFP/BGP). Es necesaria una investigación adicional del protocolo.