What detail symptoms will I be getting if MTU size mismatch?

Hanry Zhou
Super Advisor

What detail symptoms will I be getting if MTU size mismatch?

If MTU size is set differently no a switch and server, 1500 on the switch and 9000 on the server, can the connection still be fine, just matter of performance downgraded, or I cannot use the connection at all? am I able to ping the interface?

Thank you for your advice!


Honored Contributor

Re: What detail symptoms will I be getting if MTU size mismatch?

So, you're talking about a MTU mismatch specifically within your local network segment.

By default, ping packets are much smaller than the MTU, so if you're using the ping command with default packet size, you will see no difference with the ping command at all.

Some versions of the ping command do have an option to prevent automatic fragmentation of packets larger than the MTU: if you enable that option and then attempt to send packets of e.g. 2000 octets in size, you will get 100% packet loss. In some situations and operating systems, you might also get an error message telling you if you are getting back ICMP "fragmentation needed" messages or other signs that your MTU is incorrect.

For example, on Linux systems you could use ping with these options to verify 9000-octet jumbo frame capability in your network:

ping -s 8972 -M do <target IP or hostname>

Note: some ping commands interpret the -s option as the packet payload size, so you must take into account the ICMP header size: here, 8972-octet payload + 28 bits of protocol headers = 9000 octets in total. Some other ping commands may make this calculation automatically for you.

On TCP connections, the initial connection will be successful: the SYN - SYN/ACK - ACK three-way handshake will complete. But as soon as the first packet of greater than 1500 octets in size is attempted, the connection may hang if the MTU mismatch is between your server and your local switch.

For example, a SSH connection with debug messages enabled might indicate it has successfully connected to the target host, but hang as soon as it should begin exchanging keys with the other end (as the key packets are the first protocol messages that can be larger than 1500 octets).

With the old FTP protocol, a plaintext authentication might be entirely successful, but as soon as you attempt to get a directory listing or to transfer a file, the connection might hang, unless the file is very small or the directory listing is very short.

A different MTU size in a different network segment that is behind a router/gateway should not be a problem at all, if the router/gateway is aware of the fact. In that case, the router/gateway will send back an ICMP "Fragmentation Needed" message, and your TCP stack will detect it, and, automatically limit the maximum TCP segment size for that specific connection only to avoid the need for fragmentation, and then will resend the failed segment as two or more packets sized optimally for that particular connection. This is the Path MTU Discovery, or PMTUD, mechanism.