Seguridad y VPN : Negociación IPSec/Protocolos IKE

Errores del IPSec %RECVD_PKT_INV_SPI e información de la función de recuperación del SPID inválido

16 Agosto 2013 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (20 Marzo 2013) | Comentarios


Contenido


Introducción

Este documento describe el problema del IPSec cuando las asociaciones de seguridad (SA) se convierten fuera de sincronizan entre los dispositivos de peer.

Nota: Contribuido por Atri Basu, Anu M Chacko, y Wen Zhang, ingenieros de Cisco TAC.

Prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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

Uno de la mayoría de los problemas del IPSec comunes es que los 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 su par no conoce alrededor. Estos paquetes se caen en el par con este mensaje registrado al Syslog:

Sep  2 13:27:57.707: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet
   has invalid spi for destaddr=20.1.1.2, prot=50, spi=0xB761863E(3076621886), 
   srcaddr=10.1.1.1

Nota: Con el NAT-T, los mensajes RECVD_PKT_INV_SPI no fueron señalados correctamente hasta que el Id. de bug Cisco CSCsq59183 (clientes registrados solamente) fuera reparado. (El IPSec no señala los mensajes RECVD_PKT_INV_SPI con el NAT-T)

Nota: En la plataforma del Routers de los servicios de la agregación de Cisco (ASR), los mensajes %CRYPTO-4-RECVD_PKT_INV_SPI no fueron implementados hasta la versión 2.3.2 (12.2(33)XNC2) del ® XE del Cisco IOS. También observe con la plataforma ASR, este descenso determinado es ambos registradoes bajo el receptor de papel global del contador de caídas del qfp como en el contador de caídas de la característica del IPSec tal y como se muestra en de estos ejemplos:

Router# show platform hardware qfp active statistics drop | inc Ipsec                                        
  IpsecDenyDrop                              0               0                                   
  IpsecIkeIndicate                           0               0                    
  IpsecInput                                 0               0     <======
  IpsecInvalidSa                             0               0
  IpsecOutput                                0               0
  IpsecTailDrop                              0               0
  IpsecTedIndicate                           0               0               
Router# show platform hardware qfp active feature ipsec datapath drops all | in SPI        
        4  IN_US_V4_PKT_SA_NOT_FOUND_SPI                           64574     <======
        7  IN_TRANS_V4_IPSEC_PKT_NOT_FOUND_SPI                         0
       12  IN_US_V6_PKT_SA_NOT_FOUND_SPI                               0

Primero, es importante observar que este mensaje particular es tarifa limitada en el Cisco IOS hasta una tasa de 1 por el minuto por los motivos de seguridad obvios. Si este mensaje para un flujo determinado (src/dst/spi) aparece solamente una vez en el registro, después podría apenas ser una condición transitoria al mismo tiempo que el IPSec reintroduce donde un par puede comenzar a utilizar el nuevo SA mientras que el dispositivo de peer no es muy listo para utilizar el mismo SA. Esto no es normalmente un problema pues es solamente temporal y afectaría solamente a algunos paquetes. Sin embargo, ha habido los bug donde esto podría ser un problema. Por los ejemplos, vea por favor el bug Cisco ID CSCsl68327leavingcisco.com (clientes registrados solamente) (la pérdida del paquete durante reintroduce) o CSCtr14840 (clientes registrados solamente) (ASR: las caídas de paquetes durante la fase 2 reintroducen bajo ciertas condiciones).

Por otra parte, hay un problema si más de un caso de los mismos mensajes se observa para señalar mismo SPI para el mismo flujo, tal como estos mensajes:

Sep  2 13:36:47.287: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has 
   invalid spi for destaddr=20.1.1.2, prot=50, spi=0x1DB73BBB(498547643), 
   srcaddr=10.1.1.1
Sep  2 13:37:48.039: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has 
   invalid spi for destaddr=20.1.1.2, prot=50, spi=0x1DB73BBB(498547643), 
   srcaddr=10.1.1.1

Esto es una indicación que el tráfico blackholed, y puede no recuperarse hasta que los SA expiren en el dispositivo remitente o hasta el Dead Peer Detection (DPD) golpea con el pie adentro.

Recuperación del SPID inválido

En este momento, Cisco recomienda que usted habilita la función de recuperación del SPID inválido. Por ejemplo, ingrese el comando crypto de la inválido-SPI-recuperación del isakmp. Hay algunas cosas que usted necesita saber sobre lo que hace y no hace este comando:

  • Primero, la recuperación del SPID inválido sirve solamente como mecanismo de recuperación cuando los SA están fuera de sincronizan. Ayuda a recuperarse de esta condición, pero no dirige la causa raíz fuera de porqué los SA están sincronizan en el primer lugar. Para entender mejor la causa raíz, usted necesita permitir al debug del isakmp y del IPSec en ambos puntos extremos del túnel. Si ocurre el problema a menudo, después obtenga los debugs e intente dirigir la causa raíz y no apenas enmascarar el problema.

  • Hay un concepto erróneo común de lo que lo hace el comando crypto de la inválido-SPI-recuperación del isakmp realmente. Incluso sin este comando, el Cisco IOS realiza ya una clase de funciones de la recuperación del SPID inválido cuando envía una CANCELACIÓN notifica para el SA recibido al par de envío si tiene ya IKE SA con ese par. Una vez más esto ocurre sin importar si el comando crypto de la inválido-SPI-recuperación del isakmp está dado vuelta encendido o no.

  • Con el comando crypto de la inválido-SPI-recuperación del isakmp, intenta dirigir la condición donde un router recibe el tráfico IPSec con el SPID inválido y no tiene IKE SA con ese par. En ese caso, intentará establecer a una nueva sesión IKE con el par y entonces enviar una CANCELACIÓN notifique sobre IKE creado recientemente SA. Sin embargo, este comando no trabaja bajo todas las configuraciones de criptografía. Las únicas configuraciones para las cuales este comando trabajará son las correspondencias de criptografía estática donde definen al par y derivan explícitamente a los peeres estáticos de las correspondencias de criptografía ejemplificadas, tales como VTI. Aquí está un resumen de las configuraciones de criptografía de uso general y si la recuperación del SPID inválido trabaja con esa configuración o no:

Config Crypto ¿Inválido-SPI-recuperación?
Correspondencia de criptografía estática
Correspondencia cifrada dinámica No
P2P GRE con el TP
mGRE TP que utiliza con el mapeo NHRP estático
mGRE TP que utiliza con el mapeo NHRP dinámico No
sVTI
Cliente EzVPN N/A

Mensajes de error intermitentes del SPID inválido del Troubleshooting

Muchas veces el mensaje de error del SPID inválido ocurre intermitentemente. Esto hace difícil resolver problemas mientras que llega a ser muy duro recoger los debugs relevantes. Los scripts EEM pueden ser muy útiles en este caso.

Para más detalles, refiera a los scripts EEM usados para resolver problemas las aletas del túnel causadas por los índices inválidos del parámetro de seguridad.

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: 115801