Please let me know if I am right:
I am using a GRE-IPSEC tunnel configuration + EIGRP routing protocol and I would like to confirm if I am right with the following:
Due to I am configuring the IP MTU = 1400 in the Tunnel interface, I am avoiding additional fragmentation after GRE encapsulation because there is enough room for IPSEC encapsulation (no matter which mode I am using - I am considering the worst case Tunnel Mode). However, I would like to know what happens if I ALSO include in the Tunnel configuration the command ip tcp adjust-mss 1360 which is clear operates in layer 4 during the 3 way handshaking process to establish the TCP connection/session between opposite hosts (in this case the interaction is with the respective end routers). By adding this MSS command, I understand that I could also eliminate the initial fragmentation of the 1500 bytes LAN packets (before GRE encap) because the hosts are notified to send 1360 bytes packets to the Router and based on the previous, I would be able to transfer packets without "theorical" fragmentation between both ends.
One more question, how can affect if I include this additional command (TCP ADJUST-MSS) the performance (process + memory) of a router 3845 or 7200 without producing for example a entire crash of the device???. I understand that this TCP MSS negotiation is router process intensive but is less than IPSEC encryption/decryption.
thanks in advance for your comments.
Is the IP MTU parameter the responsible for limiting the MSS size during the 3-way tcp handshake to 1360 bytes ((IP MTU configured in the Tunnel Interface = 1400) - (40 bytes headers)) as you see in the next image? How the PMTUD is also participating in this process?
No, the IP MTU parameter configured on a router is not responsible for the initial MSS size as advertised by end hosts. The end hosts initially derive their starting MSS value by looking at their own interface MTU (not the router's MTU - they do not know it at all) and decreasing it by at least 40 bytes. This starting MSS may subsequently be lowered thanks to ip tcp adjust-mss on a router. During the TCP session, the real MSS used to talk to the other party may dynamically change according to the current MTU of the end host's interface, or it may be influenced by PMTUD during the session, but it may never exceed the negotiated MSS.
Quoting from RFC 1122, Section 188.8.131.52 stipulates:
The maximum size of a segment that TCP really sends, the "effective send MSS," MUST be the smaller of the send MSS (which reflects the available reassembly buffer size at the remote host) and the largest size permitted by the IP layer: Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize where: * SendMSS is the MSS value received from the remote host, or the default 536 if no MSS option is received. * MMS_S is the maximum size for a transport-layer message that TCP may send. * TCPhdrsize is the size of the TCP header; this is normally 20, but may be larger if TCP options are to be sent. * IPoptionsize is the size of any IP options that TCP will pass to the IP layer with the current message.
The PMTUD - if run by the end host engaged in the TCP communication - may influence the MMS_S element of the equation. Please do not confuse this Effective Send MSS with the value of the MSS option indicated in the TCP header during the 3-way handshake. That MSS is here represented as SendMSS and it may never be exceeded.
Based on my test below, I dont see any significant difference between using IP MTU or IP TCP Adjust-MSS if the IP MTU is already responsible for limiting TCP traffic through the GRE Tunnel connection.
The difference is rather strong. As I just explained, the IP MTU configured on a router is not directly influencing the MSS choice at the end host simply because the end host has no idea about the configuration of the router. In fact, the only way to find out is to use the PMTUD that has to be run by the end host again - not by the router. If the PMTUD is not performed, end hosts may end up negotiating much larger MSS than what would be necessary to prevent fragmentation, and the resulting IP packets sent by end hosts will have to be fragmented by the router.
The ip tcp adjust-mss is therefore indispensable.
Peter, if I am not wrong, the initial MSS value = 1260 sent by my PC depends on the Operating System and Application based on your orientation?
Yes, that is correct. What do you mean by "orientation" here?