10-07-2021 09:17 PM
Can someone help me understand this better., I'm clearly missing something. Why is the default MSS (536) so much smaller than the default MTU (1500)? I would expect them to have a difference of the 40 bytes to account for IP and TCP headers? What am I missing?
TY,
PB_Falcon
Solved! Go to Solution.
10-08-2021 10:29 AM
Any IP host, that originates a packet, if sending to another host on the same locally connected media, "knows" the MTU of that media (and normally doesn't send packets larger than that MTU).
Any IP host, that originates a packet, if sending to another host that's not on a locally connected media, either restricts itself it 576 or, if PMTUD enabled, uses the first hop locally connected media's MTU. If that's too large, if should receive an IGMP message to that effect.
A router transmitting transit packets only concerns itself with a packet's size if it's too large for the its egress interface. If transit packet's size is larger than egress interface's MTU it will either drop or fragment the packet.
Cisco GRE tunnels, themselves, I recall (?) have a very large MTU (as they are virtual) but are also limited to the egress interface's MTU, used by the tunnel. So, I also recall, by default, a tunnel's packet will be fragmented, but as it doesn't (again by default) have DF set, this fragmentation isn't "reported" to the tunnel. There's a great Cisco whitepaper addressing changing defaults and dealing with tunnel packets to avoid fragmentation and/or detect it further downstream.
10-07-2021 09:32 PM - edited 10-07-2021 09:33 PM
Hi,
https://datatracker.ietf.org/doc/html/rfc879
There have been some assumptions made about using other than the default size for datagrams with some unfortunate results. HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS. This is a long established rule. To resolve the ambiguity in the TCP Maximum Segment Size option definition the following rule is established: THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY. The default IP Maximum Datagram Size is 576. The default TCP Maximum Segment Size is 536.
10-07-2021 10:33 PM
That's the part I explained that I was already aware of. How do we get from 576 to 1500?
10-07-2021 11:29 PM - edited 10-07-2021 11:30 PM
this is how to change MSS:
Device(config)#interface GigabitEthernet 0/0/0
Device(config-if)#ip address 1.1.1.0.255.255.255.0
Device(config-if)#ip tcp adjust-mss <Value>
10-07-2021 11:22 PM
Hi,
you can refer below link for understand MSS and MTU behavior. and default MSS value is not as mentioned in RFC always. its depends on vendor optimizations. you can change MSS using CLI commands relevant to device OS or platform.
https://networkdirection.net/articles/network-theory/mtu-and-mss/
rate this and mark as answer if this solved your concern
10-08-2021 12:28 AM
I’m asking a specific question. The default MSS on a Cisco router is 536 Bytes according to Cisco documentation. The default MTU is 1500. Why the huge discrepancy?
I’ve read everything you’re posting, the answer isn’t there.
10-08-2021 12:50 AM
Hello,
one of the (probably few) benefits of getting, and being older, is that you remember more stuff. I remember the sound of an analogue modem, or Tom Brady being a quarterback for Michigan, in the 1990s...
Just kidding: a very long time ago, I worked for IBM, and there was a networking protocol around called X.25. That is where, if I remember it well, the small TCP datagram/window size of 576 originated. So basically it is a remnant of the early Internet days, and more or less obsolete now.
Have a look at topic 6.3 in the document linked below:
10-08-2021 08:43 AM
There is no "default" MTU. MTU is media (and its protocol) dependent.
MSS of 536 was chosen, I believe, because it was expected any media being used (back then) by IP would have a MTU that would not require fragmentation for that size.
Regarding the 40 bytes for IP and TCP headers, that's a minimum. Both headers support optional fields that can make one or both headers, larger.
To take advantage of media MTUs larger than 536, for non-directly connected media, you need to enable PMTUD. (The latter is often overlooked for Cisco routers and/or switches.)
10-08-2021 09:00 AM
Thank you Joseph, that helps get me a little closer to understanding. The background on this question is that I’m studying for my CCNP. In the Boson practice test there’s a question about sending a ping at 1500 Bytes with the DF but set through a GRE tunnel. The answer explains that the default for a Cisco router is 536. I’m starting to think they must be specifically referring to a payload originating from a Cisco router, I’m going to read the question again and I think I’ll just post it here so it can be seen directly because there might be something I’m missing, or the answer itself may be incorrect which has been known to happen.
thanks.
10-08-2021 10:29 AM
Any IP host, that originates a packet, if sending to another host on the same locally connected media, "knows" the MTU of that media (and normally doesn't send packets larger than that MTU).
Any IP host, that originates a packet, if sending to another host that's not on a locally connected media, either restricts itself it 576 or, if PMTUD enabled, uses the first hop locally connected media's MTU. If that's too large, if should receive an IGMP message to that effect.
A router transmitting transit packets only concerns itself with a packet's size if it's too large for the its egress interface. If transit packet's size is larger than egress interface's MTU it will either drop or fragment the packet.
Cisco GRE tunnels, themselves, I recall (?) have a very large MTU (as they are virtual) but are also limited to the egress interface's MTU, used by the tunnel. So, I also recall, by default, a tunnel's packet will be fragmented, but as it doesn't (again by default) have DF set, this fragmentation isn't "reported" to the tunnel. There's a great Cisco whitepaper addressing changing defaults and dealing with tunnel packets to avoid fragmentation and/or detect it further downstream.
10-09-2021 08:51 AM
Thanks Joe. I went back and looked. The question was about minimizing fragmentation and was specific to traffic originating from the router having a default MSS of 536 as you have said( considering the 40 for headers). For anybody trying to follow along, this pertains to traffic originating from the router, not transient traffic. If you're here reading this because you're trying to learn this as I am, you might as well go ahead and lookup PMTUD as well.
Thank you Joe!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide