The Network's Blind Spot: Chasing MTU Mismatches

Network problems can leave even the most experienced IT pros stuck from time to time. Sometimes the connection looks like it’s there, but specific applications don’t work, web pages load slowly, or VPN connections keep dropping. Behind these kinds of mysterious issues, there’s often an overlooked factor: an MTU mismatch.

The Maximum Transmission Unit (MTU) defines the largest data unit a network interface can send in a single packet. Inconsistent MTU values across devices on a network prevent data packets from being delivered properly, leading to performance drops and connection issues. In this guide, we’ll walk step by step through what MTU is, how to diagnose MTU mismatch problems, and effective solutions.

What Is MTU and Why Does It Matter?

MTU (Maximum Transmission Unit) refers — in bytes — to the size of the largest data unit a network protocol can transmit in a single frame or packet. This value is usually set by the physical-layer and data-link-layer (Layer 1 and Layer 2) technologies. For example, the default MTU value for standard Ethernet networks is 1500 bytes.

The MTU value plays a critical role in the efficiency and reliability of data communication on the network. If a sent packet is larger than the MTU of a device on the network, that packet is either fragmented or dropped entirely. Both situations can negatively affect network performance and lead to issues.

Every device on the network — whether it’s a router, switch, or computer — has its own MTU value. The MTU values of all devices along every path a packet travels from source to destination matter. If a packet is larger than a device’s MTU and the “Don’t Fragment” (DF) bit is set, that packet is dropped and an ICMP “Fragmentation Needed” message is typically sent back to the sender.

The Network’s Silent Killer: MTU Mismatch

An MTU mismatch happens when two devices — or a device and a network segment — on the network have different MTU values. This shows up most often where different networking technologies meet (such as a transition from Ethernet to PPPoE, or VPN tunnels) or as a result of misconfigurations. The consequences are usually misleading and hard to diagnose.

Common signs of an MTU mismatch include:

• Slow or intermittent connections: Issues during large file transfers or video streaming, in particular.
• Trouble reaching specific websites or applications: Some sites open while others fail to load entirely or appear with missing content.
• VPN connections that drop or run slowly: VPN tunnels add an extra header, which lowers the effective MTU value.
• Ping succeeds, but HTTP/HTTPS fails: Small packets (ping) get through, while large TCP segments (web traffic) hit problems.

Path MTU Discovery (PMTUD) and Why It Fails

Path MTU Discovery (PMTUD) is a mechanism used to dynamically determine the smallest MTU value (Path MTU) along the route from a source to a destination. This mechanism is used by connection-oriented protocols like TCP and aims to avoid IP fragmentation. PMTUD works by sending packets with the DF bit set and listening for ICMP “Fragmentation Needed” messages from routers along the way.

When PMTUD fails, the sender can’t learn the Path MTU correctly. As a result, the sender keeps trying to send large packets that are either dropped or fail to reach the destination. The result: connection drops, slowdowns, and timeouts, because the sender keeps trying to retransmit the data.

Diagnosing MTU Mismatch

Diagnosing an MTU mismatch requires patience and a systematic approach. Here are the main tools and methods you can use:

Using Ping with the Don’t Fragment (DF) Bit

This method is quite effective at determining the largest MTU on the network path. When you send a ping packet with the DF bit set, the packet can’t be fragmented by any router on the path. If the packet is larger than a router’s MTU, the router drops the packet and sends back a “Fragmentation Needed” (Windows) or “Packet needs to be fragmented but DF set” (Linux/macOS) error message.

On Windows:

ping <target_ip_address_or_hostname> -f -l <size>

• -f: Sets the Don’t Fragment (DF) bit.
• -l <size>: Specifies the data payload size of the packet to be sent. The total packet size is obtained by adding the ICMP header (8 bytes) and the IP header (20 bytes).

Example Use:

First, start with 1472 bytes by subtracting 28 bytes (the ICMP and IP headers) from the standard Ethernet MTU of 1500.

ping google.com -f -l 1472

If this ping succeeds, keep trying larger sizes (e.g., 1473, 1474). If you get a “Packet needs to be fragmented but DF set” or “fragmentation needed” error, lower the size and try again.

ping google.com -f -l 1473
Packet needs to be fragmented but DF set.

In this case, since 1472 bytes worked and 1473 bytes failed, the Path MTU is 1472 + 28 = 1500 bytes. If you’re getting an error at a smaller size (e.g., 1400), the Path MTU is lower and you should keep dropping the size until you find that value.

On Linux/macOS:

ping -D -s <size> <target_ip_address_or_hostname>

• -D: Sets the Don’t Fragment (DF) bit.
• -s <size>: Specifies the data payload size of the packet to be sent.

Example Use:

ping -D -s 1472 google.com

Using Traceroute and MTR

Traceroute (tracert on Windows) shows the routers a packet passes through on its way from the source to the destination, along with the latency at each hop. It’s not normally used directly for MTU diagnosis, but if you see unusual latency or packet loss at one hop, it can point to an MTU issue at that point.

mtr (My Traceroute) is a more advanced tool that combines ping and traceroute functions. It continuously monitors packet loss and latency, which can help you pinpoint problem spots more clearly. Some mtr versions also offer options that help determine the Path MTU.

# Linux/macOS
mtr -r -c 100 <target_ip_address>

Packet Capture with Wireshark

Wireshark or any similar packet analyzer is one of the most powerful tools for diagnosing MTU mismatches. By capturing network traffic, you can directly see ICMP “Fragmentation Needed” messages or unusual TCP retransmissions.

What to look for:

1. ICMP “Fragmentation Needed” messages: On a connection going from source to destination, you can see that packets above a certain size are being dropped and that these ICMP messages are being returned. These messages show that the Path MTU isn’t what’s expected.
   • Filter: icmp.type == 3 && icmp.code == 4
2. TCP Retransmissions: When large TCP segments fail to reach the destination because of an MTU mismatch, the sender keeps retransmitting them. A high count of these retransmissions in Wireshark is one of the signs.
   • Filter: tcp.analysis.retransmission
3. Packet Sizes: Compare the packet sizes on connections that succeed and those that fail. You can spot packets above a certain size getting stuck.

Solving MTU Mismatch

Solving an MTU mismatch generally involves optimizing the MTU settings on devices on the network or making sure PMTUD works correctly.

Setting the Interface MTU

Based on the optimal Path MTU value you’ve found, you can adjust the MTU values on the network interfaces of the troubled devices. Remember, you mustn’t assign a value larger than the Path MTU when doing this.

On Windows:

Run the command prompt as administrator.

1. View the existing interfaces and their MTU values:

   netsh interface ipv4 show subinterfaces

2. Change the interface’s MTU (e.g., 1492 for the “Ethernet” interface):

   netsh interface ipv4 set subinterface "Ethernet" mtu=1492 store=persistent

   The store=persistent command makes the setting persist across reboots.

On Linux:

1. View the existing interfaces and their MTU values:

   ip link show

2. Change the interface’s MTU (e.g., 1492 for eth0):

   sudo ip link set dev eth0 mtu 1492

   This command is temporary. To make it persistent, you may need to edit configuration files like /etc/network/interfaces or /etc/sysconfig/network-scripts/ifcfg-eth0 (varies by distribution).

Router/Firewall Configuration

One of the underlying causes of most MTU problems is routers or firewalls blocking ICMP “Fragmentation Needed” messages. Allowing these messages through can let PMTUD work properly and automatically resolve many issues.

Allowing ICMP (Example: iptables - Linux Firewall):

sudo iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
sudo iptables -A OUTPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT

These rules allow ICMP Type 3 Code 4 messages on input and output. To make them persistent, you need to save them to your firewall configuration.

MSS Clamping (Maximum Segment Size Clamping):

MSS clamping is a solution commonly used in scenarios like PPPoE or VPN tunnels. The router adjusts the MSS value in TCP SYN packets based on the MTU of its own outgoing interface, preventing the destination device from being offered a segment size larger than the Path MTU. This effectively prevents fragmentation and PMTUD issues for TCP connections.

• MSS (Maximum Segment Size): The largest amount of data a TCP segment can carry, excluding TCP and IP headers. It’s usually calculated as MTU - (IP Header + TCP Header) (e.g., 1500 - 20 - 20 = 1460).
• MSS Clamping: The router lowers the MSS value of SYN packets passing through a connection to a value appropriate for the outgoing interface’s MTU.

MSS Clamping Configuration on a Router (Example: Cisco IOS):

interface GigabitEthernet0/1
 ip mtu 1500
 ip tcp adjust-mss 1452  # (1500 - 20 - 28 = 1452, for VPN or PPPoE 1492 - 20 - 20 = 1452)

Here, 1452 is generally an appropriate MSS value for a PPPoE connection that has a 1492 MTU (1492 - 20 byte IP header - 20 byte TCP header = 1452). You should adjust this value based on your own network setup.

VPN-Specific Solutions

VPN tunnels often add an extra tunnel header, which lowers the effective MTU value. This can cause MTU mismatch issues for traffic going over the VPN.

• VPN Client MTU Setting: Many VPN clients (e.g., OpenVPN, WireGuard) offer the option to set the MTU value manually. Choosing a value appropriate for the VPN tunnel’s Path MTU can fix connection issues.
• VPN Server MTU/MSS Setting: On VPN servers (e.g., OpenVPN server), you can configure the tunnel MTU and MSS clamping using directives like tun-mtu or mssfix.

  # OpenVPN server config
  tun-mtu 1400
  mssfix 1360  # (1400 - 40 = 1360)

  These settings make sure the packets inside the VPN tunnel are the right size.

Best Practices and Prevention

Some best practices for preventing MTU mismatch problems and making your network more robust:

• Consistent MTU Settings: As much as possible, try to use consistent MTU values across all devices and segments on your network. Be especially careful when transitioning between different network technologies.
• Allow ICMP: Make sure your firewalls and routers permit ICMP “Fragmentation Needed” messages. This is vital for PMTUD to work properly and for the network to adapt itself.
• Monitor Network Performance: Regularly monitor performance drops, latency, and packet loss on your network. These kinds of indicators can point to potential MTU problems.
• Documentation: Document the MTU settings of critical devices on your network and why they’re configured that way. This will significantly ease future troubleshooting.

Conclusion

MTU mismatch is a sneaky problem that remains the network’s blind spot — hard to diagnose but capable of causing serious performance issues. With the right tools and a systematic approach, however, it’s possible to find and fix these problems. The DF-bit ping test, packet analysis with Wireshark, and optimizing MTU/MSS settings on routers and devices are the cornerstones of this fight.

When you run into mysterious connection issues on your network, make checking MTU a habit. Ensuring PMTUD works properly and optimizing the MTU settings on your network devices will deliver a more stable, faster, and more efficient network experience. Remember — every small detail on your network can affect overall performance.