12,270
edits
MTU: Difference between revisions
m
→What is my MTU?
m (Use 'payload' in the same meaning as earlier in the page to avoid confusion) |
|||
| (20 intermediate revisions by 3 users not shown) | |||
|
<indicator name="Front">[[File:Menu-packet.svg|link=:Category:MTU|30px|Back up to the MTU Page]]</indicator>
This page will be about MTU, it is currently work in progress.
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
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.
For example:
[[File:Firebrick-1500MTU-ping.png|200px|thumb|a 1500 ping on FireBrick]]
On Linux:
ping -c1 -M do -s 1472 81.187.81.187
On OSX (Apple):
ping -c1 -D -s 1472 81.187.81.187▼
On Windows:
^^ That's the ping command to remember. The rest of this section is a bit of info about that command.
Which results in:
PING 81.187.81.187 (81.187.81.187) 1472('''1500''') bytes of data.
1480 bytes from 81.187.81.187: icmp_req=1 ttl=59 time=54.1 ms
--- 81.187.81.187 ping statistics ---
'''1 packets transmitted, 1 received''', 0% packet loss, time 0ms
rtt min/avg/max/mdev = 54.108/54.108/54.108/0.000 ms
The things to note are highlighted in bold
If 1500 bytes cannot pass, then a ping result will look like:
''' -s 1472''' When setting size in ping, the size is the payload size - not the full packet size. The full packet size is payload + ICMP header size (28 bytes). The option for payload size is -s.▼
PING 81.187.81.187 (81.187.81.187) 1472(1500) bytes of data.
From 81.187.81.187 icmp_seq=1 '''Frag needed and DF set''' (mtu = 1492)
--- 81.187.81.187 ping statistics ---
'''0 packets transmitted, 0 received''', +1 errors
▲ ping -c1 -D -s 1472 81.187.81.187
==Explanation of the ping options==
▲ ping -n1 -f -l 1472 81.187.81.187
'''-c1 / -n 1''' This is optional, it simply tells ping just to send a single ping
'''-M do / -f / -D''' The important option! This means don't fragment the ping packet - we don't want the ping split into multiple packets when testing MTU!
▲''' -s 1472 / -l 1472''' The payload size. When setting size in ping, the size is the payload size - not the full packet size. '''The full packet size is''' <syntaxhighlight inline> payload (1472) +
==Two quick examples==
rtt min/avg/max/mdev = 12.491/12.491/12.491/0.000 ms
So, here we ping with '''1472''' bytes, this is 1472 plus 20 bytes for the IP header and 8 bytes for the ICMP header is a '''1500''' byte MTU!
Checking if you have smaller than 1500 MTU:
time of writing (Dec 2014) TTW does not support an MTU of 1508, so users of PPPoE cannot achieve an MTU of more than 1492 bytes.
[Above is the official position. However, there are some experimental results which indicate one might be able to do better. Using a TG582n as the router running PPPoE
and configuring it to support baby jumbo frames:
:eth ifconfig intf=eth_WAN mtu=1508
and with PPPoE needing to send 1504 octets and receive 1508.
[[Category:MTU]]
| |||