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

It's better, because it eliminates the problem in one particular case.

However, it does not catch all cases; in particular, it does not catch
the case where the original of the cached route is deleted.  (This
*might* not be an issue, if I missed something in the invalidation code
and it does manage to invalidate the cached route.)

However, I am not at all sure there are no other cases, and clearing
the cache whenever the routing table is touched catches them all.  I
don't think the additional cache flushes are that high a price to pay
for the certainty that the problem won't recur.

Or, for that matter, the fix I sent in with the PR does almost as good
a job, recovering within at most one second from a bogus cached route
no matter how it happened.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B