(usagi-users 03380) Re: How to avoid automatic route creation?

I'll wade in here a bit , given that I've been looking at the routing 
tables over the last few weeks.  I'm confident the gurus will correct my 
tentative understanding.

What is added is not really a route, but a destination.  This is 
generally per spec, as the output path involves looking in the 
destination cache and then the looking for routes.  It is assumed, 
usually correctly, that the destination cache is from a very recent 
transaction, and therefore likely to be the correct "route" back to the 
node.  The destinations have limited lifetimes and will go away unless 
refreshed peridically by traffic.  If a node moves due to network 
reconfiguration, then the unreachability detection will figure out that 
the link-layer address is no longer valid and the destination will be 
removed. 

 Destination entries are also useful for managing flows within the 
traffic stream, and as such you really don't want to stop this behavior. 
This seems to be the primary reason to cache the outbound destinations, 
so that the data from a particular flow can follow the same route. 
However, since this is Linux, you can always use the source to do 
whatever you want.  AFAIK, there is no config variable to prevent the 
addition of destinations to the table.

The implementation of the routing table(s) makes little distinction 
between routes and destinations, the discriminating information being 
carried in a few flags in the common data structures.  route is probably 
not as aware of the subtleties of the combined routing/destination 
database as is ip, which seems to have been written and maintained much 
more closely with the kernel implementation.  Thus ip -6 route shows 
only true routes, while the route program sees routes and destination 
and doesn't know the difference.  Or perhaps it's a difference in the 
switches used.

Thgen again, there are clone routes that get created, so that the parent 
route can be manged while not messing up a flow that is in progress. 
 Perhaps this is what you are seeing.  No that I think about it, I think 
this is what gets created on the outbound path.

As for the redirects - the RFC 2461 says that a router "SHOULD" send 
them.  In the general case, you want them to ensure that the router only 
has to deal with traffic from one link to another and to minimize 
bandwidth useage.  If the route taken is important, then IPV6 proides 
for source routing, which can override the general routing table state. 
 There is no required configuration variable for disabling redirects. 
 Agains, since the source is available, it is always possible to hack 
the code to do your bidding.

There are certain events that flush the routes from the caches, and 
perhaps these could be used to remove the destinations, but I'm not sure 
that works.  

It is also possible that the lookup of routes/destinations fails to take 
into account the entry hierarchy, in which case there may be a bug in 
the code.  I have seen cases where the route entry changes, but it takes 
some time for the clones to age out and get recreated with the updated 
information.  One thing to keep in mind is that entries in the table 
which have expired and been released go onto a garbage collection list. 
 The GC only runs every 30 seconds, so anything that happens under that 
time may work with stale data that is on its way out, but not yet 
removed.  I've seen that with hoplimit updates, before a fix was put in 
to not take the hoplimit from the route but force it to come from the 
interface.  Some of the route prefix lifetime tests from TAHI fail for 
that reason, but work just fine when the test time is lengthened to 
allow the CG to run.

These observations apply to 2.6.10 with Usagi 20050131 and MIPV6 mooshed 
in, so the strict community code may have addressed some of these issues 
already.

Mark Huth


Ignacy Gawedzki wrote:

>Hi,
>
>I'm working on a routing daemon for ad hoc networks which performs routing
>table management by itself.  Unfortunately the kernel seems to interfere with
>the daemon at times and routing becomes a mess.
>
>When some traffic goes to a 1-hop neighbor (i.e. a host that has a direct
>route without any gateway), the kernel adds an additional route (visible using
>route -A inet6 but not ip -6 route) for that destination with the destination
>itself as the gateway.  If the route changes from direct to indirect (the
>destination is farther away and now we want another node to relay the
>paquets), it seems that the old additional route is preferred, which is
>clearly not wanted.
>
>Does anybody have any idea how such automatic addition could be prevented?
>
>Another point: is there a way to prevent routers from sending redirects (I
>actually use accept_redirect = 0 which make nodes ignore them, but they are
>still generated).
>
>Thanks.
>
>  
>