@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.pri...@profihost.ag <mailto:s.pri...@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.pri...@profihost.ag > <mailto:s.pri...@profihost.ag> > > <mailto:s.pri...@profihost.ag <mailto:s.pri...@profihost.ag>>> wrote: > > > > > > Signed-off-by: Stefan Priebe <s.pri...@profihost.ag > <mailto:s.pri...@profihost.ag> > > <mailto:s.pri...@profihost.ag <mailto:s.pri...@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@pve.proxmox.com <mailto:pve-devel@pve.proxmox.com> > <mailto:pve-devel@pve.proxmox.com <mailto:pve-devel@pve.proxmox.com>> > > http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > > > > > _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel