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

[Grant]

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