RE: [PATCH][RFC] net/bridge: add basic VEPA support

Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support

On Wednesday 12 August 2009, Fischer, Anna wrote:

quoted

Yes, for the basic VEPA this is not important. For MultiChannel VEPA,

it

quoted

would be nice if a macvlan device could operate as VEPA and as a

typical

quoted

VEB (VEB = traditional bridge but no learning).

Right, this would be a logical extension in that scenario. I would
imagine
that in many scenarios running a VEB also means that you want to use
the advanced ebtables/iptables filtering of the bridge subsystem, but
if all guests trust each other, using macvlan to bridge between them
sounds useful as well, if only for simplicity.

quoted

Basically, what we would need to be able to support is running a VEB

and

quoted

a VEPA simultaneously on the same uplink port (e.g. the physical

device).

quoted

A new component (called the S-Component) would then multiplex frames
to the VEB or the VEPA based on a tagging scheme.

You can of course do that by adding one port of the S-component to
a port of a bridge, and using another port of the S-component to
create macvlan devices, or you could have multiple ports of the
S-component each with a macvlan multiplexor.

Just to make sure I get the chain right, would it look like this?
(adapted from Paul's PDF)

eth0 (external) ---scomponent0 --- vlan2 --- macvlan0
                 |              |         \- macvlan1
                 |               \-vlan3 --- macvlan2
                 |-scomponent1 --- vlan2 --- br0 --- tap0
                 |                             \ --- tap1
                 |-scomponent2 --- vlan3 --- macvlan3
                 \-scomponent3 ---  ---  --- macvlan4

In this scenario, tap0 and tap1 could communicate over the bridge
without
tagging, while any data going out through the S-Component gets tagged
with both a 802.1q Q-Tag and an S-Tag.

Yes, that looks right. If all the different interfaces, e.g. bridge ports,
macvlan devices, vlan tagging devices can be stacked that easily without
any known issues, that would be great.

macvlan4 would be a guest that does its own tagging, and the external
switch would need to check the VLAN IDs, but it could communicate with
any other guest by tagging the frames as 2 or 3.

macvlan2 and macvlan3 could communicate with each other and with
external
guests in vlan3.

Guests on scomponent1 and scomponent3 could in theory have
subdivisions of the network with macvlan running in the guest
to run containers.

quoted

I think the question here was whether there is a way for a macvlan

interface

quoted

to be set to promiscuous mode. At the moment, I believe a macvlan

interface

quoted

only receives packets based on its destination address (this is for

unicast

quoted

packets now). What if a macvlan interface wanted to get all packets

that

quoted

are being received (either on the physical device, or on a particular
VLAN if using macvlan nested in vlan). Would this work easily?

Imagine

quoted

you have a virtual machine attached to that macvlan / macvtap device

and

quoted

this VM wants to do packet inspection or network traffic monitoring

on

quoted

all packets flowing through the virtualized server.

Ok, I see. As I said, the host could easily get access to all frames
on macvlan downstream ports by opening a raw socket on the upstream
port (with some extra work if we want to support this in bridge mode).

If you want the inspection to be done in a guest rather than the host,
the easiest way to achieve that would be to connect that raw socket
to the guest using Or's raw frontend for qemu.

I am not too familiar with that raw frontend for qemu to be honest, but 
if it can share the physical device with other macvlan interfaces 
simultaneously, then I think that would indeed be sufficient to support
promiscuous mode ports. We would need to have a similar sort of driver
for Xen and other hypervisor solutions again as well though.

If it is possible to easily stack macvlan devices and bridges as you
describe above, then a promiscuous port should also be realized quite
easily as a typical bridge port, e.g. as shown above tap0 and tap1 
would be typical, traditional bridge ports and though could send
and receive from/with any MAC addresses they like.

Anna