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;
ip mtu 1400
ip tcp adjust-mss 1360
I was still experiencing fragmentation / reassembly until I changed to the following;
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?
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.
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.
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.
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.
Hope this helps.
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.