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

Mark Handley M.Handley@cs.ucl.ac.uk
Mon, 16 Aug 2004 23:13:52 +0100


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

 - Mark