[Xorp-hackers] Adding static routes with unresolved next-hop router

[Pavlin Radoslavov]

> >I believe that both mechanisms can be implemented within
> >StaticRoutes, but the final decision which one to use would be left
> >to the netadmin.
> >
> >For example, if a network interfaces goes down and if the neadmin
> >does NOT want to use the RIP routes for the same destination, then
> >when configuring StaticRoutes, all he needs to do is to add the same
> >route twice, but with different metric. E.g, the first route with
> >the preferred metric will use the desired network interface. The
> >second route with the less preferred metric will use a dummy
> >/dev/null-like network interface toward the destination. If the
> >desired network interface fails, then StaticRoutes itself will
> >replace the first route with the second route inside the RIB (this
> >operation can be atomic, because there is already a "replace_route"
> >XRL).
> >
> >If the netadmin does want to ensure reachability, then he simply
> >doesn't need to install the second route with the less preferred
> >metric and the /dev/null next-hop network interface.
> 
> There's a simpler solution than this.  The XRL interface to the RIB
> should require the admin distance to be specified on a per-route
> basis.  This would allow low-priority static routes - something I
> think is quite desirable, as a fallback in case a dynamic routing
> protocol loses all routes.
> 
> Currently the RIB chooses the admin distance for each protocol.  But
> this isn't a good idea - if a new protocol comes along it requires the
> RIB to be modified.  The routing protocol should specify the admin
> distance.  Once it's doing this, it can also do it on a per-route
> basis, so that the default admin distance for a protocol can be
> overridden if desired.  Probably this would only be used for static
> routes, and as a result of policy filtering.

I think what you are proposing is kind of orthogonal.

I was suggesting that we can use routes with different metrics to
configure StaticRoutes such that if the original route fails, and if
we don't want to use the RIP routes for a particular destination,
then the second route (that points to /dev/null) will be used by
StaticRoutes and installed into the RIB. Obviously, this can't be
used to install fallback static routes if the dynamic routing fails,
but can be used to keep _some_ high-priority static routes into the
RIB.

I agree with your suggestion to export the admin distance to the RIB
XRL add/replace interface. Then, we can mediate between protocols
and let static routes being used as backups.

In other words, I think we want both solutions, because they are not
mutually exclusive, but complementary.

Regards,
Pavlin