Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>>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
>>
>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms
>
> Look again! You're just looking at the _PING_ packets, not the ICMP/IP
> packets actually going over the interface! You'll need to run
> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
> there's two IP packets actually going over the interface, due to the
> ping-packet being too large and being fragmented.
>
> Start the tcpdump in another (x)term before running the "ping" ...
>
> If you use '-M do', you should get the
>
>     "Frag needed and DF set (mtu = NNNN)"


I switched to '-M do' and found that 1464 is the highest size I can
ping without the "Frag needed" error.  This means I should add 28 to
that and set my MTU to 1492 across the network?

- Grant


> error from ping. "-M dont" explicitly allows fragmentation, which you
> can then see with tcpdump. E.g. a with my MTU of 1492, a
>
> ==== ping -n -c 1 -M dont -s 9999 192.168.178.1 ====
> PING 192.168.178.1 (192.168.178.1) 9999(10027) bytes of data.
> 10007 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.79 ms
>
> --- 192.168.178.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 2.795/2.795/2.795/0.000 ms
> ====
>
> results in
>
> ==== tcpdump -n -i eth0 icmp ====
> 17:40:11.901583 IP 192.168.178.11 > 192.168.178.1: ICMP echo request, id 11363, seq 1, length 1472
> 17:40:11.901597 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901599 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901600 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901602 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901603 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901605 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.903762 IP 192.168.178.1 > 192.168.178.11: ICMP echo reply, id 11363, seq 1, length 1480
> 17:40:11.903779 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.903984 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.903997 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904227 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904241 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904338 IP 192.168.178.1 > 192.168.178.11: icmp
> ====
>
> Yes, that is just the _one_ ping packet.
>
> Read up on the links I gave you about fragmentation and IP(v4) in
> general a bit ;) It's much better described there than I could ATM.
>
> Which does not mean not to ask for stuff that's unclear.
>
> HTH,
> -dnh, who seems to have a knack for translating "techese" to normal
>     language ... Actually, I guess fragmentation can be explained
>     quite nicely by comparing to real-life packets ;) You'd get an
>     basically unlimited supply of courier boys, but you can get just
>     so many incoming and outgoing through the doors ;)
>
>     *grepping out the appropriate sig for that*