cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
30569
Views
12
Helpful
18
Replies

Do I need 'crypto ipsec df-bit clear'?

localgareth
Level 1
Level 1

I have a VPN tunnel between an 871 and 877, the tunnel seems to be fine, but checking the tunnel using SDM shows an error.

Checking the tunnel status... Up

Encapsulation :330231

Decapsulation :393226

Send Error :7939

Received Error :0

-----

A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not Fragmet' packets.

1)Contact your ISP/Administrator to resolve this issue. 2)Issue the command 'crypto ipsec df-bit clear' under the VPN interface to avoid packets drop due to fragmentation.

-----

Are the send errors anything to worry about?

Do I need to issue the 'crypto ipsec df-bit clear' on the routers?

Any info would be much appreciated.

Thanks

Gareth

18 Replies 18

<Comment removed>

We use dmvpn to an enormous scale over wired/broadband/wireless internet access for various business lines/uses.  SSL/TLS cannot be fragmented so any application with large payload segments using SSL/TLS will have issues over GRE IPSEC tunnels. Outlined below are the necessary steps for large packets to traverse the VPN without issues.

1) TCP - On the tunnel interface, reduce the MTU and MSS to the Cisco best practice configuration for GRE/IPSEC

interface Tunnel10
 ip mtu 1400
 ip tcp adjust-mss 1360

We have found that some wireless networks use tunneled backhauls which further reduce MTU, so we have reduced both values by -40 bytes to accommodate as follows.

interface Tunnel10
 ip mtu 1360
 ip tcp adjust-mss 1320

 

2) The above configuration does nothing for UDP, because it has no way to adjust mss. Some tftp clients will use very large payload segments. We use a route map on the Ingress interface to clear the DF bit on UDP packets so fragmentation will occur.

interface Vlan10
 ip policy route-map FRAG-UDP-rmap

!

ip access-list extended FRAG-UDP
 permit udp any any

!
route-map FRAG-UDP-rmap permit 10
 match ip address FRAG-UDP
 set ip df 0
!
route-map FRAG-UDP-rmap deny 99

There is no implicit deny at the end of a Cisco route-map, so the explicit deny is necessary to prevent matching all traffic, not completely necessary here, but a best practice.

 

3) ICMP - The only reason ICMP packets should be large is for testing. You can accomplish this with the following lines.

ip access-list extended FRAG-UDP
 permit icmp any any

4) You must configure these elements on both ends of the tunnels.

 

We have used these configurations globally without issues.

Thanks,
Brian

 

 

Hi Brian,

 

Ive had a look at your config and we are suffering the same sorts of problems with large UDP packets over DMVPN.

 

What I did was increase the tunnel MTU to 1500 and this allowed an end to end ping to run at 1500 packet size, whereas when the MTU was set to 1400 on the tunnel, this could not be achieved.

 

Unfortunately we are still seeing issues so would your config allow large UDP packets and how would I identify if the the df bit on the UDP packet was set to 1 in the first place ?

I also have the following command....is that ok ?

 

crypto ipsec fragmentation after-encryption

 

Thanks

 

Dear Brian,

Your posts have been very helpful; I have tried to implement those suggestions, but I am still having a problem when using a GRE tunnel.

Since you seem to have experience with tunnels, could you please check this thread:

https://supportforums.cisco.com/discussion/12485176/problem-exporting-netflow-over-gre-tunnel

and suggest a reason why Netflow export is not working correctly?

I assume the reason is this (fragmentation causing checksum errors):

https://www.plixer.com/blog/general/interesting-cisco-asa-netflow-fragmentation-issue/

In that case, turning on pre-fragmentation for IPSec VPNs worked. But what could we do with simple GRE tunnels?

Nick