10-12-2010 08:15 AM - edited 03-04-2019 10:05 AM
Hi,
I am just wondering if the fact to have the error message below several times could make my bgp session flapping as the bgp session is as per my tunnel :
UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=311, sequence number=0
Thanks in advance for your time
Mel
10-12-2010 10:26 AM
Hi,
If you are running BGP over a GRE/IPSec or VTI tunnel, then this error could potentially cause BGP session flaps as it is a indication of packet drop due to ipsec anti-replay check failure. Also note that you may have actually more drops than the number of messages logged since this particular message is rate-limited to 1 per minute. Check the "show crypto ipsec sa detail" output for a more accurate drop count. That said, what's concerning with this error is that the ESP sequence number is 0, this is almost always a bug as it should never be 0 even if the 32 bit sequence counter has wrapped. What's the remote device, and if it's a cisco, what version of code?
Thanks,
Wen
10-13-2010 01:17 AM
Hi Wen,
Thanks for your prompt feedback
The device is a Cisco 1812 with the IOS version c181x-advipservicesk9-mz.124-15.T13.bin
Reagrding the show crypto ipsec sa, I forwarded you the output of that command. I requested to get the show crypto ipsec sa det, but still haven 't received the capture.
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr X.X.X.X
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer Y.Y.Y.Y port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 9010618, #pkts encrypt: 9010618, #pkts digest: 9010618
#pkts decaps: 8843226, #pkts decrypt: 8843226, #pkts verify: 8843226
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 86
local crypto endpt.: X.X.X.X, remote crypto endpt.: Y.Y.Y.Y
path mtu 1492, ip mtu 1492, ip mtu idb Dialer1
current outbound spi: 0x7CDB0C2D(2094730285)
inbound esp sas:
spi: 0xD13C6DC0(3510398400)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 763, flow_id: Motorola SEC 2.0:763, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4442267/335)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x7CDB0C2D(2094730285)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 764, flow_id: Motorola SEC 2.0:764, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4442153/335)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
Thanks
Mel
10-13-2010 07:34 AM
Hi,
So based on this output, we can see you got 86 recv errors. The "detailed" output will tell you how many of these are due to anti-replay check failure. Is the version information you included the router itself or the peer device? Since the ESP sequence number of 0 is sent from the peer, that's the device we are interested in. From what you see in the logs, how often do you get the REPLAY error?
Thanks,
Wen
10-13-2010 07:49 AM
Hi
Below the details of the crypto IPsec
router#show crypto ipsec sa detail
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr X.X.X.X
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer Y.Y.Y.Y port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 9090820, #pkts encrypt: 9090820, #pkts digest: 9090820
#pkts decaps: 8918222, #pkts decrypt: 8918222, #pkts verify: 8918222
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 86
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: X.X.X.X, remote crypto endpt.: Y.Y.Y.Y
path mtu 1492, ip mtu 1492, ip mtu idb Dialer1
current outbound spi: 0x9D35974B(2637535051)
inbound esp sas:
spi: 0xCD49720E(3444142606)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 797, flow_id: Motorola SEC 2.0:797, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4460272/98)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
spi: 0xDCBC906C(3703345260)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 799, flow_id: Motorola SEC 2.0:799, crypto map: Tunnel0-head-0
--More-- sa timing: remaining key lifetime (k/sec): (4401485/563)
--More-- IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x9B797C0(163026880)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 798, flow_id: Motorola SEC 2.0:798, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4460239/98)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
spi: 0x9D35974B(2637535051)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 800, flow_id: Motorola SEC 2.0:800, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4401461/563)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
router#
In the Version I am only including the cisco router as the other and is belonging to a NNI, I will still ask them to have more info.
The amount of replay error can vary:
Oct 3 21:08:13.004 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=251, sequence number=0
Oct 3 23:04:29.736 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=281, sequence number=0
Oct 4 13:32:39.246 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=505, sequence number=0
Oct 5 11:45:50.820 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=849, sequence number=0
Oct 5 18:28:57.099 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=953, sequence number=0
Oct 5 20:25:11.785 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=983, sequence number=0
Oct 5 22:21:28.229 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=13, sequence number=0
Oct 6 00:17:44.189 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=43, sequence number=0
Oct 6 10:53:21.286 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=207, sequence number=0
Oct 6 23:25:14.466 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=401, sequence number=0
Oct 8 13:00:54.110 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=983, sequence number=0
Oct 8 14:57:09.866 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=13, sequence number=0
Oct 9 01:32:46.684 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=177, sequence number=0
-------------> BGP dropped
Oct 9 03:29:03.947 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=207, sequence number=0
Oct 9 12:08:24.882 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=341, sequence number=0
Oct 9 14:04:43.084 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=371, sequence number=0
Oct 10 00:40:17.419 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=535, sequence number=0
Oct 10 13:12:10.583 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=729, sequence number=0
Oct 12 00:51:33.488 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=281, sequence number=0
----->BGP dropped
Oct 12 02:48:00.398 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=311, sequence number=0
Oct 12 13:23:27.185 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=475, sequence number=0
Oct 12 15:19:43.551 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=505, sequence number=0
Oct 12 23:59:11.748 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=639, sequence number=0
Oct 13 01:55:20.732 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=669, sequence number=0
Oct 13 12:30:56.843 UTC: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
connection id=833, sequence number=0
Thanks
Mel
10-13-2010 08:00 AM
Hi, Mel:
So all the receive errors were indeed caused by replay check failures as shown in the sa detail output. The logs also show that all the packets dropped had an ESP seq# of 0. This is likely a bug on the remote peer device as the sequence number should never be 0. Hope this helps.
Thanks,
Wen
10-13-2010 08:08 AM
Just a last question, does that mean that normaly I should receive a ESP sequence numbers incrementing sequentially?
Your feedbacks have been very helpfull, Thanks
10-13-2010 08:25 AM
Hi, Mel:
Yes. Per RFC2406:
2.2 Sequence Number
This unsigned 32-bit field contains a monotonically increasing
counter value (sequence number). It is mandatory and is always
present even if the receiver does not elect to enable the anti-replay
service for a specific SA.
In the same section, you'll also find the requirement about the sequence number should always start with 1 and not 0.
Thanks,
Wen
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide