Check MTU size with ping command

Check MTU size with ping command

　Since the MTU size is determined for each communication line, when a packet is passed through a communication path with an MTU smaller than the packet length, the packet is fragmented according to the smaller MTU size.

However, fragmentation causes the following problems and reduces network utilization efficiency.

• Fragmentation overhead occurs.
• Since packets are split, the number of packets increases.
• If any of the split packets is corrupted, all the original IP packets before splitting are ruined.

To solve this problem, we need to send packets in sizes that do not split along the way.

You can use the ping command to find out the optimal MTU value to your destination.

The usage of the ping command is as follows.

●For Windows

From the command prompt,

C:\>ping -f -l [size] <destination>

For the size, try gradually decreasing numbers such as 1,450 and 1,400.

　-f : Option to prevent packet fragmentation
　-l : Option to specify packet size

In the example above, fragmentation is required, so you should still try the ping command with a smaller size.

So try smaller sizes until the ping succeeds.

This time, the ping command succeeded with a size of “1,426”.

You can see that up to 1,426 bytes of data can be sent and received correctly.

MTU size = 1,426 + 8 (ICMP header) + 20 (IP header) = 1,454

The optimal MTU size is “1,454 bytes”.

The value is smaller than the Ethernet MTU size of 1,500 bytes.

　This is because if you are using a PPPoE (ADSL or FTTH) internet line, etc., the MTU size must be reduced by that protocol.

NTT’s FLET’S requires 46 bytes, which is the header size of PPPoE.

Therefore, the MTU size is “1,454 bytes”.

　The explanation up to this point is based on the assumption that a router in the route or the destination computer returns an error for an IP packet with the DF flag set so that the packet is not fragmented.

　Some routers and computers are configured not to report errors. Also, error reports may be filtered by firewalls along the way. In that case, the optimal MTU value cannot be investigated.

Path MTU Discover

　Since the MTU is determined for each communication line, when packets are passed through a communication path with an MTU size smaller than the original MTU size, they will not be able to pass through the communication line unless fragmentation (division processing) is performed.

Fragmentation causes the following problems and reduces network utilization efficiency.

• Incurs fragmentation overhead.
• Since the packets are split, the number of packets increases.
• If any of the fragmented packets are corrupted, all of the original IP packets are ruined.

To solve this problem, we need to send packets in sizes that do not split along the way.

　When a router receives a packet that is too large, it will drop the packet if the DF flag is set. Then, an ICMP error notification (Type3 Code4) is sent to the source host.

If the DF flag is not set, the packet is fragmented and sent.

　The source terminal that receives the ICMP error notification (Type3 Code4) uses the notified MTU as the route MTU. Note that this route MTU value is cached for a while.

The code list for Type 3 is shown in the table below.

　The error notification (Type3 Code4) is “Fragmentation Needed and DF set”. Turns out it’s just to notify the sender that fragmentation is needed.

　However, ICMP error notifications (Type3 Code4) may be filtered in the middle of the route. In that case, an appropriate MTU value cannot be communicated to the sender. This state is called “Path MTU Discovery Black Hole”.

When network administrators filter ICMP, they tend to set ICMP to reject outright.

If it is a Cisco router, it is apt to set “deny icmp any any”.

　For ICMP filtering, it is recommended to allow Code 3 “Destination Unreachable” and Code 11 “Time Exceeded”.