Bug 1487

Summary: BridgeNetDevice flooding causes crash if a loopback device was added to it
Product: ns-3 Reporter: scheibel1
Component: bridgeAssignee: Gustavo J. A. M. Carneiro <gjcarneiro>
Status: NEW ---    
Severity: normal CC: ns-bugs
Priority: P5    
Version: pre-release   
Hardware: All   
OS: All   

Description scheibel1 2012-08-17 16:17:27 EDT 
As it stands now, internet stacks cannot (should not) be installed on nodes that function as bridges, because the bridge will try to forward to the loopback device that is provided as part of the internet stack (at which point the loopback device will end the simulation, according to logic in loopback-net-device.cc, SendFrom). In particular the issue occurs when the bridge device has no learned state for a packet and performs flooding (in ForwardUnicast).

This is not documented as far as I know (http://www.nsnam.org/doxygen/group__bridge.html) so it seems that it would be a good idea to either:

a.Document it (and perhaps fail fast if one attempts to aggregate a loopback device into a bridge).  This would have the disadvantage that bridges would not be routable (and therefore one could not install applications on a bridge node).

b.Change the bridge net device to check whether a ported device is a loopback device (and not call SendFrom on it if this is true).  This seems like the best choice to me.

Thanks!
Comment 1 scheibel1 2012-08-17 17:36:07 EDT 
Actually, one can avoid this issue by avoiding adding netdevices which are loopback net devices when calling BridgeHelper::Install.  My title is therefore misleading, as bridge nodes should work fine as long as I avoid the mistake of adding a loopback device to the bridge.  

It would still be nice if the BridgeNetDevice would refuse to add loopback devices, or if this behavior was documented (i.e. make sure not to install loopback devices with the BridgeHelper).  

I think this is worthwhile because the issue results from what I would consider to be a valid use case: I personally made this mistake because it was attractive to me to mark nodes as bridges, and then later come around and bundle all the netdevices together for such nodes with the BridgeHelper (which happened to be after a point when an internet stack had been installed on the bridge).
Comment 2 Tommaso Pecorella 2013-02-17 17:43:40 EST 
To be honest I'd go for the (b) option, however I'd like to argue about it a bit more.
Now, a "bridge" device is for real a... stupid bridge (meaning, not intellgent). Let's check what is the intended use of such a device.

The answer is trivial: one wants to make a... bridge (doh!), like a hub or a WiFi AP with bridged interfaces (the WiFi and the Ethernet). Note: a switch is different). The two are quite different tho, as in the first case you'll probaby NOT want to have an IP stack on the hub, while you might want the IP stack on the WiFi AP.
Hence, the Bridge NetDevice should be "nice" with loopback things.

In order to fix this, however, I'd like to have a test program where the Brige fails miserably. If this possible ?

Thanks.
Comment 3 Gustavo J. A. M. Carneiro 2013-10-26 10:48:15 EDT 
Well, this is kind of documented.  Documentation says:

"Bridging is designed to work only with NetDevices modelling IEEE 802-style technologies, such as CsmaNetDevice and WifiNetDevice."