[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 #10 from Egemen <egemen.cetinkaya at gmail.com>  2008-11-14 17:29:00 EDT ---
(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?


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