Sécurité et VPN : Négociation IPSec/protocoles IKE

Scripts EEM utilisés pour dépanner des instabilités de tunnel provoquées par les index non valides de paramètre de Sécurité

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit une des questions d'IPsec les plus communes, qui est que les associations de sécurité (SAS) peuvent devenir hors du sync entre les périphériques de pair. En conséquence, un périphérique chiffrant chiffrera le trafic avec SAS que l'unité de chiffrement de pair ne connaît pas.

Remarque: Contribué par Anu M Chacko, ingénieur TAC Cisco.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ces informations dans ce document sont basées sur des tests terminés avec la release 15.1(4)M4 de Cisco IOSÝ. Les scripts et la configuration devraient fonctionner avec des versions de logiciel plus tôt de Cisco IOS aussi bien, puisque l'utilisation de les deux applet a inclus la version 3.0 du gestionnaire d'événement (EEM) qui est prise en charge dans la Cisco IOS version 12.4(22)T ou ultérieures. Cependant, ceci n'a pas été testé.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problème

Des paquets sont lâchés sur le pair avec ce message connecté au Syslog :

*Mar 12 18:22:10.706: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet 
   has invalid spi for destaddr=213.163.222.7, prot=50, spi=0x68842105(1753489669), 
   srcaddr=11.1.1.3, input interface=Ethernet0/0

Pour des informations détaillées sur les index non valides de paramètre de Sécurité (SPI), référez-vous aux erreurs d'IPSec %RECVD_PKT_INV_SPI et à la reprise non valide SPI. Ce document décrit comment dépanner les scénarios dans lesquels l'erreur se produit par intermittence, qui le rend dur pour collecter les données nécessaires pour dépanner.

Ce type de problème n'est pas comme le dépannage VPN normal, où vous pouvez obtenir met au point quand le problème se pose. Afin de dépanner les instabilités intermittentes de tunnel provoquées par des SPI non valides, vous devez d'abord déterminer comment les deux headends sont sortis du sync. Puisqu'il est impossible à prévoir quand la prochaine panne se produira, les scripts EEM sont la solution.

Solution

Puisqu'il est important de savoir ce qui se produit avant que ce message de Syslog soit déclenché, continuez à exécuter le conditionnel met au point sur les routeurs et les envoie à un serveur de Syslog de sorte qu'il n'affecte pas le trafic de production. Si met au point sont activés dans le script à la place, ils sont générés après que le message de Syslog soit déclenché qui peut ne pas être utile. Voici une liste de met au point que vous pourriez vouloir s'exécuter sur l'expéditeur de ce log et le récepteur :

debug crypto condition peer ipv4 <peer IP address>
debug crypto isakmp
debug crypto ipsec
debug crypto engine

Le script EEM est conçu pour faire deux choses :

  1. Arrêtez met au point sur le récepteur quand ils sont collectés pour 18 secondes après que le premier message de Syslog est généré. Le temporisateur de délai pourrait dont devoir être modifié, dépend de la quantité met au point/logs générés.

  2. En même temps il désactive le met au point, fait envoyer un déroutement SNMP au pair, qui désactive alors met au point sur le périphérique de pair.

Configuration SNMP

Les configurations de Protocole SNMP (Simple Network Management Protocol) sont affichées ici :

Receiver:
========

snmp-server enable traps event-manager
snmp-server host 11.1.1.3 public event-manager 
snmp-server manager

Sender:
=======

snmp-server enable traps event-manager
snmp-server host 213.163.222.7 public event-manager
snmp-server manager

Script final

Des scripts pour le récepteur et l'expéditeur sont affichés ici :

Receiver:
========

!--- To test if this output gets logged to the file called "hub"

sh ip int bri | tee /append disk0:hub.txt    
conf t
!
event manager applet command_hub
event syslog pattern "CRYPTO-4-RECVD_PKT_INV_SPI.*srcaddr=11.1.1.3"
action 1 cli command "enable"
action 2 syslog msg "command_hub is running ..." priority informational
action 3 cli command "show crypto sockets | append disk0:hub.txt"
action 4 cli command "show crypto isa sa | append disk0:hub.txt"
action 5 cli command "show crypto ipsec sa detail | append disk0:hub.txt"
action 6 cli command "show dmvpn detail | append disk0:hub.txt"
action 7 wait 18
action 8 cli command "undebug all"
action 8.1 snmp-trap intdata1 2323232 strdata ""
action 9 syslog priority informational msg "DONE ON HUB"
!
end

Sender: 
=======

conf t
!
event manager applet spoke_app
 event snmp-notification oid 1.3.6.1.4.1.9.10.91.1.2.3.1.9. 
    oid-val "2323232" op eq src-ip-address 213.163.222.7 maxrun 35
 action 1.0 syslog msg "Received trap from Hub..." 
 action 2.0 cli command "enable"
 action 3.0 cli command "undebug all"
 action 4.0 syslog msg "DONE ON SPOKE"
!
end

Logs de script EEM

Une liste de messages de log de script EEM est affichée ici :

Receiver:
=======

*Mar 12 18:22:10.706: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet 
    has invalid spi for destaddr=213.163.222.7, prot=50, spi=0x68842105(1753489669), 
    srcaddr=11.1.1.3, input interface=Ethernet0/0
*Mar 12 18:22:10.727: %HA_EM-6-LOG: command_hub: command_hub is running ...
hub#
*Mar 12 18:22:30.026: %HA_EM-6-LOG: command_hub: DONE ON HUB

Sender:
=======

spoke#
*Mar 12 18:22:30.542: %HA_EM-6-LOG: spoke_app: Received trap from Hub...
*Mar 12 18:22:30.889: %HA_EM-6-LOG: spoke_app: DONE ON SPOKE

Vérification

Afin de vérifier le problème a été résolu, sélectionne la commande de show debug.

Receiver:
=========
hub# show debug


Sender:
=======
spoke# show debug

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 116005