[lxc-devel] [Fwd: [PATCH 3/4] macvlan: implement bridge, VEPA and private mode]

[Daniel Lezcano]

Andrian Nord wrote:
> Yes, this is very interesting, but in some points it seems to be based
> on missing context. May I ask some clarifications about this points?
>   
Sure :)
>> MACVLAN_PRIVATE:
>>   The device never communicates with any other device
>>   on the same upper_dev. This even includes frames
>>   coming back from a reflective relay, where supported
>>   by the adjacent bridge.
>>     
>
> i.e. current behaviour of macvlan?
>   

Right.
>> MACVLAN_VEPA:
>>   The new Virtual Ethernet Port Aggregator (VEPA) mode,
>>   we assume that the adjacent bridge returns all frames
>>   where both source and destination are local to the
>>   macvlan port, i.e. the bridge is set up as a reflective
>>   relay.
>>   Broadcast frames coming in from the upper_dev get
>>   flooded to all macvlan interfaces in VEPA mode.
>>   We never deliver any frames locally.
>>     
>
> Current macvlan (without possibility of intercommunication or communication
> with host's physical device) + possibility of catching broadcasts?
>   



>>   interface, but when they come back from a reflective
>>   relay, we don't deliver them again.
>>     
>
> Hm, I'm completely lost, what is "reflective relay" in link with
> "adjacent bridge". This is some feature that should be enabled on
> physical device macvlan-device is bound on (and this feature reflects
> packets sent to same physical device back to connected macvlan-devices,
> allowing intercommunication of macvlans bound on same physical device)?
>   

I not am sure for this one, but I think this mode allows to plug the 
macvlan to a bridge and fix problem of infinite looping packets in the 
virtual network topology bridge + macvlan (same as plugin a bridge with 
a another bridge).

>> [...]
>>   Since we know all the MAC addresses, the macvlan bridge
>>   mode does not require learning or STP like the bridge
>>   module does.
>>     
>
> This seems to cover most of common veth uses, and it should be much
> faster than veth, right (if we don't need absolutely virtual device)?
>   
Absolutely, and this mode looks very promising because you can setup 
your container without setting up the host, you keep native network 
performances and you can communicate with the other containers having a 
macvlan on the same physical devices.