Am Tue, 20 Sep 2016 05:42:01 -0700 schrieb Grant <[email protected]>:
> >> 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. http://www.nthelp.com/icmp.html > > 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. -- Regards, Kai Replies to list-only preferred.
