Troubleshoot › Error Decoder › %CRYPTO-4-RECVD_PKT_INV_SPI

What does %CRYPTO-4-RECVD_PKT_INV_SPI mean?

IPsec VPN received a packet it cannot place

%CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=203.0.113.5, prot=50, spi=0x3F2A1B9C, srcaddr=198.51.100.9

Platform: Cisco IOS / IOS XE routers. ASA and other vendors word this differently; the stale-session logic is the same.

What it means

A VPN tunnel received an encrypted packet stamped with a security ID (SPI) that this router no longer knows. Usually it means the two ends of the tunnel disagree about the current session: one side restarted the tunnel and built a fresh one, while the other side is still sending on the old one. The packets get dropped, and users see a tunnel that looks 'up' but passes no traffic — often right after a brief outage.

Likely causes, in order

• One peer rebooted or its tunnel bounced, and the other peer never noticed — its copy of the session is stale.
• Dead Peer Detection is off or mismatched, so neither side cleans up dead sessions.
• The tunnel's lifetimes differ wildly between the two ends, so one side expires sessions the other still trusts.

Check, in order

1. Copyshow crypto isakmp saWhether the management session to that peer is alive and current.
2. Copyshow crypto ipsec sa | include spiCompare the SPIs this side expects with the one named in the log message. A mismatch is the smoking gun.
3. Copyshow logging | include CRYPTOHow often it happens — every few minutes means a standing mismatch, not a one-off restart.

The fix

• Clear the stale sessions for that peer (clear crypto sa peer <ip>) during a safe moment and let both sides rebuild together — traffic usually flows immediately.
• Turn on Dead Peer Detection on both ends with matching settings so dead sessions get cleaned up automatically.
• Align the tunnel lifetimes on both peers.

Sources

• Cisco: Verify IPsec %RECVD_PKT_INV_SPI Errors and Invalid SPI Recovery

More error messages