David Young <dyoung@pobox.com> writes:

> Can you use ifwatchd to add/remove routes for interfaces whose carrier
> state changes?

Probably.  I was just wondering if they should go away by themselves
without having to run ifwatchd.  Quagga is going to grow code to
remove and reinstall these routes anyway, since there are and will
always be systems that don't do this.

> Hopefully Quagga will cope if you RTM_CHANGE a route
> that comes from, say, OSPF.

If not it's a bug and should be easy enough fix.

That points out that the kernel could remove another route for the
same prefix on reenabling, just like ifwatchd, and either issue
RTM_DELETE first or RTM_CHANGE.

> FWIW, I have improved [*] the RADIX_MPATH patches from KAME.net.
> RADIX_MPATH most famously lets us store more than one nexthop for a
> single destination prefix; it chooses the nexthop to use by hashing
> the source/destination pair; for better or worse, the forwarding
> decision is cached "in the usual way."  I have added a hook to
> RADIX_MPATH for "weighting" routes [**], made it possible to keep both
> RTF_GATEWAY/RTF_LLINFO information (indirect/direct route) for a single
> destination, and added a "wireless" forwarding heuristic [***].

With that, one could add priority (vs weight, where priority has no
random selection), and change priority of connected routes to above
regular when link state is good and below when bad.



-- 
        Greg Troxel <gdt@ir.bbn.com>