PLPMTUD is an advanced mechanism (RFC 4821) that dynamically discovers the largest possible packet size (MTU) that can traverse a network path without fragmentation.
Unlike traditional Path MTU Discovery (PMTUD), which relies on ICMP “Fragmentation Needed” messages, PLPMTUD operates at the transport layer (e.g. TCP, SCTP, QUIC) and uses in-band probing to detect blackholes even when ICMP is blocked.
- Resilient to ICMP filtering
Works reliably even when routers or firewalls drop ICMP “Fragmentation Needed” messages.
This eliminates a common cause of silent TCP stalls and “black-hole” connections. - Automatic path optimization
Dynamically adapts the segment size (MSS) to the maximum supported by the current route, improving throughput and efficiency. - No manual tuning required
Reduces the need to manually adjust MTU or MSS values on interfaces, tunnels, or VPNs. - Improves reliability across complex paths
Particularly useful for paths that include VPNs, GRE/IPsec tunnels, or cloud networks with varying MTU sizes. - Gradual, safe probing
The kernel probes carefully, avoiding packet loss bursts or connection resets.
¶ Considerations
- Slightly increased handshake latency
Initial probing may slightly delay connection setup on long-RTT or lossy links. - More kernel state and probing traffic
Each TCP connection may maintain extra metadata and send occasional probe segments; negligible for normal workloads but measurable in large-scale environments with hundreds of thousands of concurrent sessions. - Only affects transport-aware protocols
PLPMTUD benefits TCP, SCTP, or QUIC; it does not affect pure UDP traffic unless the application implements its own PLPMTUD logic. - Possible interference with middleboxes
Some NATs or firewalls that aggressively filter “odd-sized” packets may cause probes to fail; the algorithm will recover, but convergence time increases. - Not a substitute for correct MTU configuration
Interfaces, tunnels, and VPNs should still be configured with consistent MTU values; PLPMTUD only compensates for unknown or variable paths.
¶ When to Use PLPMTUD ?
- Firewalls or routers blocking ICMP
Many enterprise firewalls silently drop ICMP packets for “security”.
Classic PMTUD then fails, leading to “TCP black holes” — where connections hang silently.
PLPMTUD fixes this by probing the MTU at the TCP layer without relying on ICMP.
eg: Users report “downloads hang at 99%” or “SSH freezes” after login — often caused by blocked ICMP.
- Tunneled or encapsulated links
VPNs (IPsec, OpenVPN, WireGuard), GRE, VXLAN, or MPLS reduce the effective MTU.
Intermediate tunnels might fragment or drop large packets.
PLPMTUD automatically adapts to the smaller MTU of the tunnel path.
eg Traffic between data centers via GRE or IPsec tunnels — path MTU can vary between 1400–1420 bytes.
- Mixed Artica Reverse-Proxy, Artica SMTP or Artica VPN
For Artica handling many external clients (e.g., reverse proxies, web gateways, mail relays, etc.).
Avoids sporadic stalls caused by MTU mismatches on client paths.
An Artica reverse proxy that serves both LAN users (MTU 1500) and VPN users (MTU 1400).
Use PLPMTUD whenever you can’t guarantee ICMP reliability or path MTU consistency.
It makes your TCP connections more robust and self-correcting — especially across VPNs, the Internet, or filtered networks.
UDP / QUIC - unecessary: handled in user space by the protocol stack (e.g., QUIC in Chromium implements its own PLPMTUD).This feature is available with v4.50 Service Pack 6 or in v4.50 Service Pack 5 Hotfix 20251028-16
¶ How to enable PLPMTUD inside Artica ?
On the left menu, go to Network & Nics > Interfaces > Network Interfaces Details (tab)
Click on “Kernel network optimization” button.
Turn on the TCP MTU Probing checkbox.
