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

[code@nsnam.ece.gatech.edu]

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





--- Comment #13 from Tom Henderson <tomh at tomh.org>  2008-11-15 17:50: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?
> 
Yes, we could add a check to look at the Ipv4Interface state of the interface. 
I think that we need to do this check to support the dynamic behavior you are
looking for.


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