My original problem was that inappropriate routes kept appearing in my
routing tables. The problematic routing entry was taking the form of:
192.168.201.222 192.168.200.2 UGHD 0 9 tu0
Many thanks to the following for helping me solve "The Mystery of the Rouge
Routes"!:
Whitney Latta
J. Dean Brock
Arrigo Triulzi
Dejan Muhamedagic
Dejan in particular hit the nail on the head with the following reply,
which really helped me fix the problem:
"The 'D' flag (from UGHD) means that the route was established through an
ICMP redirect. This happens when the router which is receiving packet for
a particular destination routes that packet through the same interface on
which it was received and, therefore, concludes that there must be a better
route. This is the correct behaviour and it helps when one doesn't want to
bother in establishing all the necessary routes but just to set the default
one and all the other routes will be established automagicaly. Now, the
real question is why does your default router (200.2) becomes a better
route to the network 201.0 than the router 200.200. You should, perhaps,
check if your routes are really what they should be. BTW, RIP and other
routing protocols are not in this game."
Approaching things from this angle (i.e. assuming ICMP redirects are a good
thing and make it work) I eventually came to realize that the problem was
with my 192.168.200.2 gateway, which had IP forwarding DISABLED. The reason
for this was that the gateway is my firewall, and I’ve been told to avoid
enabling IP forwarding for your firewall.
What is interesting is that I’ve now been able to remove several of my
static routes, greatly simplifying my routing table. I’m now seeing a lot
of dynamic routes appear, but this time they work properly. Invariably the
dynamic routes are my tunnel client users, and it wants to route them to
the tunnel server, which is 192.168.200.200. Apparently, every once in a
while, it gets the bright idea to route them through my gateway/firewall
first. This is an extra hop so it would be interesting to see why it
occasionally thinks this is a good idea.
A couple of other nuggets:
>From Whitney, on the idea of disabling the Digital UNIX boxes from doing
anything with ICMP redirects:
Disabling ICMP redirects is not a trivial thing. Depending on the OS
version, you can patch "icmp_rejectcodemask" on the running kernel (defined
as "0" in ip_icmp.c). The values are defined in
/usr/include/netinet/ip_icmp.h. There may be a better way to do this.
>From Arrigo, on how to find out which machine is sending the ICMP redirects:
Now, how do you spot the rogue ICMP broadcaster? Well, if you have a Linux
box run icmpinfo, a pretty program which logs all ICMP messages including
the origin and the contents.
The other possibility is a well writting tcpdump command line which will
screen the net for ICMP packets only.
Conclusion:
For the time being I’ve enabled IP forwarding and everything is working
perfectly. I plan on trying to find out which machine is sending the ICMP
redirects - I do have a Linux box and might give icmpinfo a try. Ultimately
I’d like to disable IP forwarding again and either have DU ignore the
redirects or find the machine sending ‘em and squash them.
cknorr_at_hops.com
305-827-8600 ext. 238 (voice)
305-827-0999 (fax)
Received on Wed Sep 23 1998 - 22:24:04 NZST