.jpg "Opportunities, Appliacation, Openings"){kind=small}
.jpg "Hand Job, Blow Job, Job Search, Monster Job"){kind=small}
.jpg "pusat resume, daftar kerja, cari kerja"){kind=small}
.jpg "Project Manager, SOftware Engineer, SAP Consultant"){kind=small}
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
