[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 #23 from Tom Henderson <tomh at tomh.org>  2008-11-22 17:23:05 EDT ---
(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.

> 
> 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.

> 
> 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.

> 
> Please let me know if you want me to post the files for each of the above
> scenarios.
> 

Not necessary, I was able to reproduce each one.  Thank you for the detailed
report.  Sorry this is causing you problems; I'll expedite a new patch.


-- 
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.