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
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