From: Dale Shaw (dale.shaw@gmail.com)
Date: Mon Mar 31 2008 - 04:38:09 ART
Hi all,
On Mon, Mar 31, 2008 at 6:19 PM, Joseph Brunner <joe@affirmedsystems.com> wrote:
> I suspect your issue was MTU. The unreachables were reporting fragmentation
> needed...
Yep, disabling ICMP unreachables can break TCP's Path MTU Discovery
(PMTU-D) function. Like Joe, I suspect that's what was happening here
-- the router needed to fragment a HTTP (tcp/80) or ICA (tcp/1494?)
packet, but the "Don't Fragment" (DF) bit was set in the TCP header.
Normally a router will generate a "fragment needed but DF bit set"
ICMP unreachable (type 3, code 4 -- see
http://www.iana.org/assignments/icmp-parameters), which the sender
will respond to. However, with "no ip unreachables" configured, the
router never generates this message, the sending host never knows it
needs to change its behaviour, and things generally go to mud
(timeouts, app lock-ups etc.)
> A better approach is to disable unreachables, as they are considered a
> security risk... and to enable "ip tcp mss-adjust 1380" on the client facing
> ce
> Interfaces, and limit the "ip mtu 1412"
Are unreachables really considered a security risk? If they were, are
they still? I personally consider some ICMP types, unreachables
included, a key part of a well-functioning network. Maybe you'd
consider restricting unreachables in certain parts of your network, or
in certain directions, or (if you can) limit the specific sub-codes,
but disable them completely? Not on my network - at least not in the
soft gooey centre.
TCP MSS adjustment, while quite clever, obviously only affect
TCP-based protocols. Any non-TCP transports that have a big enough
payload to exceed the interface MTU might need ICMP unreachables to
work at all (I can't think of a good example at the moment).
BTW, slight correction: the command is "ip tcp adjust-mss <value>"
> You want to force the clients to use smaller mtu earlier on, to avoid
> "dumbbell" mtu issues as they route through the cloud.
I agree with this -- sometimes it's just less torture to drop the MTU
on individual hosts. You'll find most VPN clients (Cisco's included)
automagically drop the client's MTU prior to establishing a
connection. Having said all that, I don't know why the OP is having
MTU troubles with the configuration shown - there doesn't seem to be
anything configured on those interfaces that would introduce overhead
typically associated with PMTU-D problems (IPSec, PPPoE etc.). Would
probably need to see a more complete config.
> -Joe
cheers,
Dale
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:54 ART