[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 #7 from Tom Henderson <tomh at tomh.org>  2008-11-12 01:36:34 EDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > Yes, global routing only works in the pre-simulation stage at present.  I will
> > try to provide some kind of workaround for you later tonight.  
> > 
> > For the longer-term cleaner fix, in general, if we want to support calling
> > PopulateRoutingTables() at any time in the simulation, we need to be able to
> > keep track of the routes that were previously injected, so they could be
> > removed.  One way would be to tag each route somehow so the routes iterated
> > could be examined for the tag.  Another way would be to store these routes in a
> > dedicated global routing object that is distinct from the static routing
> > ("manual" routing) object that users may want to hand-enter default routes, and
> > to call Flush() on this routing object.  Right now, those routes are mixed
> > together in Ipv4StaticRouting so we do not want to just delete every route we
> > find in that object.
> 
> Erm, the behavior I was expecting was that PopulateRoutingTables would reset
> the routing tables of all nodes it is invoked on. i.e., it would empty the
> forwarding tables before filling them.
> 

That would be the easiest behavior to code, but would tend to make it harder
for users to mix hand-crafted route installation (such as adding defaults to
portions of the topology, such as an ad hoc routing subnet) with global route
installation.  Such users would have to keep re-entering their static routing
entries each time the global routing changed.


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