DMVPN GRE with IPSEC fragmentation

les_davis · ‎11-30-2011

When configuring our tunnel we get an error message indicating that the MTU is greater than the transport value 1376, fragmentation will occur (see below). We are using transport mode and using the recommended MTU settings of 1400 bytes. Could this be causing excessive fragmentation and affecting latency and user experience?

ro1-91309(config)#interface Tunnel2

service_policy on dynamic interface is not allowed if there is fair-queue configured on main interface

ro1-91309(config-if)# description GRE tunnel interface to Tempe

ro1-91309(config-if)# bandwidth 1500

ro1-91309(config-if)# ip address x.x.x.x.x

ro1-91309(config-if)# ip mtu 1400

%Warning: IP MTU value set 1400 is greater than the current transport value 1376, fragmentation may occur

ro1-91309(config-if)# ip hello-interval eigrp 65100 10

ro1-91309(config-if)# ip hold-time eigrp 65100 40

ro1-91309(config-if)# ip flow ingress

ro1-91309(config-if)# ip flow egress

ro1-91309(config-if)# ip pim sparse-mode

ro1-91309(config-if)# ip nat outside

ro1-91309(config-if)# ip nhrp authentication cisco

ro1-91309(config-if)# ip nhrp map 10.2.0.1 x.x.x.x

ro1-91309(config-if)# ip nhrp map multicast x.x.x.x

ro1-91309(config-if)# ip nhrp network-id 1001

ro1-91309(config-if)# ip nhrp holdtime 600

ro1-91309(config-if)# ip nhrp nhs 10.2.0.1

ro1-91309(config-if)# ip nhrp registration timeout 30

ro1-91309(config-if)# ip virtual-reassembly in

ro1-91309(config-if)# zone-member security TRUST

ro1-91309(config-if)# ip tcp adjust-mss 1360

ro1-91309(config-if)# ip summary-address eigrp 65100 10.8.80.0 255.255.255.0 5

ro1-91309(config-if)# load-interval 30

ro1-91309(config-if)# if-state nhrp

ro1-91309(config-if)# qos pre-classify

ro1-91309(config-if)# tunnel source FastEthernet0/1

ro1-91309(config-if)# tunnel destination x.x.x.x

ro1-91309(config-if)# tunnel key 1001

ro1-91309(config-if)# tunnel protection ipsec profile iGBN

ro1-91309(config-if)# max-reserved-bandwidth 100

service_policy on dynamic interface is not allowed if there is fair-queue configured on main interface

ro1-91309(config-if)# hold-queue 4096 in

ro1-91309(config-if)# hold-queue 4096 out

ro1-91309(config-if)#end

Crypto settings

crypto isakmp policy 1

encr aes

hash md5

group 5

crypto isakmp invalid-spi-recovery

crypto isakmp keepalive 30 12

!

crypto ipsec security-association replay window-size 1024

!

crypto ipsec transform-set iGBN esp-aes esp-md5-hmac

mode transport

!

crypto ipsec profile iGBN

set transform-set iGBN

!

ajay chauhan · ‎11-30-2011

You should be good with this configuration -

Here is the explaination-

When an IP packet has been split into two fragments and encapsulated by GRE. In this case IPsec will see two independent GRE + IP packets. Often in a default configuration one of these packets will be
large enough that it will need to be fragmented after it has been encrypted. The IPsec peer will have to reassemble this packet before decryption. This "double fragmentation" (once before GRE and again after IPsec) on the sending router increases latency and lowers throughput. Also, reassembly is process-switched, so there will be a CPU hit on the receiving router whenever this happens. This situation can be avoided by setting the "ip mtu" on the GRE tunnel interface low enough to take into account the overhead from both GRE and IPsec (by default the GRE tunnel interface "ip mtu" is set to the outgoing real interface MTU - GRE overhead bytes).

les_davis · ‎11-30-2011

I found that explanation earlier. However we have the tunnels MTU set to 1400 bytes and the router is giving us this message during configuration.

%Warning: IP MTU value set 1400 is greater than the current transport value 1376, fragmentation may occur

This concerns me that we don't have the optimum settings. If we are fragmenting the packets that would account for increased latency and poor performance.

ajay chauhan · ‎11-30-2011

Just thinking about transform set diffrent encryption has got diffrent overhead. I can not test it right now but incase if you can try for esp-3des or des.

Thanks

Ajay

les_davis · ‎11-30-2011

We are unable to change the transform set. Production enviornment and we can't make that type of changes. I am currently trying to set up a couple of routers with the same tunnel config and perform some testing as well.

les_davis · ‎12-01-2011

I updated a remote location that was reporting high latency and sluggish performance. They have a 5Mb/s/512kb/s cable circuit. I adjusted the tunnel ip mtu to 1376 as suggested. I also adjusted the physical and tunnel interface MSS to 1336. They are reporting that things have never been better. Maybe it's too early to tell for sure but we are experiencing positive results with the change.

pradeepkumar83 · ‎12-02-2011

This below link will usefull for you....

https://supportforums.cisco.com/thread/150917