Fixing MTU Mismatch Issues in Linux

MTU (Maximum Transmission Unit) defines the largest packet size that can be transmitted across a network without fragmentation. When devices along a network path have different MTU configurations, MTU mismatch issues happen, which can cause periodic connectivity problems that are very difficult to recognize.

An MTU mismatch happens when parts of a network use different MTU sizes, for example, 9000 vs 1500 bytes. This can disrupt traffic if Path MTU Discovery cannot adjust the packet size. PMTUD relies on ICMP Fragmentation Needed messages to tell the sender to send smaller packets. If firewalls block ICMP, PMTUD fails, and packets get dropped, which creates an MTU black hole.

In this guide from PerLod Hosting, you will learn how MTU mismatches cause network issues and discover the best strategies for detection and fixes.

MTU mismatch issues can cause periodic connectivity problems that are hard to debug. Simple tests may work, but bigger data transfers can fail, and the exact symptoms depend on the app or protocol.

Here are the most common symptoms of MTU mismatch issues:

1. Connection Establishment vs. Data Transfer Failures:

Initial connections may work, but data transfer can fail or freeze. Small packets like the TCP handshake get through, while larger packets hit the MTU limit and get dropped. A common example is SSH. You can connect and log in, but commands that produce lots of output may hang because the bigger packets cannot pass.

2. Application Failures:

Different apps can fail in different ways when there is an MTU mismatch.

• Web browsing: Some sites load, but others hang or only partially load, especially HTTPS.
• VPN Connections: The VPN adds extra headers, so the usable MTU gets smaller. The VPN stays connected, but websites and transfers may fail or time out.
• Database Replication: The connection starts, then replication stalls when it tries to send large rows or bulk data.
• File Transfers: Small files work, but large files freeze partway through. They do not just get slower, they stop.
• VoIP and Streaming: Calls and video get choppy, pixelated, or drop because packets are lost.

3. Black Hole Symptoms:

MTU black holes happen when oversized packets get dropped with no warning. This usually occurs because routers do not send ICMP Fragmentation Needed messages, often due to firewalls blocking ICMP or router misconfiguration. They are hard to spot because small tests like ping still work, but real applications that send larger data hit timeouts or random failures.

4. Performance Slowdown Symptoms:

Even if the connection does not completely fail, an MTU mismatch can still slow down performance:

• Excessive Fragmentation: If packets can be fragmented, routers split large packets into smaller pieces. This adds extra headers, increases CPU work, and if one fragment is lost, the whole packet must be resent.
• Increased Retransmissions: When large packets get dropped, apps time out and resend data, which wastes bandwidth and adds delay.
• Higher Latency: Fragmentation and reassembly add processing overhead, so interactive apps like SSH or real-time audio and video feel slower.

5. Environmental Factors:

Some network setups make MTU mismatch issues more common:

• Tunneling Protocols: GRE, IPsec, and VXLAN add extra headers, which lower the usable MTU, and it drops even more if tunnels are stacked.
• Cloud and Container Networks: Overlays in environments like AWS, Azure, and Kubernetes often reduce MTU from 1500 to around 1450 or less.
• WAN Links: PPPoE, DSL, and some MPLS networks use non-standard MTUs like 1492, which can clash with Ethernet 1500.

You need a step-by-step method to find MTU mismatches. This can be done by systematic testing, including checking the MTU at each hop, and making sure the whole network path can carry the packet size you need.

You can run these MTU mismatch issue tests directly on your VPS server to confirm the real path MTU between your host and the destination.

Before testing the network path, first check the MTU on your local network interface. On Linux, you can run the ip command to display interface details, including MTU:

In the output, look for the MTU field:

For a specific interface, you can use the command below:

Alternatively, you can use the commands below:

Also, you can check the MTU value directly from the system filesystem:

For a comprehensive view of all interface statistics, including MTU mismatches, you can use the command below:

In the output, you will see MTU alongside packet statistics:

Ping is the main tool for checking MTU mismatches on a network path. It sends test packets of specific sizes with Do Not Fragment enabled, so you can see the largest packet size that can pass without being split.

The basic syntax for MTU mismatch testing with ping on Linux looks like this:

Command options:

• -M do: Turns on Do Not Fragment. If the packet is too big, it gets dropped instead of being split.
• -s <packet_size>: Sets the ping payload size in bytes. Total packet size is payload + 28 bytes for IP and ICMP headers.
• -c 4: Sends 4 pings, then stops.
• <destination>: The host or IP you are testing.

Calculating Packet Size:

To test a specific MTU with ping, set the payload size to:

For example:

• MTU 1500: payload 1472 (1500 - 28).
• MTU 9000: payload 8972 (9000 - 28).
• MTU 1400: payload 1372 (1400 - 28).

Test standard Ethernet MTU 1500 bytes with:

Here is an expected output when MTU is supported:

Test jumbo frames MTU 9000 bytes:

If the packet size exceeds the path MTU, you will receive an error including fragmentation is needed:

To find the largest MTU the path supports, start with a large ping payload and lower it until the ping succeeds. You can automate this with a simple loop that retries with smaller sizes:

To find the exact path MTU faster, you can use a binary search. Test a middle packet size, then go higher if it works or lower if it fails, until you narrow down the maximum size that passes:

Save this as find-mtu.sh, make it executable, and then run:

Tracepath shows the route to a destination and finds the MTU mismatches along the way. Unlike ping, it can point out which hop causes the MTU to drop.

Basic usage looks like this:

Example output:

Explanation:

• pmtu 1500: The path MTU starts at 1500 bytes, usually your local interface.
• pmtu 1400: At that hop, the path MTU drops to 1400 bytes.
• reached: The destination is reachable.
• Resume: The summary shows the final path MTU, for example, 1400 bytes.

Tracepath is useful because it shows where the MTU changes, which helps you find the device causing the mismatch.

Tracepath options include:

To test if the path supports a specific MTU, you can use the -l option:

If the output shows MTU reductions, you have found where the mismatch happens.

ICMP filtering can break Path MTU Discovery and create MTU black holes. You can test whether ICMP Fragmentation Needed messages are being delivered:

Send oversized packets with the DF bit set:

Monitor with tcpdump on the source host:

You must look for:

• ICMP Fragmentation Needed messages appear: PMTUD is working, and you will see errors like Destination unreachable (Fragmentation needed).
• No ICMP messages show up: ICMP is likely blocked somewhere, so packets get dropped silently, creating an MTU black hole.

Specific tcpdump filter for Fragmentation Needed messages:

This filter shows only ICMP Type 3 Code 4 (Fragmentation Needed) messages, the specific ICMP message used for PMTUD.

VPN tunnels add extra headers, so the usable MTU inside the tunnel is smaller. To find the real MTU, you can ping a host through the tunnel with DF enabled and adjust the payload size until it works.

For IPsec VPNs: IPsec adds extra header data, usually about 50 to 73 bytes, depending on the encryption and settings:

If 1422 succeeds, the effective MTU is 1450 bytes (1422 payload + 28 headers).

For GRE tunnels: GRE adds 24 bytes of overhead (20-byte IP header + 4-byte GRE header):

For GRE over IPsec, combined overhead is about 80 bytes:

Start with a smaller packet size, then increase it step by step until it fails. This helps you find the largest MTU that still works end-to-end:

For deep analysis, you can capture actual traffic and examine fragmentation behavior:

Capture oversized packets with the command below:

This captures all packets exceeding 1500 bytes, which should not exist on standard Ethernet if PMTUD is working correctly.

Capture ICMP and test traffic with the command below:

You can transfer the capture file to a system with Wireshark and apply filters to analyze it.

Here is a comprehensive script that combines multiple MTU testing methods:

Save it as mtu-discovery.sh, make it executable, and run with the commands below:

Once MTU mismatch issues are found, you can use several strategies to solve them. The optimal solution depends on your network topology, infrastructure control, and operational requirements.

Here are the most effective strategies you can use to fix MTU mismatch issues:

The most powerful solution is to ensure all devices in the network path use consistent MTU values. This removes mismatches at the source rather than working around them.

To find all devices in the path, you can use traceroute or tracepath to map the complete network path:

Set the same MTU on all routers, switches, and hosts on the path. For most networks, the safe default is 1500 bytes.

Only use 9000-byte jumbo frames if every device on the path supports it end-to-end. Otherwise, you will see fragmentation or dropped packets.

Verify consistency after changes with the command below:

The output should show a consistent PMTU value throughout the path.

For quick testing, you can temporarily change your interface MTU so you can confirm the issue is MTU-related before making permanent changes.

On Linux, you can use the command below to update the MTU immediately:

Replace eth0 with your actual interface name and 1400 with the desired MTU value.

Verify the change with the command below:

Look for mtu 1400 in the output to confirm the change is applied.

Use the ifconfig command to bring up the interface after the MTU change:

Important notes about temporary changes:

• These changes are lost after a system reboot.
• The interface may briefly disconnect during the MTU change.
• Applications with active connections may need to reconnect.
• Test connectivity after changing MTU to ensure the value is correct.

After changing the MTU, immediately test that it resolved the issue with the commands below:

To make MTU changes persistent across reboots, you must update your network configuration files. You can use different methods depending on your Linux distro and network management system:

List existing connections with the nmcli command:

Set MTU for a specific connection:

Replace Wired connection 1 with your actual connection name and 9000 with your desired MTU.

Reapply the configuration without disconnecting:

Or restart the connection, which causes a brief disconnection:

Verify the configuration with the command below:

You should see ethernet.mtu: 9000 in the output.

Connection profiles are stored in /etc/NetworkManager/system-connections/. Edit the appropriate file:

Add or modify the MTU setting in the [ethernet] section:

Reload the configuration with the commands below:

On older Red Hat-based systems using network scripts, you can edit the interface configuration file:

Add or modify the MTU line:

Restart networking to apply changes:

Or you can restart just the specific interface:

Verify the configuration with the command below:

Many modern distributions use systemd-networkd for network configuration. You can create or edit a network file with the command below:

Add the MTU configuration:

For static IP configuration:

Restart systemd-networkd and verify the configuration with the commands below:

In the output, you must see MTU: 1400 or your configured value.

Ubuntu uses Netplan for network configuration. Netplan reads YAML files and then generates the actual settings for the backend it uses, usually NetworkManager or systemd-networkd.

Edit the Netplan configuration file with the command below:

Configure MTU in the YAML file.

For DHCP with custom MTU:

For static IP with custom MTU:

For bonded interfaces (LACP) with custom MTU:

Test the configuration before applying and apply the configuration permanently:

Verify the configuration:

On Debian and older Ubuntu systems using ifupdown, you can edit the interfaces file:

Add MTU configuration.

For DHCP:

For static IP:

Alternative syntax using the post-up command:

Restart networking or restart the specific interface:

When using DHCP, you can configure the DHCP client to request or override the MTU:

Edit the dhclient configuration:

Add lines to set MTU.

To use a specific MTU regardless of the DHCP server:

To set a default if DHCP does not provide MTU:

Restart the network interface to apply DHCP changes:

TCP MSS clamping is a workaround for MTU problems in TCP connections. It prevents MTU issues for TCP traffic by manipulating the TCP handshake, so packets stay small enough for the path MTU, which avoids fragmentation and drops.

MSS clamping is particularly useful in scenarios where you cannot modify MTU on all devices, like across an ISP, or when using VPN tunnels where encapsulation lowers the usable MTU.

MSS is the TCP data size limit, calculated as:

For example:

• MTU 1500: MSS 1460 bytes.
• MTU 1400: MSS 1360 bytes.

Using iptables for MSS Clamping: Add MSS clamping with an iptables TCPMSS rule. Use FORWARD on a router or gateway for transit traffic, and OUTPUT for traffic generated locally.

Clamp to PMTU (Path MTU Discovery):

This adjusts MSS based on the discovered path MTU, which is the most flexible method.

Clamp to specific MSS value:

Use this when you know the exact MSS needed, which is common for VPS gateways.

For VPN tunnels (IPsec) on the gateway:

This clamps MSS for traffic from the VPN network going out interface eth0.

For GRE tunnels:

GRE overhead is around 24 bytes, so MSS should be reduced accordingly.

To make iptables rules persistent, create a systemd service:

Add the following content:

Enable and start the service with the commands below:

Use firewalld for MSS clamping on RHEL:

Or with a specific value:

Verify MSS clamping is active with the command below:

Look for MSS values in SYN packets. They should match your clamped value.

When you use tunnels like VPN, GRE, or VXLAN, the tunnel adds extra headers, so you should lower the tunnel interface MTU to leave room for that overhead.

For GRE tunnels, for example on Cisco IOS:

For IPsec VPN, for example strongSwan on Linux, edit /etc/ipsec.conf:

For OpenVPN, edit the server configuration:

For WireGuard:

Make it persistent in WireGuard configuration:

Linux has a feature called TCP MTU probing that can adjust TCP packet size even when ICMP is blocked. It is off by default, but you can enable it with Linux kernel probing.

Check the current setting with the command below:

Enable TCP MTU probing with the following command:

• 0: Disabled
• 1: Enabled when an ICMP black hole is detected
• 2: Always enabled

Make it permanent by editing /etc/sysctl.conf:

Add this to the file:

Apply without reboot:

Adjust base MSS for probing:

Make permanent in /etc/sysctl.conf:

After implementing any MTU fix, verify that it resolves the issue.

You can test with ping:

Test application connectivity:

Monitor for errors:

Verify MTU consistently:

Check for TCP retransmissions:

MTU mismatch issues happen when devices on the same network path use different MTU sizes, often made worse when ICMP is blocked and Path MTU Discovery cannot work. They usually look like connects fine, then hang or time out when sending real data, which affects things like SSH, HTTPS, VPNs, file transfers, databases, and VoIP.

You can find them by testing packet sizes end-to-end, checking hop-by-hop MTU drops, and inspecting traffic for drops and fragments.

Fixes include using a consistent MTU everywhere, lowering MTU on tunnels, using TCP MSS clamping when you cannot change the network, and enabling TCP MTU probing on Linux if ICMP is blocked.

We hope you enjoy this guide on MTU mismatch issues. Subscribe to X and Facebook to get the latest articles and updates.

For further reading:

Resolve Kubernetes MetalLB External IP Not Reachable

Resolve Conntrack Table Full Errors