[pve-devel] [PATCH] support QinQ / vlan stacking

[Stefan Priebe - Profihost AG]

@dietmar
I think this is a big problem and i never noticed it. Currently a guest
attached to the bridge see all frames. I thought it sees only untagged
frames.

This means i cannot isolate a guest to only untagged frames. What's your
opinion?

Stefan

Am 02.03.2015 um 23:10 schrieb Andrew Thrift:
> Hi Stefan,
> 
> Yes that is correct.  The tap interface of a VM attached only to vmbr0
> with no vlan specified will see all frames.  
> Individual guests that are connected to vmbr0 with a vlan specified will
> only see frames tagged with that vlan-id.
> 
> The use case is that we often attach virtual routers to the parent
> bridge e.g. vmbr0 so they are able to access multiple client vlan's.
> 
> This is no different than the previous standard config, attaching
> directly to vmbr0 would allow you to see all frames.
> 
> 
> Regards,
> 
> 
> 
> Andrew
> 
> 
> On Mon, Mar 2, 2015 at 8:53 PM, Stefan Priebe - Profihost AG
> <s.priebe at profihost.ag <mailto:s.priebe at profihost.ag>> wrote:
> 
>     Hi Andrew,
> 
>     sorry i lost this mail... Please see reply inline.
> 
>     Am 24.02.2015 um 04:45 schrieb Andrew Thrift:
>     > We have found you need to nest the bridges to get QinQ to work in all
>     > scenarios.
>     > e.g. The above patch will work for MOST scenarios, but if you attach a
>     > vlan aware VM to the parent vmbr0 bridge it will cause traffic to the
>     > VM's to stop, or will not be able to see the tagged frames.
>     >
>     > The patch we use only has one other minor change:
>     >
>     > -        activate_bridge_vlan_slave($bridgevlan, $iface, $tag);
>     > +        activate_bridge_vlan_slave($bridgevlan, $bridge, $tag);
> 
>     So you mean if you attach a 2nd VM where not the tap device handles the
>     tagged frames but instead the VM does itself. It won't work? I'm not
>     sure if this should work at all.
> 
>     As this means somebody can grab tagged traffic inside his VM without
>     your knowledge.
> 
>     Stefan
> 
> 
>     > On Sat, Feb 14, 2015 at 9:41 PM, Stefan Priebe <s.priebe at profihost.ag <mailto:s.priebe at profihost.ag>
>     > <mailto:s.priebe at profihost.ag <mailto:s.priebe at profihost.ag>>> wrote:
>     >
>     >
>     >     Signed-off-by: Stefan Priebe <s.priebe at profihost.ag <mailto:s.priebe at profihost.ag>
>     >     <mailto:s.priebe at profihost.ag <mailto:s.priebe at profihost.ag>>>
>     >     ---
>     >      data/PVE/Network.pm |    2 +-
>     >      1 file changed, 1 insertion(+), 1 deletion(-)
>     >
>     >     diff --git a/data/PVE/Network.pm b/data/PVE/Network.pm
>     >     index 00639f6..97f4033 100644
>     >     --- a/data/PVE/Network.pm
>     >     +++ b/data/PVE/Network.pm
>     >     @@ -323,7 +323,7 @@ sub activate_bridge_vlan {
>     >
>     >          my @ifaces = ();
>     >          my $dir = "/sys/class/net/$bridge/brif";
>     >     -    PVE::Tools::dir_glob_foreach($dir, '((eth|bond)\d+)', sub {
>     >     +    PVE::Tools::dir_glob_foreach($dir, '((eth|bond)\d+(\.\d+)?)', sub {
>     >              push @ifaces, $_[0];
>     >          });
>     >
>     >     --
>     >     1.7.10.4
>     >
>     >     _______________________________________________
>     >     pve-devel mailing list
>     >     pve-devel at pve.proxmox.com <mailto:pve-devel at pve.proxmox.com>
>     <mailto:pve-devel at pve.proxmox.com <mailto:pve-devel at pve.proxmox.com>>
>     >     http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>     >
>     >
> 
>