>>> The MTU on the client Machines generally needs to be lower then the
>>> MTU on the server, if the server is PPPoE based. So your server
>>> should be 1492, so the client PCs can be 1472 and they should be
>>> just fine.
>> I'm curious as to why the MTU used for the masqueraded hosts should be
>> lower. A 1492 MTU is 20 octets less than the 1492 that accommodates the
>> 8 extra octets beyond the standard Ethernet frame that PPPoE requires,
>> which would seem to be all that those hosts should need too.
>> Is it related to something about IP masquerading that I don't know about?
> Actually it was 1472 that someone suggested, but I am not sure why either.
Yes, I've already had my fingers whacked for that mistake.
Quote:> The way to test max mtu is to determine the largest ping data size that
> will pass without fragmenting (if your ping has that option) and then add
> 28 to get maximum mtu.
> From a masqueraded internal box I had no trouble doing:
> ping -c4 -M do -s 1464 www.dslreports.com
> Anything bigger and it would fragment over pppoe.
> ie, 1464 + 28 = 1492 max mtu for LAN.
Yes, a ping is an ICMP message in an IP datagram, and the datagram has
a 20 octet header with the rest being data payload. TCP is mostly over
IP and it has a 20 octet header too which makes 40 octets overhead,
so for a TCP/IP segment originating from a standard Ethernet the MSS
(Maximum Segment (data) Size) is the 1500 octet standard Ethernet
payload size minus 40, or 1460 octets.
PPPoE has a 6 octet header followed by 2 octet PPP protocol field and
then the PPP payload, including TCP/IP headers, but with no PPP frame
FCS (CRC). So the it can only carry up to 1452 octets of data. To make
that happen the MTU of the Ethernet must be no greater than 1492.
Why an extra 20 octets needs to be subtracted from the 1492 octets to
facilitate PPPoE is the real question. I don't disagree that 1472 would
"be just fine" but I don't see any need to use something other than the
maximum. Apparently something is going on that I don't understand, but
would certainly like to.
Quote:> I saw one theory that explained why 1454 would be optimum because once it
> got to the ATM it would be sending 30 full atm packets for every tcp
> packet instead of 31 with 1 partially empty. But I have not seen actual
> evidence of that. All actual tests seem to indicate that bigger is
> better, short of fragmenting. So maybe atm packets are split and
> assembled at a rate that makes a slight difference in number of atm
> packets insignificant.
I don't see how PPP over ATM relates to PPPoE at all.
Quote:> I did see an explaination about the Win Enternet software for my Efficient
> 5360 modem that said they determined that MSS 1454 was optimum, but I
> don't know how that relates to MTU. Their software indicated that it had
> connected with mtu 1480.
I don't know anything about that hardware.
Quote:> So the numbers thrown about can be confusing when you do not know if they
> are MTU, MSS, RWIN or whatever. In fact I saw one explaination of how to
> calculate optimum RWIN (which you do not have to worry about for Linux),
> and one of the variables was speed, but it did not mention what units for
> that speed.
Probably bits/second, aka bandwidth.
PPP-Q&A links, downloads: http://users3.ev1.net/~ckite/public_html/
/* The signal-to-noise ratio is too low in many [news] groups to make
* them good candidates for archiving.
* --- Mike Moraes, Answers to FAQs about Usenet */