The MTU is the largest IP packet a link can carry without requiring fragmentation at that layer. Ethernet commonly supports an IP MTU of 1500 bytes, but tunnels, PPPoE, VPNs, and other encapsulation add overhead and may require a smaller effective packet size. TCP MSS is related but different: it describes the maximum TCP payload a host is willing to receive in one segment, leaving room for IP and TCP headers.
Place the concept in the packet path
Networking terms become easier when you place them in a real packet path: client interface, local link, IP configuration, default gateway, translation or routing, provider network, DNS and the remote service. Ask which device makes the decision described by the term, what information it uses, and whether the behavior stays on the local link or crosses a router. That mental model prevents unrelated settings from being blamed for the same symptom.
The core idea
Path MTU Discovery is intended to let endpoints learn the largest packet that can traverse the entire path. Problems appear when a tunnel reduces MTU and the network blocks or mishandles the control messages needed to adjust. Small packets may work while large HTTPS transfers, VPN traffic, uploads, or specific websites stall. This is sometimes called a PMTUD black-hole symptom.
A concrete example
A PPPoE connection adds overhead that can make a 1500-byte LAN packet too large for the WAN path unless the network handles it correctly. Browsing a simple page may succeed, while a VPN or specific TLS session hangs on larger packets. Correct MTU/MSS handling fixes the packet-size mismatch; changing DNS would not.
How to apply the idea
- Establish whether the problem affects all traffic or primarily large transfers/tunneled paths.
- Check whether PPPoE, WireGuard/OpenVPN/IPsec, GRE, or another encapsulation changed the effective path MTU.
- Use controlled ping tests with the “do not fragment” behavior where the operating system supports it, accounting for header size.
- Inspect router/VPN settings for MTU and TCP MSS clamping; change them only with a clear reason.
- Ensure firewalls do not indiscriminately block ICMP messages required for proper path behavior, especially in IPv6 where fragmentation rules differ.
- Retest both TCP and non-TCP applications after any change.
What the evidence should tell you
Use these observations to connect the protocol concept to something measurable on a client, router, switch, packet capture, or status page.
- Establish whether the problem affects all traffic or primarily large transfers/tunneled paths. This observation reveals where the behavior occurs in the packet path.
- Check whether PPPoE, WireGuard/OpenVPN/IPsec, GRE, or another encapsulation changed the effective path MTU. Use the result to distinguish protocol behavior from an unrelated application symptom.
- Use controlled ping tests with the “do not fragment” behavior where the operating system supports it, accounting for header size. A contradictory result is a reason to revisit addressing, scope, or topology assumptions.
- Inspect router/VPN settings for MTU and TCP MSS clamping; change them only with a clear reason. This observation reveals where the behavior occurs in the packet path.
- Ensure firewalls do not indiscriminately block ICMP messages required for proper path behavior, especially in IPv6 where fragmentation rules differ. Use the result to distinguish protocol behavior from an unrelated application symptom.
- Retest both TCP and non-TCP applications after any change. A contradictory result is a reason to revisit addressing, scope, or topology assumptions.
Deeper technical context
Lowering MTU blindly can mask a path problem but also reduces efficiency. MSS clamping is commonly used at routers to advertise a smaller TCP payload across a constrained tunnel, but it does not fix every protocol because it applies to TCP. IPv6 places even more importance on correct Path MTU Discovery because routers do not fragment forwarded IPv6 packets in the IPv4 style.
How to verify your conclusion
Do not stop at the first result that seems to confirm your theory. Repeat the decisive test after the change, compare it with a known-good client or path, and check that unrelated functions still work. For router changes, verify local management access, DHCP addressing, default gateway, DNS resolution, internet reachability and the specific feature you intended to fix. Keep the old setting in your notes until the network has remained stable long enough to trust the new state.
Common mistakes that create bad conclusions
- Setting MTU to a random low number from a forum without measuring the path.
- Confusing MTU with internet speed or Wi-Fi channel width.
- Blocking all ICMP for “security” and then breaking path discovery.
- Assuming MSS clamping fixes UDP-based protocols.
Security and recovery notes
Use these steps only on networks and devices you own or are authorized to administer. Never weaken authentication, expose a management interface to the public internet, or publish router credentials merely to make troubleshooting easier. A normal reboot is very different from a factory reset: rebooting preserves configuration, while a reset can erase ISP, Wi-Fi, VPN, reservation, forwarding and segmentation settings. Prefer the least destructive test that can answer the question.
Why the distinction matters in real troubleshooting
Many networking mistakes come from solving the wrong layer: changing DNS for a DHCP failure, changing Wi-Fi channels for a WAN outage, opening a port when CGNAT blocks upstream reachability, or resetting a router because an ARP/VLAN problem prevents one client from reaching it. Place the symptom beside the protocol’s scope. If the concept cannot influence the failing path, it is probably not the root cause.
Questions people usually ask
Is 1500 always the correct MTU?
No. It is common on Ethernet, but tunnels and access technologies can reduce effective path MTU.
Is MSS the same as MTU?
No. MSS is a TCP payload value; MTU is a link/network packet-size limit.
Can MTU problems affect only some websites?
Yes, especially when paths, packet sizes, and PMTUD behavior differ.
Should I block ICMP?
Broad ICMP blocking can break legitimate network functions. Use protocol-aware firewall policy rather than assuming all ICMP is harmful.
Bottom line
The useful outcome is not merely knowing the term or completing a setting change; it is being able to explain why the network behaved that way and reproduce the result safely. If the evidence points to a different layer than the one discussed here, follow the evidence rather than forcing the original theory.