cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
41838
Views
40
Helpful
4
Replies

crypto isakmp invalid-spi-recovery command is not worked fine in the DMVPN Case

Hello,

I have done configuration for Hub/Spokes in th DMVPN Case and It's worked fine. But after reload Hub and I saw some error output below although I've added crypto isakmp invalid-spi-recovery command in the Hub & spokes  :

*Oct  7 03:10:03.175: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=150.1.1.1, prot=50, spi=0x72662541(1919296833), srcaddr=150.3.1.3

*Oct  7 03:10:03.175: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=150.1.1.1, prot=50, spi=0x72662541(1919296833), srcaddr=150.2.1.2

Note: spoke1's IP address: 150.2.1.2/spoke2's IP address:150.3.1.3/Hub's IP address:150.1.1.1

My temp solution for this issue, I must clear SPI by manually and It worked fine again.

Anybody has the same issue, please let me know

Regards,

Tran

2 Accepted Solutions

Accepted Solutions

wzhang
Cisco Employee
Cisco Employee

Hi,

There is a common misconception of what the command crypto isakmp invalid-spi-recovery actually does. Even without this command, IOS already performs a kind of invalid SPI recovery functionality by sending a DELETE notify for the SA received to the sending peer if it already has an IKE SA with that peer. Again, this occurs regardless of whether the command crypto isakmp invalid-spi-recovery is turned on or not.

With the crypto isakmp invalid-spi-recovery command, it tries to address the condition where a router is receiving IPSec traffic with invalid SPI and

it does not have an IKE SA with that peer. In that case, it will try to establish a new IKE session with the peer and then send a DELETE notify over the newly created IKE SA. However, this command does not work under all crypto configurations. The only configurations that this command will work are, static crypto maps where the peer is explicitly defined, and static peers derived from instantiated crypto maps, eg., sVTI. Here is a summary of commonly used crypto configurations and whether invalid spi recovery works with that configuration or not:

Crypto configInvalid-spi-recovery?
Static crypto mapYES
Dynamic crypto mapNO
P2P GRE with TPYES
mGRE TP using w/ static NHRP mappingYES
mGRE TP using w/ dynamic NHRP mappingNO
sVTIYES
EzVPN clientN/A

To help with your scenario, you can enable DPD (crypto isakmp keepalive) on the spoke to help with the tunnel recovery.

Thanks,

Wen

View solution in original post

Hi,

Could you elaborate on why enabling DPD on the spokes wouldn't help in your case? This is the sequence of events that are supposed to take place with DPD enabled while the hub router reloads.

1. Hub router reloads and comes back up with no IKE and IPSec SA's

2. Spoke routers continue to send traffic to the hub with the previously established SA's, and hub drops them with the PKT_INV_SPI error

3. With the on-demand DPD, spoke will initiate DPD since it's not getting any return traffic from the hub

4. DPD fails, and spoke will tear down both the IKE and IPSec tunnels

5. Spoke will trigger a new ipsec tunnel, and this should help it recover from the hub reload failure

You can verify these steps with "debug crypto isakmp" on the spoke.

Thanks,

Wen

View solution in original post

4 Replies 4

VitaliyVS
Level 1
Level 1

I've resolved this issue by changing IOS to 24-15.T13 (Cisco 871, 2811). Aslo I use "crypto isakmp keepalive 120 10 periodic" command. But I haven't found solution for Cisco 881 yet (15.1.2T1 doesn't suit).

wzhang
Cisco Employee
Cisco Employee

Hi,

There is a common misconception of what the command crypto isakmp invalid-spi-recovery actually does. Even without this command, IOS already performs a kind of invalid SPI recovery functionality by sending a DELETE notify for the SA received to the sending peer if it already has an IKE SA with that peer. Again, this occurs regardless of whether the command crypto isakmp invalid-spi-recovery is turned on or not.

With the crypto isakmp invalid-spi-recovery command, it tries to address the condition where a router is receiving IPSec traffic with invalid SPI and

it does not have an IKE SA with that peer. In that case, it will try to establish a new IKE session with the peer and then send a DELETE notify over the newly created IKE SA. However, this command does not work under all crypto configurations. The only configurations that this command will work are, static crypto maps where the peer is explicitly defined, and static peers derived from instantiated crypto maps, eg., sVTI. Here is a summary of commonly used crypto configurations and whether invalid spi recovery works with that configuration or not:

Crypto configInvalid-spi-recovery?
Static crypto mapYES
Dynamic crypto mapNO
P2P GRE with TPYES
mGRE TP using w/ static NHRP mappingYES
mGRE TP using w/ dynamic NHRP mappingNO
sVTIYES
EzVPN clientN/A

To help with your scenario, you can enable DPD (crypto isakmp keepalive) on the spoke to help with the tunnel recovery.

Thanks,

Wen

Hi Wzhang,

Thank you for responding my case but "crypto isakmp keepalive command" can not help in this case. I looking for How to know processing recovery look like output debug? anybody know this?

Regards,

Tran

Hi,

Could you elaborate on why enabling DPD on the spokes wouldn't help in your case? This is the sequence of events that are supposed to take place with DPD enabled while the hub router reloads.

1. Hub router reloads and comes back up with no IKE and IPSec SA's

2. Spoke routers continue to send traffic to the hub with the previously established SA's, and hub drops them with the PKT_INV_SPI error

3. With the on-demand DPD, spoke will initiate DPD since it's not getting any return traffic from the hub

4. DPD fails, and spoke will tear down both the IKE and IPSec tunnels

5. Spoke will trigger a new ipsec tunnel, and this should help it recover from the hub reload failure

You can verify these steps with "debug crypto isakmp" on the spoke.

Thanks,

Wen