Bug 520 - tap-bridge does not support virtual machines
: tap-bridge does not support virtual machines
Status: RESOLVED FIXED
: ns-3
devices
: ns-3-dev
: All Linux
: P2 normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-03-12 00:30 EDT by
Modified: 2009-03-24 21:00 EDT (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


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