If I was to fix it, I think one way to do it would be aggregating an interface to each of the netdevices.  Such interface would have a method to retrieve other netdevices attached to that netdevice.  Then we need a "L2 bridge" interface in Node, which would have a method enumerating other netdevices connected to the same "bridge" as a certain netdevice of the node.  With these two interfaces the GlobalRoutingManager would be able to recursively follow all possible L2 paths from a given netdevice and discover all remote L2 devices, even multihop ones.

Created attachment 252 [details]
test case program

this is an example program that should work with global routing but doesn't yet

will fix for ns-3.3 but document the limitation in ns-3.2 as a "known issue"

we discussed this last Friday.  There likely is new API necessary for a NetDevice to make this work:  NetDevice::IsBridge().

Basically, the global routing code crawls the network, link-by-link.  If it encounters a bridge node, it will first encounter a NetDevice type that is a real interface (such as CSMA).  It needs to determine whether the CSMA interface is part of a bridge group and, if so, find all of the bridged-together NetDevices and recursively crawl each of those channels looking for more NetDevices in the same broadcast domain.

If there is a NetDevice::IsBridge() method, the code can iterate the devices on a target node and look for bridge devices.  For each bridge device found, it can iterate and look whether the device in question is part of that bridge group.  

A more direct way would be to ask the target device (i.e., the CSMA interface) whether it is itself part of a bridge group (e.g., NetDevice::IsBridged()  -note the trailing "d") but that would require devices to know whether they are in a bridge or not and is not strictly required to make this global routing work.  So, we agreed to try for a solution that would add NetDevice::IsBridge() and set it to true for any device that considers itself a bridge.

bump from enhancement to normal, since we now have bridging code that needs this functionality

bumping priority

Created attachment 312 [details]
Patch to fix bugs 116 and 66

(In reply to comment #6)
> Created an attachment (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)

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

This code only expects IP addresses on the bridge net device interfaces.  The bridge ports themselves are expected *not* to have IP addresses.  This allows a host to bridge some of its interfaces together without needing a separate bridge node.

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

It would be good to try and detect bridge ports that have IP addresses since they are expected not to have them.  I don't really care if you want to disallow bridges on nodes with internet stacks.  It seems convenient, and BTW, Mircosoft OSes allow it.

(In reply to comment #8)
> > 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.
> 
> This code only expects IP addresses on the bridge net device interfaces.  The
> bridge ports themselves are expected *not* to have IP addresses.  This allows a
> host to bridge some of its interfaces together without needing a separate
> bridge node.

It seems to me the current code in global-router-interface.cc is handling the case where the bridge net device has an IP address.  To get to the 
ProcessBroadcastLink() method (line 616), one has to pass the IPv4 interface check (line 598).  Then, if someone has assigned the bridge device an IP address, it will proceed to ProcessBridgedBroadcastLink().

> 
> > 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?
> 
> It would be good to try and detect bridge ports that have IP addresses since
> they are expected not to have them.  I don't really care if you want to
> disallow bridges on nodes with internet stacks.  It seems convenient, and BTW,
> Mircosoft OSes allow it.
> 

I wasn't suggesting that we disallow bridges on nodes with internet stacks; only that if some of the devices are part of a bridge group that they are not used as router interfaces also.

(In reply to comment #8)
> The
> bridge ports themselves are expected *not* to have IP addresses.  This allows a
> host to bridge some of its interfaces together without needing a separate
> bridge node.

I agree-- could we enforce this by checking whether NetDeviceIsBridged() such as at line 613 or so?

if (NetDeviceIsBridged (ndLocal))
 {
  continue;
 }

I'm not sure we're communicating well.  You (Tom) wrote:

  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.

A net device in a brige group may not have an IP address associated with it.  If a node is a router, and has a bridge, the IP interface for routing purposes is the bridge net device, which is not a net device in a bridge group, unless I misunderstand the term.

I added an explicit test in ProcessBridgedBroadcastLink to ensure that net devices in a bridge group (bridge ports in Gustavo's lingo) do not have IP interfaces.

As it stands now, a node with a router can have a bridge device on it (that may have a number of associated brige ports).  The router will treat the bridge net device (not the ports) as an interface routing purposes if the bridge net device has an IP address.

Is this the behavior okay, or do you want to disallow the bridge net device with IP address from participating in routing?  If so, I don't really understand your concern.  Can you elaborate?