1 |
On Tuesday 20 Sep 2016 12:57:00 Grant wrote: |
2 |
> > Leaving your MTU at the default ethernet size of 1500 on your PC/server |
3 |
> > should not cause a problem for most day to day operations, because modern |
4 |
> > end-point OS and network devices use Path MTU Detection. Problems will |
5 |
> > arise when you come across a misconfigured router/firewall/server |
6 |
> > (internet black hole) which drops ICMP Fragmentation Needed (Type 3, |
7 |
> > Code 4) packets and won't adjust its MTU to make sure you can receive |
8 |
> > packets of the appropriate size. |
9 |
> |
10 |
> And I believe that's exactly what I have as far as my AT&T |
11 |
> modem/router which seems to drop all icmp packets. I think that's why |
12 |
> it's important for me to set an MTU for my network which is not |
13 |
> greater than the MTU of the modem/router which appears to be 1492. |
14 |
> |
15 |
> > I have no idea if PMTUD is in any way relevant to the TCP queue spikes you |
16 |
> > have observed, but they are caused by TCP buffers overflowing. Some |
17 |
> > detective work at the time these overflows take place would show what the |
18 |
> > server is doing at the time. |
19 |
> |
20 |
> Any idea which tool to use? I could start keeping an eye on output |
21 |
> when things are good and then again when things are bad so I can |
22 |
> compare the two states. |
23 |
> |
24 |
> - Grant |
25 |
|
26 |
On the server you could start by using iftop, iptraf-ng, netstat to get an |
27 |
idea of connections and bandwidth consumed. Use lsof, syslog and webserver |
28 |
logs to see what's happening at an application level. |
29 |
|
30 |
You can also increase the firewall verbosity briefly, to see if anything strange |
31 |
is happening with packets being processed there. |
32 |
-- |
33 |
Regards, |
34 |
Mick |