Bug 520 - tap-bridge does not support virtual machines
tap-bridge does not support virtual machines
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: devices
ns-3-dev
All Linux
: P2 normal
Assigned To: Craig Dowell
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-12 00:30 EDT by Tom Henderson
Modified: 2009-03-24 21:00 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Henderson 2009-03-12 00:30:19 EDT
Current tap-bridge works when the packets are being sourced/sinked by the host machine via the tap device, if the host's tap device parameters are lined up with the ns-3 device:

device      mac
---------------
tap0        00:00:00:00:00:01
tap-bridge
wifi        00:00:00:00:00:01

It exploits (but is constrained by) the fact that tap0 (or "left" in the example script) and wifi0 have both the same IP address and same mac address.  The tap-bridge calls the (Wifi)NetDevice::Send() method, which adds mac addresses.

In the use case I'm interested in, the device being bridged is not a tap device but another host virtual device, such as an OpenVz "veth" device.  Here, the various mac addresses may be different:

device
------
eth0 (on virtual machine)  00:00:00:aa:00:00
veth1000.0 (on host)  00:bb:00:aa:00:00
tap0   00:00:00:aa:00:01
tap-bridge
wifi     00:00:00:00:00:01

This will not work as present.  It is not always possible to change the mac address on the virtual machine (eth0 in this case).  It is not necessarily easy for ns-3 to know this mac address other than by configuration side information.  

To make this work now, the tap-bridge needs to bridge frames from a foreign address (00:00:00:aa:00:00) to the wifi adapter, which has 00:00:00:00:00:01.  The tap-bridge itself thinks it has 00:00:00:00:00:01 (it learns this from the wifi device), so address 00:00:00:aa:00:00 looks foreign to it.

This necessitates two changes:
1) tap-bridge.cc has some code where it throws away unicast frames destined to OTHERHOST.  These should be permitted in this case.
2) tap-bridge needs to promiscuously receive from wifi device and be able to map between the wifi mac address and the eth0 address.  wifi should not reply to any arps or process any incoming frames at the IP layer or above.

The way I thought it might work is:
- in the virtual machine to ns-3 direction, the tap-bridge learns of the eth0 source mac address.  there can only be one mac address-- if two unique source addresses are observed, then assert.
- tap bridge calls NetDevice::Send()-- the source mac address will be overwritten to the mac of the wifi netdevice
- in the ns-3 to virtual machine direction, the tap-bridge will receive frames destined to the wifi mac address.  Here, the tap-bridge can swap out the wifi mac for the learned eth0 mac.
Comment 1 Tom Henderson 2009-03-12 00:32:32 EDT
To clarify, this is a second "mode" of operation for tap-bridge.  I'm not proposing to remove how Craig has it first working, because I think that mode may be usable for protocol testing purposes.  I don't know whether it makes more sense to implement this requested mode as a "mode" of the existing class or as a different subclass.