Small pings succeed, DNS resolves, and a TCP connection opens. Then a web page stalls during TLS or loads only part of its content. On an L2TP or PPPoE service, this is a strong reason to investigate packet size. Small control packets can cross a path that silently discards larger data packets.
The fix starts with an encapsulation budget for each segment. A number copied from another LNS may fit its transport and fail on yours, particularly when IPsec protects the tunnel.
Count headers on the segment where they exist
An Ethernet IP MTU of 1,500 describes the space available for an IP packet. The Ethernet header and frame check sequence sit outside that value. VLAN tags increase the required Ethernet frame capacity; do not subtract them again from an IP MTU unless the equipment's frame limit actually forces a smaller payload.
PPPoE uses six bytes for its session header and normally two bytes for the PPP protocol field. With a 1,500-byte Ethernet payload, that leaves 1,492 bytes for the subscriber IP packet. Larger PPPoE payloads require appropriate support throughout the access path.
At a LAC, PPP is carried into L2TP. The original access Ethernet and PPPoE headers are not normally carried inside an L2TPv2 PPP data packet. The transport instead carries outer IP, UDP, L2TP and the PPP representation. Budget the access and tunnel segments separately, then take the limiting result.
L2TPv2's header format includes optional fields. A minimum data header is six bytes, but length, sequencing and offset fields can increase it. Verify the negotiated and captured format rather than treating the minimum as universal.
A worked byte budget
Assume a tunnel underlay with a 1,500-byte IP MTU, outer IPv4 without options, an eight-byte L2TP data header including its length field, and a two-byte PPP protocol field without address/control bytes. There is no IPsec in this first calculation.
| Component | Bytes | Remaining tunnel budget |
|---|---|---|
| Underlay IP MTU | 1,500 | 1,500 |
| Outer IPv4 | 20 | 1,480 |
| UDP | 8 | 1,472 |
| Assumed L2TP header | 8 | 1,464 |
| Assumed PPP representation | 2 | 1,462 |
The tunnel allows a 1,462-byte subscriber IP packet under these assumptions. That is smaller than the 1,492-byte PPPoE access limit, so the tunnel controls the end-to-end budget.
For ordinary headers, the corresponding TCP MSS ceilings are:
Inner IPv4 TCP MSS: 1,462 - 20 - 20 = 1,422 bytes
Inner IPv6 TCP MSS: 1,462 - 40 - 20 = 1,402 bytes
MSS counts TCP data, not the complete packet. TCP options and any additional IP headers require appropriate sender accounting. These figures are worked examples, not configuration defaults.
Add IPsec using the actual encapsulation
IPsec overhead depends on transport versus tunnel mode, the algorithm, explicit IV, authentication tag, padding and whether UDP encapsulation is used. Tunnel mode adds another IP header. Avoid assuming that every protected L2TP packet has one fixed overhead.
For illustration, if the deployed IPsec format adds a maximum of 64 bytes beyond the unprotected stack above, the subscriber budget becomes 1,398 bytes. The ordinary IPv4 TCP MSS ceiling becomes 1,358 bytes. Use a measured or calculated maximum for your actual security association, including padding, rather than reusing that illustrative allowance.
A working small ping proves reachability at that size; it does not prove that a full-sized subscriber packet fits through the tunnel.
Recognise a packet-size black hole
Look for repeated retransmissions of similarly sized packets after successful small exchanges. A TLS handshake can expose the issue when a larger certificate response arrives. Uploads and downloads may behave differently because their paths or encapsulation differ.
Classic path-MTU discovery depends on feedback reaching the sender. For IPv4, an oversized packet with DF set needs an appropriate fragmentation-needed response. IPv6 uses ICMPv6 Packet Too Big. Filtering those messages, or failing to translate tunnel-related feedback into useful information for the original sender, can leave endpoints repeating packets that never arrive.
A tunnel can also hide the issue by fragmenting outer IPv4 packets. That may restore delivery while increasing processing and reassembly costs. Treat observed fragmentation as evidence to investigate, not proof that the MTU budget is healthy.
What MSS clamping fixes
TCP advertises MSS during connection establishment. A clamp reduces an excessive advertised value so the peer sends smaller TCP segments. It affects new handshakes; existing connections generally need to be reopened before a changed clamp is visible.
Netavo implements a configurable downstream TCP MSS clamp. Its configuration automatically derives MSS from the port MTU minus L2TP/IPsec outer overhead and the relevant inner headers. Check the effective setting against the real path, including optional IPsec, rather than assuming the physical port MTU describes the entire tunnel.
Direction matters: an MSS advertised by one endpoint limits data sent by its peer. Capture SYN and SYN-ACK packets on the relevant sides to confirm which advertisement changed. Do not assume a downstream clamp alone proves that both upload and download packet sizes are safe.
UDP has no TCP MSS option. QUIC therefore receives no benefit from rewriting a TCP handshake. Working path-MTU handling remains necessary. RFC 8899 describes Datagram Packetization Layer Path MTU Discovery, which uses transport or application feedback and probes to establish usable packet sizes. It can detect size black holes without depending solely on ICMP delivery. Endpoint support matters; the BNG cannot add this behaviour to an arbitrary application.
Diagnose in a repeatable sequence
- Pin down the failing path. Record subscriber, LAC, LNS, address family, destination and whether IPsec is active. Reproduce the same operation rather than testing unrelated websites.
- Inventory every MTU. Check the subscriber PPP limit, access frame capacity, tunnel underlay and any intermediate encapsulation. Calculate the limiting subscriber packet size.
- Probe a size range. Use explicit packet sizes and DF where applicable. Check whether the utility's size parameter means payload or total packet length. Test both directions where practical.
- Inspect feedback and captures. Look for oversized packets, fragmentation, repeated retransmissions and ICMP errors. A capture before segmentation offload may show packets larger than the wire actually carries, so interpret the capture point correctly.
- Verify the TCP clamp. Inspect fresh SYN exchanges and compare the effective MSS with the budget. Retest sustained uploads and downloads after opening new connections.
- Test UDP separately. Exercise QUIC or the affected datagram application and verify size adaptation or useful ICMP feedback. A successful TCP retest does not close a UDP incident.
Record the final MTU, overhead assumptions and observed boundary in the incident. If reducing packet size changes nothing, continue with loss, routing and application diagnosis rather than repeatedly lowering MSS.
Reproduce your access and tunnel stack with a Netavo evaluation, and consult the documentation for MTU and downstream MSS configuration.