| 1 |
On Tuesday 20 Sep 2016 19:38:02 David Haller wrote: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
> On Tue, 20 Sep 2016, Grant wrote: |
| 5 |
> >>>Strangely, I'm able to ping with that command even with a very high -s |
| 6 |
> >>>value: |
| 7 |
> >>> |
| 8 |
> >>>$ ping -c 4 -M dont -s 9999 www.dslreports.com |
| 9 |
> >>>PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data. |
| 10 |
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54 |
| 11 |
> >>>time=331 ms |
| 12 |
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54 |
| 13 |
> >>>time=329 ms |
| 14 |
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54 |
| 15 |
> >>>time=329 ms |
| 16 |
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54 |
| 17 |
> >>>time=329 ms |
| 18 |
> >>> |
| 19 |
> >>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms |
| 20 |
> >>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms |
| 21 |
> >>> |
| 22 |
> >> Look again! You're just looking at the _PING_ packets, not the ICMP/IP |
| 23 |
> >> packets actually going over the interface! You'll need to run |
| 24 |
> >> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but |
| 25 |
> >> there's two IP packets actually going over the interface, due to the |
| 26 |
> >> ping-packet being too large and being fragmented. |
| 27 |
> >> |
| 28 |
> >> Start the tcpdump in another (x)term before running the "ping" ... |
| 29 |
> >> |
| 30 |
> >> If you use '-M do', you should get the |
| 31 |
> >> |
| 32 |
> >> "Frag needed and DF set (mtu = NNNN)" |
| 33 |
> > |
| 34 |
> >I switched to '-M do' and found that 1464 is the highest size I can |
| 35 |
> >ping without the "Frag needed" error. This means I should add 28 to |
| 36 |
> >that |
| 37 |
> |
| 38 |
> The overhead of 28 bytes is just specific to ping. |
| 39 |
> |
| 40 |
> It means that your upstream has a MTU of 1492 bytes. And it depends on |
| 41 |
> your local needs if setting this MTU network-wide is the best course. |
| 42 |
> I think I and others wrote enough for you to decide. |
| 43 |
> |
| 44 |
> >and set my MTU to 1492 across the network? |
| 45 |
> |
| 46 |
> Probably yes. I'd even say: unless you know otherwise for your local |
| 47 |
> needs. It's a very small "pay" (-0.5% max throughput) locally for a |
| 48 |
> potentially much bigger gain towards the 'net side, esp. when |
| 49 |
> factoring in latency ... And BTW: changing the MTU is easy, why not |
| 50 |
> start with one system? Even temporarily just using ifconfig/ip |
| 51 |
> commandline (don't forget to set the default-route if you "down" the |
| 52 |
> connection: 'route add default gw $GW_IP' ) and running some |
| 53 |
> tests/benchmarks. |
| 54 |
> |
| 55 |
> HTH, |
| 56 |
> -dnh |
| 57 |
|
| 58 |
Leaving your MTU at the default ethernet size of 1500 on your PC/server should |
| 59 |
not cause a problem for most day to day operations, because modern end-point |
| 60 |
OS and network devices use Path MTU Detection. Problems will arise when you |
| 61 |
come across a misconfigured router/firewall/server (internet black hole) which |
| 62 |
drops ICMP Fragmentation Needed (Type 3, Code 4) packets and won't adjust its |
| 63 |
MTU to make sure you can receive packets of the appropriate size. |
| 64 |
|
| 65 |
I have no idea if PMTUD is in any way relevant to the TCP queue spikes you |
| 66 |
have observed, but they are caused by TCP buffers overflowing. Some detective |
| 67 |
work at the time these overflows take place would show what the server is doing |
| 68 |
at the time. |
| 69 |
-- |
| 70 |
Regards, |
| 71 |
Mick |
Archives