MTU setting on IPSEC Tunnel

[Bernard Magny]

I just finish setting a gre tunnel with IPSEC and 3DES encryption. When I used the default settings, configured by the SDM, it set the tunnel MTU to 1420.

With that default setting I was able to bring up the tunnel, but simple tcp services would not work, like viewing a HTTP server of using FTP. So I changed it to 1500. Now everything seems to work, but I'm worried that it's not as efficient as it could be. I had a message from the IOS when I changed it to 1500 saying : %Warning: MTU set 1500 is greater than default 1476, fragments will happen

Can anyone help me with that? I want the fastest connection possible, it's a critical trading software that will use the VPN. Should I leave it at 1500? Or should I try to find an other one where fragments will not happen. Also, what exactly do fragments cause by? The packet is too big to fit with the new encapsulated header?

Thanks

[drolemc]

You could have a look at the document 'Pre-fragmentation For Ipsec VPNs' for an insight into the MTU settings with IPSec. The doc is located at http://www.cisco.com/en/US/products/sw/iosswrel/ps1833/products_feature_guide09186a008009c92c.html

[Richard Burts]

To answer your question about what causes fragments: Consider what happens when you run IPSec with GRE. The end station sends a data packet, the GRE adds additional header information (as it encapsulates the original data packet into the GRE packet) and IPSec adds additional header information. So if the end station sends a large packet (say for example 1500 which is the max size for Ethernet) and you add the header information for GRE and the header information for IPSec, there is now a packet much larger than 1500 and it must be fragmented by routers along the path. Also consider that some applications send the TCP packet with the Do Not Fragment bit set so that the router can not fragment the packet but the packet is too large to go accross the link. So the application does not work.

I am very surprised that you say that there were problems when the tunnel MTU was set to 1420 but it worked better when you set the MTU to 1500. This is the opposite of what I would expect (and of what I have experienced in setting up IPSec with GRE in various networks).

Your network will perform much better if the end stations will use a packet size that does not require fragmentation when the packet goes through the network.

HTH

Rick

[Bernard Magny]

I set the MTU of the Tunnel inteface to 1500 with the command:

interface Tunnel 0

ip mtu 1500

It's the only place where I set the MTU, I'm not sure where else I should set it.

It works like this, but as you said it's getting fragmented.

I would like to set the MTU so the 3DES IPSEC GRE Tunnel works with all application even the ones that requires the Do Not Fragment bit. What is the largest MTU I can set up so both the GRE and the IPSEC infomation still fits?

Thanks

[rlcarr]

You can see how many packets the router is Fragmenting by using the SHO IP TRAFFIC command.

The best solution is to have the router adjust the TCP for the Maximum Send Size.

For Example

1500 Standard MTU

- 20 IP Header

- 24 GRE Encaps.

- 52 IPSec Encap.

- 8 PPPoE (this one is optional based on your setup)

- 20 TCP Header

_____

= 1376 MSS

You should be able to comfortably get by setting your MSS to 1376 on your interface.

~ron

[rodolphej]

I am using the 3 following commands on the interface where I got the crypto map.

interface ...

ip mtu 1400

ip tcp adjust-mss 1300

crypto ipsec df-bit clear

[Richard Burts]

The 3 commands that you use reflect 3 different ways to try to control fragmentation.

The first one ip mtu 1400 will logically put the layer 3 mtu (not necessarily the physical MTU) at 1400. In my opinion this is the least effective of the 3 approaches.

The crypto ipsec df-bit clear will clear the do not frament bit of TCP packets. This will prevent the problem of packet loss due to packets needing fragmentation but the do not fragment bit being set. There are two reasons why this is not my favored solution. First it clears the do not fragment bit of every TCP packet and if there were some real and valid reason why the application set the bit, the router has just undone it. Second it puts the overhead of fragmenting and reassembling the packet on the routers in the network and I would rather put that load on the end stations rather than on the router.

The ip tcp adjust-mss is my favorite solution. It will cause the router to intervene in the TCP packets when the session is being negotiated and set the max segment size to the value that you specify. This means that you can set a size that will not require fragmentation by the router, it will not undo something that the application has done, and it puts the overhead of managing the packet size on the end station rather than the router.

Either the df-bit clear or the adjust-mss can provide an effective solution. I prefer the adjust-mss but you can use whichever you prefer, or as this post points out you can combine solutions.

HTH

Rick

[ralphazzi1]

hello bernard,

i am working with IP cameras where the default MTU packet size is 1450 bytes ; we already have the script to change the size to any other value .

because we have an IPSEC network deployment and in order to configure multicast streaming we are using GRE tunnel . 

i have set up the camera MTU size to 1280 bytes and we are still having packet fragmentation .

do you have any experience with IP camera and can you share with me what could be the exact MTU size that need to be used ?

ralph