In some cases, higher-layer protocols may create large-size packets that not all network paths can support, such as the case of the jumbo frames.
These large packets (or frames) exceed the conventional Ethernet 1500 bytes of MTU (Maximum Transmission Unit).
So, the routers along the path with a default Ethernet MTU in their interfaces will fragment any of these large size packets that threaten to hurt their performance.
An improperly configured MTU can lead to failed transfers and intermittent connectivity.
But what is more daunting is that troubleshooting these kinds of problems can be really challenging.
Fortunately, we can do advanced troubleshooting and find the path MTU with the precious simple networking tool — The Ping Command.
How Does Path MTU Discovery Work?
The default Ethernet II MTU size is 1500 bytes, which is the largest size allowed in most of the Internet.
Although this value is known to be suitable for most environments, it is sometimes adjusted to a higher or lower value.
Adjusting MTU values can help match and improve the capacity of the network.
Larger MTU values can lead to lower network overhead, while a smaller MTU can help decrease the network delay.
How do routers discover MTU in a path?
Modern routers and endpoints use a process known as Path MTU Discovery (PMTUD) to find the path MTU, which is smaller than its interface MTU.
The goal of this process is to find the MTU size of a path while avoiding IP fragmentation.
The PMTUD works by setting the “Don’t Fragment (DF)” flag bit ON, within the IP packet header.
Routers along the path will receive these incoming packets and compare them with their MTU.
If the router interface’s MTU is smaller than the packet’s, and the packet contains the “Don’t Fragment” flag bit on, then the router will be forced to drop the packet and send back an ICMP Fragmentation Needed error message.
Knowing that the path MTU is too large, the source can adjust its packet’s MTU accordingly.
The process is repeated until the MTU has the right size to go through the entire path without fragmentation.
Simulating the Path MTU Discovery Process
You can simulate the Path MTU Discovery process using the ICMP Ping command with additional flags.
Perform a Ping to the target destination address. It can be the local gateway, a server, or a remote IP address.
To do this, we will be using the following additional Ping Flags:
- -f: Set Don't Fragment flag in packet (IPv4-only).
- -l size: Send buffer size.
Start by adjusting the TCP send buffer (size) with the “-l” flag. In the following Windows OS screenshot, you can see that we are sending an ICMP packet of 2000 bytes in size to the public IP 18.104.22.168
The Ethernet packet with a size of 2000 bytes is generally larger than most MTU in typical networks.
The packet is successfully going through the path and reaching its destination because it is being fragmented by the routers along the path.
Now, let’s see what happens when we set the “Don't Fragment” flag, with the following command:
ping (destination IP) (-f) (-l (packet size))
When a packet is too large for a path MTU, a router would usually fragment it into pieces for a safer delivery.
But, as you can see from the screenshot above, now the destination returns a “Packet needs to be fragmented but DF set”.
Since we are choosing not to fragment packets, all the routers along the path will see no choice than to drop the packet.
For other Operating Systems:
Linux Ping Command:
ping (-M do) (-s (packet size)) (destination)
macOS Ping Command:
ping (-D) (-s (packet size)) (destination)
How to Find the Path’s MTU with Ping?
Now, to find the path MTU with a Ping command, you would need to repeat the process shown before and adjust the packet size every time.
You will ultimately find the path MTU by trial and error.
In the previous ping test, we used the 2000 bytes as the packet size.
You would probably want to start with a number around 1800-2000 bytes and move down every couple of 100 bytes until you get a successful ping reply.
As you can see in the following screenshot, we started with 1800, tested with 1500, until 1400 finally gave a successful reply.
That means the path MTU between our source and destination is somewhere between 1400 and 1500 bytes.
The next step would be to move the size up between 10-50 bytes until you get another successful reply.
We tested with 1450 bytes and got a reply, which means our value is above that.
Repeating this process led us to find the value, which is 1452 bytes.
The routers along the path were still fragmenting 1453 bytes (but not 1452). They considered 1453 to be too large to traverse the path.
But 1452 was the first proper packet size that returned a successful ICMP reply. My MTU value 1452 is common in Ethernet II.
But one more thing…
We have to take into account the size of the TCP/IP header, which can range between 20-60 bytes. The header size varies according to the transmission media.
According to a chart from Wikipedia.
My Point-to-Point Protocol over Ethernet (PPPoE) header takes up 8 bytes in size, while the IPv6 header accounts for 40 bytes in size. So, the size of my TCP/IP header is 48 bytes (40+8).
Let’s take the packet size that gave us the ping reply (1452 bytes) and add it to the header size (48 bytes).
That leads us to the real MTU size, which is 1500 bytes, the common Ethernet MTU.
1452 is the data payload size or Maximum Segment Size (MSS), that results from the 1500 MTU.