> Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support > > On Wednesday 12 August 2009, Fischer, Anna wrote: > > Yes, for the basic VEPA this is not important. For MultiChannel VEPA, > it > > would be nice if a macvlan device could operate as VEPA and as a > typical > > 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. > > > Basically, what we would need to be able to support is running a VEB > and > > a VEPA simultaneously on the same uplink port (e.g. the physical > device). > > 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. > > > I think the question here was whether there is a way for a macvlan > interface > > to be set to promiscuous mode. At the moment, I believe a macvlan > interface > > only receives packets based on its destination address (this is for > unicast > > packets now). What if a macvlan interface wanted to get all packets > that > > are being received (either on the physical device, or on a particular > > VLAN if using macvlan nested in vlan). Would this work easily? > Imagine > > you have a virtual machine attached to that macvlan / macvtap device > and > > this VM wants to do packet inspection or network traffic monitoring > on > > 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
