From: Joseph Brunner (joe@affirmedsystems.com)
Date: Mon Mar 31 2008 - 12:14:16 ART
The bottom line is the MTU is a HUGE design consideration, and a decision
must be made- either at the host level, or at the router level.
Regardless of whether you rely on PMTUD (foolish in a big company where
different groups that don't speak to each other admin different devices) or
force it down the hosts (better idea if that group will do allow it) don't
just let come to a break/fix level.
In small shops I always just adjust mss and set the ip mtu on client facing
lan interface, and tunnels.
Is it a security risk? No. is CDP ? No. But something are going to come up
again and again, and I was asking the original poster to make sure his
network supported the traffic if there was a case where he had to disable
them (think policy).
-Joe
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tony
Varriale
Sent: Monday, March 31, 2008 9:08 AM
To: ccielab@groupstudy.com
Subject: RE: Can "no ip unreachables" commmand break Citrix traffic?
I like your response.
In general, if you really think it's a security risk, take a few minutes to
think of why it's a bad idea overall to disable them. Don't just do what
some supposed expert thinks. Believe me, there are many more intelligent
people/people with real experience that think the opposite.
Also, think of forcing MTU everywhere as putting host entries in your hosts
file. Only do it if you really really need to. Just because that option is
there doesn't mean you should throw it around like a rag doll.
Tony
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Dale
Shaw
Sent: Monday, March 31, 2008 2:38 AM
To: Joseph Brunner
Cc: Matemane, Walter; ccielab@groupstudy.com
Subject: Re: Can "no ip unreachables" commmand break Citrix traffic?
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:55 ART