cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
18917
Views
0
Helpful
7
Replies

%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed

melaniemaillet
Level 1
Level 1

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
7 Replies 7

wzhang
Cisco Employee
Cisco Employee

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

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

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

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

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

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

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: