[Ns-bugs] [Bug 114] global routing doesn't handle multi-hop layer-2 subnets

[code@nsnam.ece.gatech.edu]

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





--- Comment #7 from Tom Henderson <tomh at tomh.org>  2008-11-22 18:54:00 EDT ---
(In reply to comment #6)
> Created an attachment (id=312)
 --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=312) [details]
> Patch to fix bugs 116 and 66
> 

I reviewed this patch and it basically looks good to me, but there is one piece
that I found unusual:

+  void
+GlobalRouter::ProcessBroadcastLink (Ptr<NetDevice> nd, GlobalRoutingLSA *pLSA,
NetDeviceContainer &c)
+{
+  NS_LOG_FUNCTION (nd << pLSA << &c);
+
+  if (nd->IsBridge ())
+    {
+      ProcessBridgedBroadcastLink (nd, pLSA, c);
+    }
+  else
+    {
+      ProcessSingleBroadcastLink (nd, pLSA, c);
+    }
+} 
+

The ProcessBridgedBroadcastLink implies that you can have a node which is both
a bridge and a router, on the same device.  That is, a NetDevice that is in a
bridge group can also be considered as an IP interface for routing purposes, if
someone assigned an IP address to it.  So, the device can forward at layer-2
and router at layer-3?  I'm not sure what behavior that might trigger.

In my experience, bridges do not have IP addresses, but if they do, they are
assigned an IP address on the virtual bridge interface (not on the ports
themselves) and this is just used for management such as getting SNMP data out
of the bridge; i.e. the bridge is not an IP forwarding device.

I would be inclined to disallow the above ProcessBridgedBroadcastLink and
perhaps to even sanity check that people are not assigning Ipv4Interfaces to
non-virtual devices that are in bridge groups (although I think the latter will
be hard to implement and it may be a job of the global routing code to detect
and avoid this).  It makes it less flexible but perhaps less prone to confusion
or configuration error.  Other opinions?


(Aside:  this patch does not fully fix bug 66, it just provides the API
allowing the topology to be restricted, but there is still missing code in the
global route manager as to how to process the stub links)


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