MTU issues when using PPPoE

By Fenn Bailey


MTU (Maximum Transmission Unit) related issues (should) only occur when using PPPoE. Common symptoms of this is very slow performance, problems FTP'ing and some webpages just not coming up for no particular reason. The reason these issues occur is to do with an inherent flaw in the way PPPoE works as a protocol (and sadly, an essentially unfixable one).

To understand how to identify and fix these problems, it's pretty useful to understand how they work and what causes them. So we're going to have a look at some pretty dry technical MTU related stuff in the next few paragraphs.

Basically, the maximum size of an Ethernet frame is 1518 bytes. 18 of these bytes are used for addressing and other trickyness (frame-check sequence, etc). Hence, the largest IP datagram that can be transmitted over Ethernet is 1500 bytes.

Unfortunately, PPPoE consumes 8 more bytes of data for its own purposes, which leaves us with 1492 of usable space for actual data. Thankfully, TCP has a few tricks up it's sleeve to help with this sort of thing.

When a TCP connection is established, the two ends (say, your PC and a webserver) will typically decide on an MSS (Maximum Segment Size). Usually, this will be the MTU minus the overhead necessary. Hence, Ethernet MTU = 1500, TCP requires 40 bytes for its own addressing, which leaves us with 1460 byte segments for our TCP connection.

To clarify things, think of MTU as the maximum datagram size your hardware can transfer, and MSS as the maximum packet size any given TCP connection can transfer. A good rule of thumb is: MSS should always be smaller than MTU.

Now we can see why MSS starts to relate to PPPoE. The main problem experienced is that the two sides negotiate an MSS size based on their own MTU limitations. Now what happens if one of the connections BETWEEN you and the webserver can only handle 1400 byte packets? Nothing good - Basically, the packets get dropped and no data transfer happens.

So! TCP has some EXTRA trickyness called "MTU Path Discovery" which allows it to determine the best possible MTU for a given path, and hence, the best possible MSS for a given connection. A great idea in theory - Unfortunately, a lot of routers won't play the "MTU Path Discovery" game and this technique doesn't work very well in practice.

So where are we up to now? Does it mean that PPPoE will never really work and we are doomed to substandard performance for all time? No, it doesn't. There are a few tricks that allow us to fix this problem.

1) Make sure that all client machines that talk through a "non standard" MTU connection (PPPoE) have a low enough MTU that they wont fragment. This option can be quite annoying as it would involve some trial and error for your connection (1400 might be best, though you will notice a performance hit), and you will also need to amend the MTU of ALL machines behind a PPPoE connection. Eg: If you have a network of 10 PC's - You need to change all of their MTU's to the same size (or smaller) than the gateway. If you are using Microsoft Windows XP's built in based PPPoE client + gatewaying, then I believe this is your only option.

2) Use "Clamp-MSS". Clamp-MSS is an "ugly hack" (their words) in rp-pppoe (Roaring Penguin) and, recently, RASPPPoE on Windows that allows you to "clamp" the MSS to a specific size. Basically, it listens in on the MSS negotiation and then lies about the negotated result. The upshot is that you can make sure that negotated MSS's are always of a reasonable size and you don't have to worry about adjusting the MTU on all of the client machines.

Basic MTU troubleshooting for Windows

ADSL Troubleshooting



fenn_b [at] pacific.net.au