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

[Pavlin Radoslavov]

> >c) If the next-hop router toward the destination is not resolvable,
> >   then the StaticRoutes should still add the route to the RIB, and
> >   then let the RIB deal with resolving the next-hop router
> >   whenever the status of the related network interface changes.
> >   Doing something like this may require changes to the RIB.
> 
> The RIB does actually contain code to do this - it's just not enabled
> for IGP routes.  The code was originally there for BGP, before we
> realised that BGP routes where the BGP nexthop is unreachable
> shouldn't be considered for the BGP decision process.  Currently I
> believe this code in the RIB is unused - you can find it in
> rib/rt_tab_extint.cc (look for anything to do with
> unresolved_nexthops).
> 
> In any event, this opens up several more questions: 
> 
>  - Should static_routes be able to specify a nexthop that isn't an
>    immediate neighbour? (So long as the nexthop is reachable via
>    another route).  Retasking the code in ExtIntTable to do nexthop
>    lookup for IGP routes would give us this.  We'd need to be careful
>    to check for mutual recursion though.
> 
>  - If we have a static_route for a destination, and a dynamic route
>    (say from RIP) for the same destination, the static_route will
>    normally win on admin distance.  Now, say the interface for the
>    static_route goes down.  Should the route fall back to that from
>    RIP?  I can see both answers make sense:  
>     
>      + It should not fall back because the network administrator
>        really really wanted to NOT use the RIP route - that's why he
>        configured the static route.  
> 
>      + It should fall back because we really want to ensure
>        reachability above all else.
> 
> Anyway, the answer to the second question determines (or at least is
> closely related to) whether you want the resolvabilty test in the
> static_routes process, or in the RIB itself.

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.

The above logic is quite simple to implement inside StaticRoutes,
and the only caveat to the end-user is that it will become legal to
install inside StaticRoutes the same route more than once, but with
different attributes.

> 
> This could of course be a policy question - if the RIB had the nexthop
> reachability code, we could configure the behaviour for each static
> route on a case-by-case basis.  If static_routes does the reachability
> test, then the route would be withdrawn when the interface goes down,
> allowing the RIP route to take over.  If static_routes always passes
> the route to the RIB , and the RIBdoes the reachability test, then it
> would be after the admin_distance test, and so the RIP route would not
> take over if the interface went down.
> 
> 
> In any event, there needs to be a way to should the routing table
> including the routes with unresolvable nexthops to see what the
> problem is.  Currently the way to show static routes is to show the
> RIB's view of them, which only shows the routes with reachable
> nexthops.

Yes, StaticRoutes itself should support some xorpsh "show" commands,
so we can look directly into its state. Currently, we can look only
into what gets installed into the RIB.

Regards,
Pavlin