[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