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

Mark Handley M.Handley@cs.ucl.ac.uk
Fri, 13 Aug 2004 08:26:13 +0100


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

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.

Cheers,
	Mark