PPPoE MTU Calculator for Home Routers

Your home lab rack is built out. Your fiber ONT is connected and working. The switch is up and running. The router is configured. The cable is plugged in. You entered credentials for your PPPoE account. The link is engaged. The connection is established. Speed test runs at full bandwidth.

But some websites don’t work. Streaming services won’t stop buffering. Maybe even video calls disconnects. No, you’re not being hacked and yes, your DNS are working as intended. What’s happening? You’ve run into Maximum Transmission Unit limits.

Why Your Internet is Slow Even Though It Works

Don’t believe me? This is a very common problem and why so many people think their ISP sucks. ISPs aren’t the issue here. It’s math: header math.

A standard Ethernet frame carries 1500 bytes of payload. That’s the default. Then PPPoE encapsulates each packet with an additional eight bytes of overhead. It use two bytes for the protocol ID and six more bytes for the session header. Your effective MTU drop down to 1492. And if your router is still trying to pack 1500-byte chunks, it’ll try to cram them into undersized frames. You end up with dropped or fragmented packets. Connection stalls follow.

The page’s calculator do that math for you. It accounts for all layers of overhead and eliminates any guesswork.

This gets trickier once you bring VLANs into the equation. Some ISPs (many fiber ISPs) require you to tag their traffic with some set vlan id. That adds an additional four bytes to the frame on the wire. It doesn’t actualy shrink the IP MTU, but it expands the actual frame size. Those tagged packets might get dropped by switches/ONTs that don’t support slightly bigger frames, called baby jumbo frames. Check if your whole chain of equipment from the wall jack to your router NIC supports 1508-byte frames. If not, then you’ll have to drop the MTU to make up for it.

There’s also complication of tunnels. You may be running a VPN like IPsec or WireGuard over that PPPoE connection. That means you’re putting packets within packets. And each layer has a header. Eighty-plus bytes is not uncommon with IPsec NAT traversal. Your usable tunnel MTU could drop from a standard 1492 down to something like 1412. Because your TCP Maximum Segment Size hasn’t been lowered, the inner packets will be larger then the capacity of the tunnel. They’ll break into fragments, causing latency spikes for TCP connections and harming the performance of UDP-based ones.

The page’s reference table describes these losses in typical configurations. It clearly explains how much space encapsulation and encryption take away.

So, the thing to remember about all of this: What are you measuring? MTU is the largest packet size allowed for passage without fragmentation. And, MSS refers to the payload size that TCP permit within that packet. So, you want to clamp the MSS so as to fit everything (including the TCP and IP header) within the MTU. It’s a tiny tweak, but it counts. Get it wrong, and when your router starts trying to send packets back and forth, it will negotiate smaller packet sizes over and over. This wastes time, causes delays, and puts more load on CPU.

Plug in the numbers, but don’t do it blindly. Consider where you’re going. Is it a standard DSL line? Use 1492. Do you have fiber with VLAN tagging? Your equipment may support baby jumbo frames. Are you running a VPN? Subtract another forty or eighty bytes. That’s why we built the calculator: so you can determine where you get enough speed without losing too much reliability.

So many ping tests, so little time. Avoid the frustration of a mismatch in expectations. When a smooth connection is made, it’s like magic; it dissapears. There are no stalled downloads, no buffered streams, no dropped calls. It just works. You’re not battling with overhead and headers anymore. You should of got it right the first time and now you can get back to doing whatever it is you do with your life. Math? Just the cost of entry.