>> >> A while back I was having networking issues. I eventually tried >> >> drastically lowering the MTU of all the systems onsite and the >> >> issues disappeared. I always thought the issue was due to the MTU >> >> on our modem/router. Today I read that AT&T DSL requires a 1492 >> >> MTU so I increased the MTU of our systems up to 1492 and haven't >> >> had any issues. Do certain ISPs require you to change the MTU of >> >> your entire network, or is this likely due to our AT&T >> >> modem/router itself? >> > >> > Are you using tunnels or a firewall that blocks related "icmp >> > fragmentation needed" packets? >> >> >> I have this in shorewall/rules: >> >> ACCEPT all all icmp - - - 10/sec:20 >> >> Which I believe accepts all icmp packets but throttles them to 10/sec >> to avoid being flooded. Is that OK? > > You should probably add a rule before that to let pass all icmp traffic > related to active connections. I think this can be done with conntrack > or "-m related". I didn't use iptables in a long time so I cannot > exactly help you with instructions. > > On the other hand, you're probably interested in only limiting icmp > echo-request. So you may want to stick with that and not limit icmp > altogether. ICMP is a very important part of a functional ip stack, you > should not play with it before fully understanding the consequences. > > I don't think it makes too much sense to bother about icmp. In case, > icmp is dropped first usually - and limiting it on your interfaces > doesn't help at all against flooding (because your provider still > delivers it to your router through your downstream, it's too late to > do limiting at this stage), it just saves you from maybe replying to all > those packets (and thus saves upstream bandwidth which on standard > asymmetric lines is ridiculous small compared to the massive > downstreams). > > But again: You really (!) should not limit icmp traffic with such a > general rule but instead limit only specific types of icmp (like > echo-request), and maybe even block other types completely on the > external interface (redirect, source quench, a few others). > > Most others are important for announcing problems on the packet route - > like smaller MTU (path mtu discovery), unreachable destinations etc. > Unselectively blocking or limiting them will result in a lot of > timeouts and intermittent connection freezes which are hard to > understand.
I removed the limiting yesterday so that I'm simply allowing icmp packets: ACCEPT all all icmp It didn't help with my TCP Queuing problem but I'll leave it as-is because I'm sure you're right about the problems it could cause. >> > Please also try to find out if you're experiencing packet loss. If >> > fragmented packets cannot be reassembled due to some packets lost, >> > you will probably find connections freezing or going really slow. >> >> I will watch the output of ifconfig today to see if there are any RX >> or TX errors. > > I almost expect you won't see any numbers there but instead see the > counter of your limit rule rise during periods where you see the > problems. TX and RX errors only catch layer 1 or layer 2 losses, you > are probably experiencing packet loss at or above layer 3 (and I guess > due to your limit rule). > > Maybe run a ping to a destination which you are having problems with, > then reproduce the problem (with the network idle otherwise). You should > see ping packets dropped only then. > > You can also ping with increasing packet sizes (see ping --help) and > see when the packet becomes too big for path MTU. But instead lowering > your MTU then, you should allow icmp-fragmentation-needed come through > reliably. Lowering MTU only makes sense to stop overly fragmentation in > the first place and optimize for a specific packet path (like traffic > through one or multiple VPN tunnels) where fragmentation would > otherwise increase latency a lot, or where icmp-frag-needed does not > correctly work. I'll try pinging today once the issue pops up. - Grant
