Seguridad y VPN : Negociación IPSec/Protocolos IKE

Scripts EEM usados para resolver problemas las aletas del túnel causadas por los índices inválidos del parámetro de seguridad

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento describe uno de la mayoría de los problemas del IPSec comunes, que es que las asociaciones de seguridad (SA) pueden convertirse fuera de sincronizan entre los dispositivos de peer. Como consecuencia, un dispositivo que cifra cifrará el tráfico con los SA que el encryptor del par no conoce alrededor.

Nota: Contribuido por Anu M Chacko, ingeniero de Cisco TAC.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Esta información en este documento se basa en las pruebas completadas con la versión 15.1(4)M4 del ½ del ¿Â de Cisco IOSïÂ. Los scripts y la configuración deben trabajar con versiones del Cisco IOS Software anteriores también, puesto que el uso de ambos applet integró la versión 3.0 del administrador del evento (EEM) que se soporta en el Cisco IOS Release 12.4(22)T o Posterior. Sin embargo, esto no se ha probado.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

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

Problema

Los paquetes se caen en el par con este mensaje registrado al 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

Para información detallada sobre los índices inválidos del parámetro de seguridad (SPI), refiera a los errores del IPSec %RECVD_PKT_INV_SPI y a la recuperación del SPID inválido. Este documento describe cómo resolver problemas los escenarios en los cuales el error ocurre intermitentemente, que hace duro recoger los datos necesarios para resolver problemas.

Este tipo de problema no es como el troubleshooting normal VPN, donde usted puede obtener los debugs cuando ocurre el problema. Para resolver problemas las aletas intermitentes del túnel causadas por los SPID inválidos, usted debe primero determinar de cómo los dos headends salieron sincronizan. Puesto que es imposible predecir cuando ocurrirá la caída del sistema próxima, los scripts EEM son la solución.

Solución

Puesto que es importante conocer qué sucede antes de que se accione este mensaje de Syslog, continúe ejecutando los debugs condicionales en los routers y enviándolos a un servidor de Syslog de modo que no afecte al tráfico de producción. Si los debugs se habilitan en el script en lugar de otro, se generan después de que se accione el mensaje de Syslog que puede no ser útil. Aquí está una lista de debugs que usted puede ser que quiera para ejecutarse en el remitente de este registro y el receptor:

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

El script EEM se diseña para hacer dos cosas:

  1. Apague los debugs en el receptor cuando se recogen para 18 segundos después de que el primer mensaje de Syslog se genera. El temporizador del retraso pudo necesitar ser modificado, que es dependiente sobre la cantidad de debugs/de registros generados.

  2. Al mismo tiempo inhabilita los debugs, hace que envíe un SNMP trap al par, que entonces inhabilita los debugs en el dispositivo de peer.

Configuración SNMP

Las configuraciones del Simple Network Management Protocol (SNMP) se muestran aquí:

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

Los scripts para el receptor y el remitente se muestran aquí:

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

Registros de secuencia de comandos EEM

Una lista de mensajes de registro de secuencia de comandos EEM se muestra aquí:

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

Verificación

Para verificar el problema se ha resuelto, ingresa el comando show debug.

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


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

Información Relacionada


Document ID: 116005