cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
15135
Views
22
Helpful
6
Replies
Highlighted
Beginner

IPSEC/mGRE overhead calculation

I believed I had properly accounted for the IPSEC/mGRE overhead on my Tunnel interface settings (IP MTU and MSS), but was experience high CPU utilization (IP Input) due to fragmentation and reassembly.

Below are the overhead calculations I used originally;

* mGRE - 28 bytes (24 for GRE plus additional 4 for DMVPN Key)

* IPSEC - 60 (SHA/AES)

* TCP Header - 20

* IP Header - 20

Total - 1372 which would be the MSS number I would use.

Following Best Practic recommendations, I even lowered my MSS number to come up with the following original Tunnel confg;

Tunnel xxxx

ip mtu 1400

ip tcp adjust-mss 1360

I was still experiencing fragmentation / reassembly until I changed to the following;

Tunnel xxxx

ip mtu 1372

ip tpc adjust-mss 1332

What was I missing in my original calculations or did I misunderstand how I would use the resulting number (MTU instead of MSS) from my calculations?

6 REPLIES 6
Highlighted
Advocate

Keith,

The way I work it out/configure my tunnels is:-

Cisco recommends a GRE MTU of 1400, that's cool. A GRE tunnel encapsulation requires 24/28 Bytes - as you have stated ( I always go with 28, includes some fudge). So the MTU that the GRE can send is 1400 - 28 = MTU 1372 - not including GRE encapsulation. Don't forget that the Maximum Segment Size is the largest transmissible amount of data that can be sent un-fragmented. So the IP header requires 20 bytes. The TCP header requires 20 bytes = 40 bytes.

Great - so now we have:-

28 Bytes - GRE

20 Bytes - IP

20 Bytes - TCP

Total of 68 Bytes, 1400 - 68 = 1332 this is the MSS, that clients and upstream devices should be setting there to MSS in the TCP handshake.

What would be helpful in some documentation is that when you set the MTU of the GRE - subtract the overhead of the GRE encapsulation. Then subtract the TCP & IP overhead, what you are left with is what you should set the MSS to.

HTH.

Highlighted
Cisco Employee

Keith,

I know this reply probably comes 8 years too late for you but I figured other people stumbling across this thread can use this.

I wrote a tool that calculates the IPSec overhead for various different scenarios.  Check it out here, you will need a Cisco support contract or be a partner.

https://cway.cisco.com/tools/ipsec-overhead-calc/ipsec-overhead-calc.html

-Jay

Highlighted

Awesome tool.

Would it be possible to get the it to support RTP with different Codecs? Would be amazing to have a tool like this to calculate queues.

Highlighted

Brianpetes,

You can use the following tool made by one of my colleagues to determine the size of the RTP packet and then use as an input to this tool.

https://cway.cisco.com/tools/vccalc/

Hope this helps.

-Jay

Highlighted

Hi

 

I find that the link of the IPSec hearder calculator is not work,

 

Can you help to post it again?

Highlighted
Hall of Fame Expert

Ha, I must have missed this post nine years ago, and as Jay says, in case someone stumbles across it . . .

First, kst allocates L2 and L3 header overhead at 20 bytes each, but one has to also remember, those are the usual minimums.  Either header can be bigger; even much bigger, but again, larger than the minimums is unusual.  However, if you do bump into such, it does throw the overhead calculation off.

Second, even if you've calculated correctly, and no packet headers are larger than you expect, often not all traffic is TCP and not all TCP traffic enables PMTUD.  Such traffic may be fragmented.  (Case in point, a couple of years ago, had a VPN router with high CPU [due to fragmentation], the cause was video security traffic.)

Lastly, for IP TCP adjust-mss to do its "magic", in needs to "see" the TCP session setup hand-shake.  If you have an environment where there's both a VPN and non-VPN path to a destination, traffic might have started on the non-VPN path and have not been subjected to IP TCP adjust-mss.