On Wed, Nov 13, 2002 at 09:28:19AM -0500, Greg Troxel wrote:
> Perhaps I am being too glib here, but checks for more/less specific
> routes sound overly complicated (and probably hard to get right) for
> fairly little benefit.  The current scheme does:
> 
>   A route is looked up for a host, and cached for later reuse for the
>   same host.
> 
> Such a scheme is correct if every time a cached route is used, the
> same route would have been found by a new search.  Clearing the cached
> route every time it is used is safe but inefficient (for back to back
> packets with huge table, which is presumably the point).
> 
> With this definition of correctness, every time the routing table or
> anything else is changed in such a way that changes which route would
> be found for the current cached route, the cached route must be
> cleared or updated.  The easy and safe solution is to clear the cached
> route _every time_ the routing table is changed (which includes
> interface up/down due to the network route for the interface), which
> surely includes every time that it needs to be cleared.
> Routing table changes are expensive enough compared to route lookups
> that this doesn't seem like a big efficiency hit.
> <snip>

It is 'easy and safe' to clear the cache every time the table
changes, but if there is a more efficient way to handle this without
adding a bunch of complexity, still maintaining correctness, then...?

<flame_bait>

No one has refuted my idea of clearing the cache when a more specific route
(longer mask length) than the cached route is added to the table.  This does
a better job of maintaining the cache when possible and adds a small amount
of code.

</flame_bait>

I agree that it is better to cheapen the table lookup.  Someone can do that.
However, this fix is simple and addresses the current brokenness of the cache.

Nick