Darren Reed <darrenr@reed.wattle.id.au> writes:

> In contrast to early behaviour of route, it has (for some time, most
> likely) not flushed all host routes when given a "route flush".
> Consequently, if you want to flush all of your host routes on the local
> lan which have link-layer information associated with them then you need
> to do it manually, per entry.  This can be a PITA, especially if you
> want to delete a route to an unresolved IP address because you've moved
> your box from one lan to the other, it reboots and creates a route stub.
> 
> To maintain backward compatibility, I'd suggest that traditional behaviour
> (i.e. delete all routes except those which belong to an interface itself)
> through using another option such as "realflush" or "empty".  Comments ?

Its not clear to me that backward compatibility is that important here.
Basically its only important if you were counting on the weird behavoir
of things still routing to an address even if the cloning route that
produced them is gone.  Since these addresses only represent a cache
(right?) I'm not sure that counting on the old behavoir wasn't destined
to lose.

The only problem I see with backward compat is with permanent arp
entries.  I know that proxy arp entries have a bit twiddled so that they
are never used for routing.  You should check for this bit-twiddling and
not flush `routes' of that type (because they aren't routes).  I don't
know what to do for permanent non-proxy arp entries.  I think it makes
sense to flush these, but in this case you might run into a backward
compat issue becuase the user could count on them not going away
arbitrarily.  Also, I'm not real familiar with non-proxy permanent arp
entries.  I don't know if they are using the bit-twiddle hack.

Chris.