Go CCIE Go!! - A Cisco Certified Internetwork Expert

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