Software Cisco IOS y NX-OS : Cisco IOS Embedded Event Manager (EEM)

Utilice EEM con IP SLA para resolver problemas las aletas o la pérdida del paquete IGP a través de un túnel VPN

25 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (9 Julio 2014) | Comentarios


Contenido


Introducción

Muchos casos se abren con el síntoma “aletas EIGRP/OSPF/BGP sobre mi túnel DMVPN/GRE/sVTI”. Para resolver problemas este problema, la primera pregunta que necesita ser contestada es, “es ésta un VPN, un Routing Protocol o un problema ISP?”

La manera que esto puede ser probada es descubrir si el transporte subyacente todavía está funcionando correctamente durante la época del flap/caída del sistema. Desafortunadamente, estos datos son generalmente poste-evento revisado y son imposibles determinar este pedazo de datos. Este documento proporciona la información sobre el uso de los acuerdos llanos del servicio del IP (SLA), de los objetos y del administrador del evento integrado (EEM) de la pista para recoger esta información durante la época del problema.

Nota: Contribuido por Jay Taylor joven, ingeniero de Cisco TAC.

prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

  • IP SLAs

  • EEM

Componentes Utilizados

La información en este documento se basa en el código del Software Release 15.2(4)M de Cisco IOS� en 881, pero cualquier código reciente (el 15.0(1)M o más adelante) tendrá este soporte.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Información sobre la Función

El IP SLA es los procesos que se ejecutan en el router en el fondo que prueba un número variable de estado de la red. En esta Conectividad del documento IP general se prueba usando la prueba de la “ICMP-generación de eco”.

Después que el estado IP SLA está seguido usando un objeto de la pista. Entonces, usando un applet EEM, el estado de la red en el buffer del Syslog puede ser registrado tomando medidas cuando los cambios de estado del objeto de la pista.

Con el estado de la red incluido en línea con los Syslog, usted puede entender retroactivo al estado actual de la red durante el flap/interrupción y determinarlo si había un crypto, transporte, o problema IGP.

Metodología de Troubleshooting

http://www.cisco.com/c/dam/en/us/support/docs/ios-nx-os-software/ios-embedded-event-manager-eem/113696-eem-tshoot-igp-01.gif

Dos SLA separados se utilizan para seguir cada capa de conectividad del IP:

  • IP Address público al IP Address público (172.18.3.52 ---> 172.20.5.43)

    ip sla 100
           icmp-echo 172.20.5.43 source-interface FastEthernet4
           frequency 5
       ip sla schedule 100 life forever start-time now
  • Dirección IP del túnel para hacer un túnel la dirección IP (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 enviarán un solo paquete ping cada 5 segundos a los pares definidos. Si responde el ping SLA será OK marcado. Si no responde será “descanso marcado”. Entonces, los objetos de la pista se utilizan para seguir el estatus de SLA.

  • IP Address público a la pista de IP Address público

    track 100 ip sla 100
         delay down 15 up 15
  • Dirección IP del túnel para hacer un túnel la pista de la dirección IP

    track 200 ip sla 200
         delay down 15 up 15

Cuando el objeto de la pista cambia, un mensaje se puede insertar en los Syslog.

  • IP Address público a la pista de IP Address público

    event manager applet ipsla100down 
        event track 100 state down
        action 1.0 syslog msg "Physical SLA probe failed!"
    event manager applet ipsla100up 
       event track 100 state up
       action 1.0 syslog msg "Physical SLA probe came up!"
  • Dirección IP del túnel para hacer un túnel la pista de la dirección IP

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

Análisis de datos

Cuando ocurre una caída del sistema, recoja la salida del comando show log.

Busque los mensajes de SLA arriba.

Durante la caída del sistema, si usted ve:

  • Fall ambos SLA. Esto significa:

    • La Conectividad de la capa 3 a través de Internet entre los dos pares fue interrumpida. Esto necesita la investigación adicional.

    • No hay problema con el túnel. Está fallando porque es una víctima de la interrupción arriba.

  • SLA físico no falla pero el túnel SLA hace. Esto significa:

    • La Conectividad de la capa 3 a través de Internet entre los dos pares está trabajando correctamente.

    • Hay un problema con el túnel. La investigación adicional del túnel es necesaria.

  • Ninguno del fall SLA. Esto significa:

    • La Conectividad de la capa 3 a través de Internet entre los dos pares está trabajando correctamente.

    • La Conectividad del unicast de la capa 3 a través del túnel entre los dos pares está trabajando correctamente.

    • La Conectividad del Multicast de la capa 3 a través del túnel es desconocida. Esto puede ser probada haciendo ping a la dirección Multicast usada por el IGP.

    • Si las pruebas funcionas antedichas entonces esto indican un problema de la aplicación (EIGRP/OSFP/BGP). La investigación adicional del protocolo es necesaria.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 113696