pre-frag failures and MTU issues

[Sharkey13]

Hello.  Last week we upgraded our ASA 5520 from 7.2.4 to 8.2.3.  All is well with the upgrade, except today we find we have one L2L VPN that cannot send data to us (many others are working just fine).  The tunnel actually builds OK, but no data can be sent to us - sending host receives time out message when they try to send us data.

Upon review, I found this output (public IPs have been changed) from SH IPSEC SA:

Crypto map tag: IPSECVPN, seq num: 30, local addr: 205.1.1.1

      access-list partner-VPN extended permit ip host 192.168.35.126 host 10.137.152.230
      local ident (addr/mask/prot/port): (192.168.35.126/255.255.255.255/0/0)
      remote ident (addr/mask/prot/port): (10.137.152.230/255.255.255.255/0/0)
      current_peer: 65.3.2.1

      #pkts encaps: 112, #pkts encrypt: 79, #pkts digest: 79
      #pkts decaps: 59, #pkts decrypt: 59, #pkts verify: 59
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 112, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 33, #fragments created: 0
      #PMTUs sent: 33, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 205.1.1.1, remote crypto endpt.: 65.3.2.1

      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: 2E3DE6E0
      current inbound spi : E902A62E

    inbound esp sas:
      spi: 0xE902A62E (3909264942)
         transform: esp-3des esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 1421312, crypto-map: IPSECVPN
         sa timing: remaining key lifetime (kB/sec): (4374000/3446)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0x2E3DE6E0 (775808736)
         transform: esp-3des esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 1421312, crypto-map: IPSECVPN
         sa timing: remaining key lifetime (kB/sec): (4374000/3446)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

I have found limited information on this, but what information I have found suggests there is an MTU negotiation issue or a fragment\don't fragment issue.  Or, could it be something else?

Experts - your thoughts and insights would be appreciated.

Thanks, Patrick

[manish arora]

Hi Sharkey,

Since the counters are incrementing in encapsulation & decaps but also the counter in pre-frag & PMTU sent is increasing, that means the far end is trying to sent you data with donot fragment bit set to on , even when the tunnel end is sending it notification to change the MTU, the remote device isn't responding to that notification , have the MTU size set 1380 or lower on the remote server. you can see the size of data packets using extended ping commands with higher byte size with df bit set.

manish

[Sharkey13]

Manish - I thought I would update you on this issue.  What we found resolved this was to change the df-bit from copy to clear (crypto ipsec df-bit clear-df ), although copy was the default behavior both before and after the upgrade of the ASA from 7.2(4) to 8.2.  We clearly identified that the remote host was not able to respond to MTU requests, but it is still a mystery why the remote host could negotiate this before the ASA upgrade but not after.  Cisco was not able to provide any insight on this either.

Regardless, thanks for providing insight on this.

Patrick

[manish arora]

Thanks for the Update ....  but if Cisco Doesn't have answer than who would

Thanks again

Manish