It is definitely possible. The invalid SPI indicates that the device received a packet for which is does not have a valid SA. It is normal during a crypto rekey when the traffic was sent on an older or newer SA than the receiving device. It all depends how often it is happening. A couple a day would probably just be normal operation. If they are very often it could be a code bug or packet loss causing loss of crypto sync between devices. I would first ask how often and next ask if they have dead peer detection enabled. Not having dead peer detection can cause this condition to go on for much longer than necessary. Note that Cisco limits the messages to one per minute to avoid DoS attacks. Which brings up another point, are you sure that the traffic causing the messages is sourced from a peer they should actually be talking with? You would get the same message if I sent IPsec encrypted traffic to them and I am not configured as a peer. If it was working and just now started happening it is probably packet loss or a bug. I would also suggest a reboot on the devices to make sure that this is not a low mem condition which also causes these once in a while on our devices. Steven Naslund Chicago IL
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mike Hammett Sent: Tuesday, December 19, 2017 9:03 PM To: NANOG list Subject: IPSec SPI
Is it possible for light packet loss (0.1% - 0.3%) to cause these errors:
Dec 18 00:12:07.098: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=Z.Z.Z.Z, prot=50, spi=0x9E6D41B7(2657960375), srcaddr=B.B.B.B, input interface=GigabitEthernet0/2 Dec 18 00:20:47.848: %>CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x430A8C9C(1124764828), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 Dec 18 00:28:39.781: %CRYPTO-4->RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x8716502A(2266386474), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2
I look it up and none of the pages I find say anything about connection quality and everything about configuration and timing.
My client is insisting that it can't possibly be their problem and that it's entirely because of the packet loss.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com