How do I investigate MTU-related connectivity problems?
MTU problems can allow small packets while larger requests stall, especially across VLANs, tunnels or overlay networks. The usable path MTU is constrained by the whole route, not just the local NIC. Test a controlled endpoint and interpret missing ICMP replies carefully because filtering can resemble an MTU failure.
Before you start
- Authorised access to the dedicated server and the named inspection tools.
Instructions
1. Read the local interface MTU
Inspect the actual routed interface and any tunnel/bridge layers. Do not assume a provider supports jumbo frames end to end.
ip link show dev enp1s0Replace the interface name. A locally configured large MTU does not prove the next hop or destination accepts the same packet size.
2. Run a small, bounded IPv4 test
Replace the documentation address with an authorised endpoint that responds to ICMP. With ordinary IPv4 and ICMP headers, a 1472-byte payload tests a 1500-byte IP packet.
ping -4 -c 3 -M do -s 1472 203.0.113.10-M do prevents fragmentation for this test. Reduce the payload deliberately when diagnosing; tunnels and other overhead may require a smaller value.
Check the result
- The tested path’s behaviour matches the configured MTU and the previously failing application request works after a reviewed correction.
Troubleshooting
- Every ping fails
- Check ICMP filtering and ordinary connectivity before concluding that packet size is the problem.
- IPv6 behaves differently
- IPv6 headers and path-MTU behaviour differ; do not reuse the IPv4 payload calculation blindly.
- Only one route fails
- Test the affected path, including any VPN or overlay, rather than changing the whole server’s MTU immediately.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.