[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 #26 from Tom Henderson <tomh at tomh.org>  2008-12-01 02:32:39 EDT ---
(In reply to comment #23)
> (In reply to comment #22)
> 
> > 
> > However, we found three potential problems as shown with the following
> > scenarios:
> > 
> > Scenario 1:
> > 
> > Problem Summary:
> > An alternate path is used only if the sink is attached to the ipv4 interface on
> > the alternate path. 
> > 
> > Testing:
> > In the above mentioned example, connect the sink application to i1i6 instead of
> > attaching to i5i6. Replace i5i6.GetAddress (1) with i1i6.GetAddress (1) in
> > line-133. No traffic flows between 3sec and 4 secs despite of an available
> > alternate link.
> 
> This is an outcome of the limitation that is documented in bug 66. 
> Specifically, when you put the sink there, the algorithm should process the
> interface as a Type 3 (stub) network link but we didn't finish off the support
> in the Dijkstra to do the stub networks yet.
> 
> I can raise the priority of fixing that.  I have some code to fix it that needs
> some cleanup and testing.

The latest patch fixes the above, and it is tested during time 11-15 of the
attached test program.

> 
> > 
> > Scenario 2:
> > 
> > Problem Summary:
> > If the interface to which the sink is attached goes down, all traffic stops
> > even if there exists an alternate route to the destination node.
> > 
> > Order of events: (changes marked with '-->')
> > //  At pre-simulation time, configure global routes.  Shortest path from
> > //  n1 to n6 is via the direct point-to-point link
> > //  At time 1s, start CBR traffic flow from n1 to n6
> > //--->  At time 2s, set down the point-to-point interface *1* on node *n6*. T
> > //  The Traffic flow stops
> > //--->  At time 3s, call RecomputeGlobalRoutes() and traffic does *NOT*
> > //    flow again the alternate path
> > //  At time 4s, re-enable the n1/n6 interface to up.  Will not change routing
> > //---> The traffic will start flowing on the original path whether or not you
> > Recomute GlobalRoutes
> > //  At time 5s, call RecomputeGlobalRoutes() and traffic will continue to flow 
> > 
> 
> This one is debatable whether it is correct or incorrect behavior.  If the
> interface is down, is the IP address associated with that interface available
> still on the node, via other interfaces?  If this is a weak ES model (RFC
> 1122), perhaps, but it probably varies from system to system whether it works
> or not.

I did not add support for this, since the associated IPv4 interface is in a
down state (and the address could be considered to be inactive and unavailable
via a different interface).

> 
> > 
> > Scenario 3:
> > 
> > Problem Summary:
> > A link does not go down unless both the interfaces on either side of the link
> > are setdown, with the exception of source interface.
> > 
> > Testing:
> > In the example that you gave, setdown ipv4 interface on node 6 corresponding to
> > link 1-6. If no further steps are taken, the traffic continues to flow on the
> > this failed link (link 1-6). 
> 
> Indeed, this is a bug in Ipv4L3Protocol::Receive().  IPv4L3Protocol::Receive()
> should check its Ipv4Interface state and drop the packet.  The reason that the
> packet is even sent at all on the interface is that, on the outbound interface,
> there is no globally computed route but the link is still "up" from the
> perspective of the sending node and the address matches the prefix on the p2p
> link.

This is fixed in the current patch, and tested during time 6-9 seconds in the
test program.


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