>>> MTU is per network interface but you really don't want to end up having
>>> your router fragment every IP packet because systems on your subnet are
>>> using a larger MTU.
>>>
>>> Todd
>>
>>That makes sense. So in my case, I'm thinking 1492 MTU on every
>>interface in the network.
>>
>>So I'm sure I understand, should everyone with a DSL connection set an
>>MTU of 1492 (or potentially lower) on all of their network interfaces
>>to avoid packet fragmentation?
>
> That depends on your traffic flow. But, then again, 8 bytes out of
> 1500 means that you're "losing" just 0.533% of the maximum payload and
> fragmenting can mean you have to send/recv 2 Frames for each 1500 Byte
> packet you see locally.
>
>
> I've just tested that (with the MTU set at 1492, so with the ping
> overhead of 28 bytes, that leaves 1464 ping-payload without fragmenting)
> ("ping -M do" disallows, "-M dont" allows fragmenting).
>
>
> $ ping -n -c 1 -M do -s 1465 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
> From 192.168.178.11 icmp_seq=1 Frag needed and DF set (mtu = 1492)
>
> --- www.dslreports.com ping statistics ---
> 0 packets transmitted, 0 received, +1 errors
>
> ==== corresponding tcpdump -n -i eth0 icmp ====
> [nothing]
> ====
>
>
> Ok, go down a byte:
>
>
> $ ping -n -c 1 -M do -s 1464 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1464(1492) bytes of data.
> 1472 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=136 ms
>
> --- www.dslreports.com ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 136.638/136.638/136.638/0.000 ms
>
> ==== corresponding tcpdump -n -i eth0 icmp ====
> 15:48:39.587143 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3656,
> seq 1, length 1472
> 15:48:39.723751 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3656,
> seq 1, length 1472
> ====
>
>
> One packet sent and received for 1492 bytes packet size / 1464 bytes payload.
>
>
> $ ping -n -c 1 -M dont -s 1465 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
> 1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms
>
> --- www.dslreports.com ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms
>
> ==== corresponding tcpdump -n -i eth0 icmp ====
> 15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595,
> seq 1, length 1472
> 15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
> 15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595,
> seq 1, length 1472
> 15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp
> ====
>
>
> Two packets sent and received for 1493 bytes packet size / 1465 bytes
> ping-payload.
>
> Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
> yourself to see, that you'll send/recv 2 packets for each ping-packet
> (and 1472 bytes is the ping-payload that just fits into the standard
> 1500 bytes MTU).
Strangely, I'm able to ping with that command even with a very high -s value:
$ ping -c 4 -M dont -s 9999 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data.
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
time=331 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
time=329 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
time=329 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
time=329 ms
--- www.dslreports.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms
- Grant
