Dépannage des pannes IGP, de la perte de paquets ou du renvoi de tunnel sur un tunnel VPN avec EEM et IP SLA

Introduction

Ce document décrit les étapes à suivre lorsque vous rencontrez des basculements EIGRP/OSPF/BGP sur un tunnel DMVPN/GRE/sVTI/FlexVPN.

Informations générales

Afin de résoudre ce problème, la première question à laquelle il faut répondre est « S'agit-il d'un problème de VPN, de protocole de routage ou de FAI ? » Pour répondre à la question, les tests de connectivité sur la sous-couche (généralement Internet ou un WAN privé) et la superposition (généralement le tunnel VPN) doivent être effectués pendant le temps de la panne/panne. Malheureusement, ces événements de battement peuvent être transitoires et intermittents et, par conséquent, il peut être difficile d'effectuer ces tests au moment du problème. Ce document fournit des conseils sur l'utilisation du contrat de niveau de service IP (SLA), des objets de suivi et du gestionnaire d'événements intégré (EEM) afin de collecter ces informations au moment du problème automatiquement.

Informations sur les fonctionnalités

Les SLA IP sont des processus qui s’exécutent en arrière-plan sur le routeur et qui testent un certain nombre de conditions réseau. Dans ce document, la connectivité IP générale est testée à l'aide de la "icmp-echo" test.

Un objet de piste peut ensuite suivre l'état du SLA IP. Ensuite, avec une applet EEM, l'état du réseau peut être enregistré dans la mémoire tampon syslog lorsque l'objet track change.

Utilisez l'état du réseau enregistré dans l'historique des syslogs pour comprendre l'état du réseau pendant la panne/panne et déterminer s'il y a eu un problème de cryptage, de transport ou de protocole IGP (Interior Gateway Protocol).

Méthodologie

Étape 1. Définir un SLA pour suivre la sous-couche (connectivité Internet)

• Option A 
  Adresse IP publique vers adresse IP publique (172.18.3.52 > 172.20.5.43). Puisque l’homologue distant répond généralement à ICMP, ce SLA doit être défini sur un seul périphérique.
  

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

• Option B 

  Note: Dans certains environnements, les paquets ICMP (Internet Control Message Protocol) sont bloqués dans le réseau de sous-couche/transport. Dans ces environnements, udp-echo Les paquets peuvent être utilisés au lieu de icmp-echo pour IP SLA.

  
  Initiateur IP SLA (routeur gauche)
  

  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

  Répondeur IP SLA (routeur droit)
  

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

Étape 2. Définir un SLA pour suivre la superposition (connectivité du tunnel)

• Adresse IP du tunnel vers adresse IP du tunnel (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

Ces SLA envoient un paquet toutes les cinq secondes aux homologues définis. Si l'homologue répond, le SLA est marqué "OK". S'il ne répond pas, il est marqué "Timeout". Les objets de suivi surveillent l'état du SLA.

Étape 3. Définir des objets de suivi pour surveiller les états SLA

• Objet de piste de connectivité sous-jacente
  

  track 100 ip sla 100
     delay down 15 up 15

• Objet de suivi de connectivité de superposition
  

  track 200 ip sla 200
     delay down 15 up 15

Lorsque l'objet de suivi change, un message peut être inséré dans les syslogs.

Étape 4. Définir une applet EEM à enregistrer lorsque les objets de suivi changent

• Créer une applet EEM pour quand le transport de la sous-couche échoue et une autre pour quand il se rétablit
  

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

• Créer une applet EEM pour quand le transport de superposition échoue et une autre pour quand il se rétablit
  

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

Analyse des données

En cas de panne, collectez la sortie de show log erasecat4000_flash:. Recherchez les messages SLA affichés dans la section précédente.

Il existe trois scénarios possibles :

1. Les deux SLA échouent. Cela signifie :
   1. La connectivité de couche 3 sur la sous-couche (Internet/MPLS) entre les deux homologues a été interrompue. Il faut approfondir cette question.
   2. Il n'y a aucun problème avec le tunnel. Il a échoué parce qu'il est victime de l'interruption de la sous-couche.
2. Le SLA physique n'échoue pas, mais le SLA du tunnel le fait. Cela signifie :
   1. La connectivité de couche 3 sur Internet entre les deux homologues fonctionne correctement.
   2. Il y a un problème avec le tunnel. Il est nécessaire d'approfondir l'étude du tunnel.
3. Aucun des contrats de niveau de service n'échoue. Cela signifie :
   1. La connectivité de couche 3 sur Internet entre les deux homologues fonctionne correctement.
   2. La connectivité de monodiffusion de couche 3 à travers le tunnel entre les deux homologues fonctionne correctement.
   3. La connectivité de multidiffusion de couche 3 à travers le tunnel est inconnue. Afin de tester ceci, envoyez une requête ping à l'adresse de multidiffusion utilisée par l'IGP.
   4. Si le test fonctionne, cela indique un problème d'application (EIGRP/OSFP/BGP). Il est nécessaire d'approfondir l'étude des protocoles.