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

[Kai Krakow]

Am Tue, 20 Sep 2016 05:42:01 -0700
schrieb Grant <emailgrant@×××××.com>:

> >> 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.