215
edits
MTU: Difference between revisions
→Two quick examples:
|
The simple answer is 1,500 bytes. But it is more complex. The internet is actually a combination of routers and links. Each router has links to other routers. Your packets go from one place to another by being passed along from one router to another over these links.
One of the main types of link is [[Ethernet]] which is used for Local Area Networks (LAN). You have probably encountered a LAN as they are used in offices and homes, and connect things together. You probably use [[Ethernet]] to connect your broadband router to your computers in your house. [[Ethernet]] allows 1,500 byte packets to be carried. Internet providers use much faster links such as gigabit and 10 gigabit and these often allow bigger packets up to around 9,000 bytes. Some links on the internet are set up specially for certain traffic and have links that support packet sizes like 1,548 bytes.
The links, like [[Ethernet]], limit the size of packets that can be sent. The size of packet that can get from one place to another without any difficulties depends on the smallest link in the chain. On the internet as a whole this is generally 1,500 bytes. But this depends where the packet goes and what links are used. The smallest link allowed is 576 bytes which used to be common for modems on dialup-internet.
The maximum size of packet you can send on a link is called the MTU (Maximum Transmission Unit). The maximum size you can receive is the MRU (Maximum Receive Unit). The terms MRU and MTU often get used interchangeably for obvious reasons.
*(A) Don't send the packet and send an error message back saying it could not be sent
*(B) Break the packet up in to smaller bits (called fragments) which will fit, and send these on to the next router.
The choice depends on the packet. For [[IPv6]] packets you have to take option (A) and send an error. For IPv4 packets the packet has a flag called DF (Don't Fragment). If that is set you have to take option (A) and send an error. If not, then you take option (B) and fragment the packet.
If an error is sent back then the sending computer can try again sending smaller packets this time. If the packet is broken in to fragments then they still arrive at the destination and can be put back together by the receiving end. Either way the data gets through.
The other main example is dialup and broadband links. In practice a broadband link works much like a dialup line as it uses a protocol called PPP (Point to Point Protocol). Part of this is each end telling the other its MRU. I.e. how big a packet it can receive. There are a number of reasons a router might decide to say it cannot handle the full 1,500 bytes:-
*The router could be using PPPoE (PPP over [[Ethernet]]) bridging which requires an extra 8 byte header for PPP and then sends the packet over 1,500 byte [[Ethernet]], so the packets sent in the PPP layer can be at most 1,492 bytes.
*Some part of the link could require the use of a smaller MTU, typically because PPPoE is being used within a back-haul network (e.g. Be lines), so the router has to be set to use 1,492.
*The router could simply have a default of 1,492 as PPPoE is common in many countries as the standard way to connect broadband lines. In the UK we usually use PPPoA (PPP over ATM) which allows the full 1,500 bytes.
=Fragments are bad=
Fragments are bad anyway, which is why [[IPv6]] insists you always take option (A) and send an error message. Fragments create extra overhead as each packet has headers that have to be copied in to each fragment. They also work badly when a link is congested as dropping any fragment in a packet means the whole packet is lost. They also take up CPU time creating the fragments and putting them back together. All in all it is better if the sending end creates the smaller packets in the first place. This means Path MTU Discovery being used and the error message not being blocked! Fortunately [[IPv6]] mandates this, so the next generation of internet protocol should not have the same issues.
=PPPoE problems (technical)=
One of the main causes of a reduced MTU is PPPoE (PPP over [[Ethernet]]). This is because [[Ethernet]] allows 1,500 byte payloads, ideal for an IP packet, but PPPoE has a header which takes a total of 8 bytes. This would make 1,508 bytes with a full 1,500 byte IP packet.
Unfortunately the specifications are not that helpful here. RFC1661 defines PPP and states If smaller packets are requested, an implementation MUST still be able to receive the full 1,500 octet information field. RFC2516 defines PPPoE The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1,492. But they are not incompatible statements - negotiating 1,492 does not mean you don't have to accept 1,500 byte packets (as per RFC1661), but you can't send on if PPPoE bridging, for example, so logically you would have to fragment the IP packet. Most routers do not do that! This is one of the reasons we get problems with MTU being smaller than 1,500 bytes.
There are also ways to do over sized PPPoE using baby jumbo frames on [[Ethernet]]. The [[Ethernet]] specification still says 1,500 bytes maximum even for gigabit speeds, but it common for gigabit equipment to support jumbo frames - i.e. larger [[Ethernet]] packets typically up to around 9,000 bytes. This is more than you need to do PPPoE with 1,500 bytes - you only need 1,508. However there are other wrapping and tunnelling cases where just a bit more is useful. Baby jumbo support normally means a bit more than the usual 1,500.
As there is no real way to tell if baby jumbo frames are supported on an [[Ethernet]], RFC4638 defines an extra option 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/100Mb/s. We have done this! (Thanks to TonyHoyle and Simon, customers on irc, for tweaking pppd and testing this for us). The new FireBrick does, of course, support PPPoE with baby jumbo frames to handle 1,500 byte MTU and even bonds multiple lines. Using the right modem (and the DLINK 320B in bridge mode do this) you can negotiate and use 1508 bytes over ADSL as well.
% ping -c1 -M do -s 1472 81.187.81.187
PING 81.187.81.187 (81.187.81.187) 1472''(1500)'' bytes of data.
'''1480 bytes from 81.
--- 81.187.81.187 ping statistics ---
1 packets transmitted, 1 received, 0% [[Packet Loss|packet loss]], time 0ms
That error says "Frag needed and DF set (mtu = 1492)". So, with an MTU of 1492 we would want a payload of 1464 (1464+28=1492):
% ping -c1 -M do -s 1464 81.187.
PING 81.187.
'''1472 bytes from 81.187.
--- 81.187.81.187 ping statistics ---
1 packets transmitted, 1 received, 0% [[Packet Loss|packet loss]], time 0ms
| |||