editor
698
edits
MTU: Difference between revisions
m
clean up, typos fixed: 100Mb/s → 100Mbit/s, have have → have
(Add a section for documenting the differences between backhaul networks) |
m (clean up, typos fixed: 100Mb/s → 100Mbit/s, have have → have) |
||
|
In most cases links support 1,500 bytes, so there is not problem. However, where we know there is a specific issue there is another option, an option (C). It is a bit of a bodge, but works. We have added this as a user-settable feature on the line so you can contol if you want us to work-around the issue or not. This is mainly for where the link from us to you is restricted, typically to 1,492 bytes, for PPPoE.
It works by exploiting the fact that at the start of a TCP session each end tells the other the MTU it can handle (actually the MSS which is the TCP payload but one is derived from the other). When we
When do you get small links?
As there is no real way to tell if baby jumbo frames are supported on an [[Ethernet]], RFC4638 defines an extra option for PPPoE to negotiate this at the [[Ethernet]] level. Of course two ends could simply agree to handle slightly larger [[Ethernet]] frames by configuration as well. Sadly this is not always the same level of operation or the same equipment that does the MRU negotiation at the PPP level, and if that knows PPPoE is involved it will not negotiate more than 1,492 MRU as per RFC2516. So typically some configuration is needed.
The upshot of all this? It is possible to get BT FTTC (Fibre to the Cabinet) circuits (which use PPPoE) working on full 1,500 byte PPP by using modified pppd on the customer end, a suitable network card that will handle 1,508 byte frames at 10/
=What is my MTU?=
ping -n1 -f -l 1472 81.187.81.187
==Two quick examples
Checking if you really have 1500 MTU:
| |||