Good to hear you found it!
In the IOS Iām using, on GNS3 :
* ip tcp adjust-mss works on (config-if)#, but not on (config)#.
* However, ip tcp mss does work on (config)#.
An error in the lesson, or a limitation im my IOS ?
Hello Maodo.
If Iām not mistaken, the lesson indicates that the ip tcp adjust-mss command is implemented at the interface and not in the global configuration mode. See the below snapshots from the lesson:
Also, it indicates that the ip tcp mss does work in the global config mode:
So your experience matches up with the lesson.
I hope this has been helpful!
Laz
1 Like
Hello Laz/Rene,
I have a question and I am going to use the below topology.
Ques: Does MTU get checked on the inbound interface or outbound interface or inbound and outbound interface both?
In this topology, PC-1 is sending a frame of 9000 Bytes to PC-2. MTU is configured according to the picture. Since MTU is 9216 on the inbound interface of ROUTER-1, the frame should be passed through this interface. What will Router-1 do before it sends the same frame out to the Router-2 through its outbound interface?
Thank you
Best regards,
Azm
Hello AZM
The MTU is checked on both inbound and outbound. So in your scenario, if the MTU on the outbound interface of Router 1 is 1500, then the frame of 9000 bytes that was sent and was successfully egressed through the inbound interface, will be fragmented. (unless the DF bit is set to 1 where it will be dropped).
I hope this has been helpful!
Laz
Hello Laz,
Layer 2 switch port and layer 3 router port check the MTU the same way. Correct?
Azm
Hello AZM
If you are referring to the interface MTU then yes.
Laz
1 Like
Wouldnt this all be fixed with Path MTU discovery?
Hello Carlos
Yes, Path MTU discovery would solve these problems, but it cannot always be implemented. PMTUD depends on ICMP packets. Many network security devices block all ICMP messages for security reasons including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This is called a black hole connection.
In these cases, MTU issues must be troubleshot and solved āmanuallyā.
I hope this has been helpful!
Laz
1 Like
Hi Laz/Rene ,
I have doubt here and i searching for answers , as follows
1.Does Hosts will fragment the packets before sending to gateway routers ?
2.How does the reassembly of fragmented packets takes place and who does this exactly (Router/Host)?
Regards,
Sameer
Hello Sameer.
The quick answer is yes. Fragmentation will occur during encapsulation. If a PC is preparing an email to send, it will take the transport segment and encapsulate it into an IP packet. An IP packet can theoretically be up to 65535 bytes long. So during encapsulation from the Network to the Data Link layer on the PC, if an IP packet is larger than the allowable 1500 bytes (or whatever the interface MTU has been set to), then it will be fragmented into several parts and sent in multiple frames. Now the IPv4 header has some fields called Flags and Fragment Offset.
These two fields are used in order to identify fragmented packets and put them back together correctly. The Flags contain three bits:
- bit 0: Reserved; must be zero
- bit 1: Donāt Fragment (DF)
- bit 2: More Fragments (MF)
The first is not currently used. The second is used to indicate during encapsulation that this packet should not be fragmented. The third is the one used for reassembly, which is 1 if there are additional fragments of this IP packet coming in additional frames or if this is the last one. The Fragment offset is used to specify the offset of a particular fragment relative to the beginning of the original unfragmented packet. This way, the reassembly can take place correctly.
Reassembly is performed during the deencapsulation processes when the multiple frames reach the destination. The frames are deencapsulated and the IP headers are examined. Because the MF bit will be set to 1, the receiver keeps the current IP packet in memory and receives the next one and the next until the MF=0. Once all the fragments are collected, the Fragment offset is used to reassemble the packet correctly before deencapsulation is continued upwards towards the Transport and Application Layers.
I hope this has been helpful!
Laz
1 Like
Hi,
I have set āip tcp adjust-mss 1430ā on a tunnel interface but for some reason the negotiation keeps setting 1460 *mss. resulting in drops has soon as mtu 1500 is reached . MAPI sets the df flag.
Why is it not intercepting the negotiation? what can i do?
thanks
Hello Steven
I suggest you use wireshark to take a look at the value of the MSS filed in both the SYN and the SYN ACK portions of the handshake. Take a look at this thread from the Cisco Support Community, check out the value of the MSS field in the SYN ACK and let us know your progress.
I hope this has been helpful!
Laz
Hi Lapagides,
Thanks for your help.
It is in wireshark I see the SYN packet options having an incorrect MSS value. when the stream reaches 1500 MTU I see icmp fragmentation needed arriving. It is as if the adjust-mss entry does not have any effect.
(EDIT:: removed wrong statement about telnet )
br Steven
What are the prereq. for the adjust-mss to work?
Hi Steven,
Nothing much, you add this command on the interface that connects to your hosts and thatās it. It only works for TCP traffic.
Rene
Does it work in both directions? also traffic ānot hittingā the ip of the interface or SVI?
Can it be put on a tunnel interface? Still not clear why it is not workingā¦
Hello Steven
I suggest you do a bit of experimentation by reducing the adjust-mss value to even lower values to see if the SYN MSS value is affected. If not, then there is some issue with the way that the adjust-mss value is being implemented on the tunnel interface. Now there are several options for dealing with IP fragmentation and MTU sizes. These can be found in this Cisco Documentation:
See if any of these solutions fit better with your scenario.
In the meantime, can you send a more detailed description of your setup? Maybe a simple diagram showing the devices and the configuration of the tunnels as well? This way we can help you out in more detail.
I hope this has been helpful!
Laz
2 Likes
Very helpful, both the article and following discussion. I even think I maybe finally understand it 
.
Saying that the topic is somewhat confusing. I believe in part due to arbitrary use of terminology in some cases and in part due to actual implementation of the feature (thank you, CISCO almighty for keeping us thoroughly entertained by allowing your developers to implement features that are not systematic, logical or well structured. It saves us from a boredom).
However, if I understood correctly some of the things Lazaros said they seem opposing to what Rene said (and actually proved). Im referring to statement that if packet size exceeds the MTU size on interface its getting fragmented. That seems is not correct - it should be dropped. The whole point of what Rene showed and stated was that packet is only getting fragmented if its size exceeds the IP MTU set size. Quite different.
But I wonder still if I understood the whole thing correctly. So here is the summary of the whole confusing topic as I understood it.
Is it really correct? -
-
There are multiple values of the MTU pertinent to each individual network layer (or corresponding PDU).
-
MTU for TCP segments is actually called TCP Max Segment Size. It can be set on the router or switch interface to negotiate with the sending/receiving host the size of the Segment. Its size defines only actual TCP payload and does not account for 20B TCP header. By itself it does not affect traffic except changing size of sent data (which is different from lower layers MTUs).
-
IP MTU is defined as size of the TCP segment plus TCP header (20B) plus the header for IP packet itself (20B). By default on CISCO routers/switches it is 1500B. It is set on router interface and defines a max size of the packet that can pass through the interfaces unharassed. If packet exceed the IP MTU value it will be fragmented (not clear though whats the rule for fragmenting - how parts are defined).
-
MTU is defined as the size of L2 frame on interface. It includes the size of the IP MTU andā¦ and nothing else. Since the Frame header now is not counted the MTU by default is equal IP MTU. If IP MTU is set to be smaller then there is no problem, frame just would be āunderutilizedā since no IP packet would be able to fill up the allowed size for the frame. If IP MTU is larger though then packet can come which is larger than MTU in which case the packet is dropped, frame is not formed. Frames do not support fragmentation as packets do.
-
It is possible to set MTU globally by defining System MTU - it will provide default MTU for all interfaces.
-
To avoid packet drops at the very least the IP MTU should be equal or less than frames MTU. Reducing IP MTU will lead to higher probability of fragmentation. It maybe beneficial in certain cases, when there is additional header inserted on top of IP header - in this case IP MTU may allow packet size which together with additional header will exceed frame MTU so the packet gets dropped. Similarly, if IP header is replaced with some other, larger than 20B header it may cause the same problem. In that case reducing IP MTU (and/or increasing frame MTU) may prevent packets drops, though at the price of fragmentation.
-
Where possible it might be better to leave IP MTU alone (though still OK to increase frame MTU) and instead reduce the TCP Masx Segment Size - that will not fragment the packets, so its better from routers utilization point of view, and will help avoiding packets drops due to exceeding MTU.
I guess that covers the most fundamental part. Would be happy if that is all correct. It still leaves some other questions, like alternate and jumbo MTUs for additional discussion.
Also, to add spice to the topic, Path MTU discovery feature is by default enabled on most contemporary equipment, based on ICMP protocol extensions and consists of detecting the disabled fragmentation for packets exceeding IP MTU (by checking if DF bits in packets set to ā1ā) and requesting the sending equipment to resend the dropped due to too large size packets with smaller TCP payload.
1 Like
Hello Vadim
Whether a packet will be dropped or fragmented depends on the contents of the Do Not Fragment (DF) bit field in the IP header. If it is set to 1 the packet is dropped. If it is set to 0 the packet is fragmented into two frames.
Your explanation seems to show that you indeed have a solid understanding of the topic as I cannot see any issues with what you have written.
Jumbo MTU is the system MTU that is used for GigabitEthernet ports. This is often set to higher values in order to accommodate specific applications that run over the network.
Alternate MTU, by itself, does nothing until you specifically assign it to a specific port. It defines a third interface MTU that fits between the system MTU and jumbo MTU. The system MTU is the interface MTU for the 10/100 ports. The jumbo MTU is the interface MTU for the GE ports. The alternate MTU can be an interface MTU for any 10/100 or GE port. You apply the Alternate MTU with a global command that maps the alternate MTU to the desired interfaces. A change to the alternate MTU or any of its applied interfaces, like the system and jumbo MTU commands, requires a reload.
Yes, this is another feature that can be very useful, but is often not usable because ICMP packets, which are necessary for its functionality, are often blocked for security reasons from many intermediary devices.
I hope this has been helpful!
Laz
1 Like