MTU Troubleshooting on Cisco IOS

Thx for your reply, Actually i know all of these info, I will ask my Q’s in another way
could you please answer each one independently ?

during the handshake, for example both agreed on mss 9860 ( Header =40 bytes )

Q1:How did they agreed on 9860? what are the criteria that they took? is it just the interface mtu in all the path and the header? or there is somethings to be considered also?
i know that mss= mtu-header.

Q2: is it mandatory that the packet should be 9000 in our case ( if the header =40)? or it may be less and this depending on the payload size?
i mean if the payload is small, will the segment be small as well in our case? or it is mandatory to be as aggreged ( fix size ) always.

Q3:
Q4:When my payload is just 1460 and the mss is 9860, will the padding take place here mandatory?

Hello Ali

Sure, no problem, I can respond to each question specifically.

The MSS is determined primarily based on the MTUs of the NICs of the sender and receiver. This process is further described in this NetworkLessons note. However, as mentioned in the note, the MSS can be influenced by using the TCP adjust-mss feature, where the MSS value in a SYN packet can be replaced with another value by an intervening router. So if a TCP sender and receiver agree upon 8960 bytes as the MSS, that means that their NICs support an MTU size of 9000. But this does not guarantee that the intervening network infrastructure supports this. The network designer must ensure that this is the case.

No it is not mandatory. The MSS defines only the maximum. The segment size can actually be anything up to the MSS value. So you don’t even need padding, you can have segments of varying sizes without any problem.

No there will be no padding necessary. The segment size of that particular transmission will be limited to the payload you have. Again, the MSS only defines the maximum size, not the size of all segments. Does that make sense?

I hope this has been helpful!

Laz

clear, thx
but recently i faced issue which is strange for me, i thought that maybe i understood something worng, anyway, simply i have network with 9000 mtu in all the path ( Spine, Leaf and FW), but from server side 1500, my edge FW is Mikrotik and each server can contact other servers normally, when i shifted the service to the new FW which is Fortigate ( I have experience in Security), SSH and some services freezes between Servers, but they can reach internet normally, again all the path 9000, just servers 1500, Freeze issue mostly related to MTU but as far as i know it should be no issue as long as they will communicate the mss, but when we changed the MTU from server side to 9000, All pass and cleared with no issue, what do u think the issue? i couldn’t perform packet capture due to the time, because we had production services during the operation.

1500 pass with DF from server to the FW and old FW ( Mikrotik ) as well.

Hello Ali

The first question that comes to mind is, are you sure that the problem is MTU related? You mention that the freeze issue is mostly related to MTU. The first thing to do is to determine conclusively that this is the case. Some ways you can do this is to use a ping sweep of various MTU sizes from one server to the other, to see if you do get a drop after a certain size.

This is the most obvious quick and dirty test you can do, but you may not be able to if your firewall drops ICMP (ping) packets. If this is the case, and you have control over the FW, during a maintenance window, you can temporarily allow ICMP to traverse the firewall to do that test.

Another thing that comes to mind with your description is the Path MTU Discovery (PMTUD) feature. This is a mechanism used by endpoints in a network to determine the largest MTU size that can be used for data transmission between them. If the network path between two endpoints supports an MTU size of 9000, but one endpoint is set to an MTU size of 1500, the smaller MTU size will be used for data transmission.

The problem arises when PMTUD fails, which can happen if a network device (like your Fortigate firewall) in the path between the endpoints is blocking ICMP messages. PMTUD uses ICMP to perform its function, and it would fail resulting in intermittent connectivity. Since in your case it is only happening using SSH (as far as you can see), it may be that SSH is using PMTUD and the FW is blocking ICMP packet with the results you see.

These are just some thoughts that may help you out in your troubleshooting. Doing a packet capture will give you even more information, so that will be helpful when you get a chance to do it.

Let us know how you get along, and how you ultimately got to the bottom of the problem and solved it.

I hope this has been helpful!

Laz