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 an attachment (id=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 an attachment (id=312) [details]
Patch to fix bugs 116 and 66

(In reply to comment #6)
> Created an attachment (id=312) [details] [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?