MTU
The largest packet a link will carry. 1500 bytes on Ethernet and most of the internet; 1492 on classic PPPoE; lower inside tunnels and VPNs.
A path that carries smaller packets than Ethernet costs a little efficiency and nothing else — provided the routers say so. A path that silently drops oversized packets instead produces connections that establish, transfer a little, and then hang forever. That failure is extremely hard to diagnose from the inside, and it is the one worth finding.
The largest packet a link will carry. 1500 bytes on Ethernet and most of the internet; 1492 on classic PPPoE; lower inside tunnels and VPNs.
The smallest MTU along the whole route, which is what actually constrains a connection. Discovered rather than configured.
The TCP segment size that follows: the path MTU minus 40 bytes for the IPv4 and TCP headers, or 60 for IPv6.
A path that drops oversized packets without sending the ICMP message that says so. Connections open, then stall the moment a full-size packet is needed.
A connection that opens fine and then hangs. SSH logs in and freezes on the first large output. A web page starts loading and stops. A VPN connects, small things work, and file transfers die. Email sends short messages and hangs on attachments.
The mechanism is always the same. Something along the path carries smaller packets than your end thinks, and the router that should say so — with an ICMP “fragmentation needed” message — is either not sending it or is being blocked by a firewall that treats all ICMP as suspicious. Your end keeps sending full-size packets that quietly vanish. Small packets get through, which is why the connection appears to work until it does not.
The fix is usually MSS clamping rather than changing an MTU. Clamping rewrites the segment size that the two ends agree during the TCP handshake, so neither ever sends a packet too large for the path. Every firewall and most routers can do it, and it is the standard remedy on any link with a tunnel in it. The alternative — allowing ICMP type 3 code 4 inbound — is more correct and depends on a firewall you may not control.
For calls, the MTU is mostly irrelevant. Voice packets are small; a 20 ms G.711 frame is about 200 bytes and fits anywhere. Where it bites is signalling: a SIP INVITE carrying a large SDP body can exceed the path MTU over UDP and disappear, which presents as calls failing to set up while the ones that connect sound perfect.
Leave it at 1500 unless something specific requires otherwise. The common exceptions are PPPoE connections, which need 1492, and VPN interfaces, where the tunnel software usually sets the right value itself. Lowering the MTU on a LAN interface to work around a path problem is treating the symptom, and MSS clamping is the more precise fix.
That is the classic path-MTU black hole. Something is dropping oversized packets without reporting it, so your end keeps retransmitting a packet that can never arrive. MSS clamping on the affected link resolves it, and this test will show whether the path narrows and then goes silent.
Because the tunnel adds its own headers to every packet, and those bytes come out of the payload. WireGuard defaults to 1420, IPsec lands around 1438, and OpenVPN varies with its configuration. The figure is the original 1500 minus whatever the tunnel adds.
No. It is what a PPPoE link gives you, which covers a great deal of DSL. It costs about half a percent of throughput in overhead and nothing else, so long as discovery works.
With the same probe as the traceroute: packets are sent at full size, and when a router refuses one it reports the largest size it will carry. That report is what path MTU discovery depends on, so this is also a test of whether discovery itself is functioning.
We design, procure and manage business connectivity — circuits, SD-WAN, failover and the prioritisation that keeps voice usable while the line is busy. A result that is persistently below what you pay for, or calls that break up on a connection which tests clean, is a diagnosis worth doing properly rather than repeatedly.