[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 03:33:54 PST 2008
http://www.nsnam.org/bugzilla/show_bug.cgi?id=406
--- Comment #11 from Mathieu Lacage <mathieu.lacage at sophia.inria.fr> 2008-11-15 06:33:54 EDT ---
(In reply to comment #10)
> (In reply to comment #6)
> > >
> > > Attached is a patch that we used. I am not sure how sound this strategy is?
> > >
> > > However, this does not help with the case where there are multiple paths
> > > between a source destination pair. When one of the paths becomes unavailable,
> > > we are not able to make the simulator use the alternative path with the global
> > > routing manager.
> > >
> >
> > The reason the patch will not completely work is that it doesn't delete the
> > existing routes. Try adding a loop that deletes everything first, before
> > reinitializing things.
> >
> > for (uint32_t i = 0; i < ipv4->GetNRoutes(); i++)
> > {
> > ipv4->RemoveRoute (i)
> > }
> >
>
> We were able to delete the existing routes as mentioned above. However, it
> appears that recalculating the routes using BuildGlobalRoutingDatabase and
> InitializeRoutes results in the exact same routes being calculated. In other
> words, the system does not recognize the fact that a certain link (ipv4
> interface) is down in its routing calculation.
>
> 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.
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.
--
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