[Ns-bugs] [Bug 406] GlobalRouteManager behaviour after Ipv4 interface SetDown and SetUp procedure

code@nsnam.ece.gatech.edu code at nsnam.ece.gatech.edu
Sat Nov 15 14:58:14 PST 2008


http://www.nsnam.org/bugzilla/show_bug.cgi?id=406





--- Comment #14 from Tom Henderson <tomh at tomh.org>  2008-11-15 17:58:13 EDT ---

> > 
> > I double checked this bug by doing a simple experiment. I SetDown an ipv4
> > interface immediately after creating the link. I observed that the global
> > routing manager ignores this fact and goes on to choose the disabled link in
> > its routing calculations. 
> > 
> > Is there a way to include a check in the routing calculation to see if the
> > interface of the link is up or down? Perhaps a call to the IsUp method of ipv4
> > class before proceeding with routing calculation?
> 
> I believe that the current behavior of the code is correct, that is, the global
> routing code should setup all routes, regardless of the ipv4 up or down state.
> It seems to me that what should happen is one or a mix of:
> 1) make the per-node route lookup be aware of the ipv4 link state. that is,
> route lookup should not return a route for an ipv4 interface which is down.
> Instead, it should a route with potentially a lower metric but which at least
> is up
> 2) make sure that the global route setup configures multiple routes with
> different metrics using multiple interfaces if there are multiple interfaces on
> a node such that the route lookup in (1) can fallback to different interfaces
> if some of them are down.
> 
There is only one route calculated to each destination.  This is not a
multipath routing algorithm.
> 
> 
> 
> However, it should probably also setup routes such that the ip route lookup in
> each node's forwarding table returns a working route when various ipv4
> interfaces are down. 
> 

If the topology changes, routes at each node should be recomputed.  If routers
autonomously make decisions to recalculate routes, or suppress telling their
neighbors about link up/down events, there will likely be routing loops or
black holes.  This particular algorithm avoids loops by enforcing a consistent
view of the topology at each node.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the Ns-bugs mailing list