Hi, about qinq, I found this forum message:
http://www.linuxforums.org/forum/networking/197702-qinq-vlan-stacking-linux.html It seem possible with vconfig, tu do something like eth0.101.201 --> stacked vlans: 101 (outside) / 201 (inside). do is work with bond0.101.201---->vmbr0<----tap interface ? (It could be easy to add it in proxmox curent code) /sbin/vconfig add bond0.101 201 ----- Mail original ----- De: "Stefan Priebe - Profihost AG" <[email protected]> À: "Alexandre DERUMIER" <[email protected]>, "Johannes Ernst" <[email protected]> Cc: "pve-devel" <[email protected]> Envoyé: Jeudi 16 Janvier 2014 08:17:36 Objet: Re: [pve-devel] [PATCH] Virtual vlan tagging to bridge interface HI Alexendre, Am 16.01.2014 06:25, schrieb Alexandre DERUMIER: >>> Q-in-Q works with all kernel versions (cents 5 & 6 + debian 6 & 7) > > Do you have tested last kernels ? (like 3.10). Because Stefan Priebe said > that it doesn't work anymore. (since 3.8 - 3.9) > > > (maybe now we need to create this qinq interface with ( ip link add link eth0 > eth0.100 type vlan proto 802.1ad id 100) , but this need new iproute2 > package) i'm not sure what was not working may be it was just my GVRP stuff. But that was the reason to switch back to the upstream code again. I had a lot of discussions on the lkml regarding which way is the correct way - but it seems the people even there have no default way. That's also the reason why something works in way a and some other stuff in way b. Stefan > ----- Mail original ----- > > De: "Johannes Ernst" <[email protected]> > À: "Alexandre DERUMIER" <[email protected]> > Envoyé: Mercredi 15 Janvier 2014 15:33:45 > Objet: Re: [pve-devel] [PATCH] Virtual vlan tagging to bridge interface > > Q-in-Q works with all kernel versions (cents 5 & 6 + debian 6 & 7) and tunnel > protocols like tinc. So you can do something like that: eth0 -> vmbr1 -> > vmbr1.100 -> vmbr2 -> vmbr2.102 -> vmbr3 > > Tagged tap interfaces might work as long as the tagging is done by the bridge > and not on the tunnel (like eth1, eth2,..) interface. > > > Am 14.01.2014 um 06:47 schrieb Alexandre DERUMIER <[email protected]>: > >>>> The packet is DOUBLE TAGGED with 0x8100 tags. So the outer tag (SVID) is >>>> 101 with an inner (CVID) tag of 201. >> >> Ok, and this work with kernel < 3.10 ? >> Because I see that support of 802.1d tagging has been had since 3.10. >> >> # ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100 >> >> (how do you defined eth0.100 in /etc/network/interfaces ?) >> >> Maybe this is why this kind of setup doesn't work anymore for stefan ? >> >> >> Anyway, I think it should work with my patch >> >> eth0.101--->vmbr0---<---tap0 >> >> #bridge vlan add dev tap vid 201 pvid untagged >> >> >> so, bridge will tag vlans for tap0. >> Then eth0.101 will retag 802.1ad. >> >> >> >> (What we need to check is how to defined eth0.100 to do 802.1ad) >> >> >> ----- Mail original ----- >> >> De: "Andrew Thrift" <[email protected]> >> À: "Alexandre DERUMIER" <[email protected]> >> Cc: "Stefan Priebe - Profihost AG" <[email protected]>, >> [email protected] >> Envoyé: Lundi 13 Janvier 2014 22:42:02 >> Objet: Re: [pve-devel] [PATCH] Virtual vlan tagging to bridge interface >> >> >> Ok, so in my example of eth0,eth1,eth2,eth3---->bond0- >> --->bond0.101---->vmbr0----> vmbr0.201<----tap interface >> >> >> The packet is DOUBLE TAGGED with 0x8100 tags. So the outer tag (SVID) is 101 >> with an inner (CVID) tag of 201. >> >> >> 802.1ad support adds the capability to have an SVID of 0x88a8 with a CVID of >> 0x8100. Before this support was added you could only do QinQ using the >> "stacked" 0x8100 tags. >> >> >> >> >> >> >> >> On Mon, Jan 13, 2014 at 9:31 PM, Alexandre DERUMIER < [email protected] > >> wrote: >> >> >> Also,I see that support of 802.1ad has been added to kernel since 3.10 only. >> So how do is work before ? >> >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ad227ff89a7e6f05d07cd0acfd95ed3a24450ca >> >> >> >> # ip link add link eth0 eth0.1000 \ >> type vlan proto 802.1ad id 1000 >> >> ----- Mail original ----- >> >> De: "Alexandre DERUMIER" < [email protected] > >> >> À: "Stefan Priebe - Profihost AG" < [email protected] > >> Cc: [email protected] >> Envoyé: Lundi 13 Janvier 2014 09:10:59 >> >> >> Objet: Re: [pve-devel] [PATCH] Virtual vlan tagging to bridge interface >> >>>> this should explain it: >>>> http://en.wikipedia.org/wiki/IEEE_802.1ad >> >> Thanks, I understand now. >> >> So, for this setup: >> >> bond0.101---->vmbr0---->vmbr0.201<----tap interface >> >> >> when the packet from tap (tagged 201) is going out through bond0.101, >> >> what happen ? >> >> is the packet vlan retagged 101 ? >> or is the packet vlan 201 encapsuled in vlan101 ? >> >> >> >> >> >> ----- Mail original ----- >> >> De: "Stefan Priebe - Profihost AG" < [email protected] > >> À: "Alexandre DERUMIER" < [email protected] >, "Andrew Thrift" < >> [email protected] > >> Cc: [email protected] >> Envoyé: Lundi 13 Janvier 2014 08:24:19 >> Objet: Re: [pve-devel] [PATCH] Virtual vlan tagging to bridge interface >> >> Am 13.01.2014 07:54, schrieb Alexandre DERUMIER: >>>>> QinQ vlan tagging. >>> >>> can somebody explain me how qinq works exactly ? (I'm reading cisco doc, >>> but I'm not sure to understand how tagging is working exactly) >> >> this should explain it: >> http://en.wikipedia.org/wiki/IEEE_802.1ad >> >> >>> ----- Mail original ----- >>> >>> De: "Andrew Thrift" < [email protected] > >>> À: [email protected] >>> Envoyé: Lundi 13 Janvier 2014 01:33:24 >>> Objet: Re: [pve-devel] [PATCH] Virtual vlan tagging to bridge interface >>> >>> >>> FYI we are using vlan tagging on bridges with Proxmox in production for >>> over a year now, initially on 2.6.32 kernel and then on 3.10. We are using >>> Intel gigabit and 10gigabit adapters. >>> >>> >>> We posted the patches to the list a few months back, I believe these are >>> very similar to Alexandre's patches. We have a more complex config in that >>> we are also doing bonding and QinQ vlan tagging. >>> >>> >>> Our setup looks like this: >>> >>> >>> eth0,eth1,eth2,eth3---->bond0---->bond0.101---->vmbr0---->vmbr0.201<----tap >>> interface >>> >>> >>> >>> That is using an outer tag of 101 and an inner tag of 201. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Jan 11, 2014 at 7:59 AM, Alexandre DERUMIER < [email protected] > >>> wrote: >>> >>> >>> >>>>> If alexandre’s patch don’t work with any devices it isn’t really >>>>> interesting because it addressing other functionality and devices. I >>>>> checked the patch and it use the same problematic part with eth*, wifi* >>>>> and >>bond* check which fails with virtual devices like gre, ipsec,.. >>> >>> What do you mean by "don't work with any devices" ? >>> >>> My patch is to manage vlan tags on the bridge, not eth interface. >>> >>> eth0---->vmbr0<------tap interface >>> >>> vlan are tagged on tap interfaces plugged on vmbr0, with new "bridge" cmd. >>> (like an access port on a cisco switch) >>> and vlans are allowed to pass through eth0.(like a trunk port on cisco >>> switch) >>> >>> So I think it should work with gre,ipsec,...(But I don't have tested it >>> yet) >>> >>> >>> >>> >>> >>> >>> ----- Mail original ----- >>> >>> De: "Johannes Ernst" < [email protected] > >>> À: [email protected] >>> Envoyé: Vendredi 10 Janvier 2014 18:16:30 >>> >>> Objet: Re: [pve-devel] [PATCH] Virtual vlan tagging to bridge interface >>> >>> >>> >>> Thus, it’s a configuration issue and NOT a kernel issue. >>> >>> If alexandre’s patch don’t work with any devices it isn’t really >>> interesting because it addressing other functionality and devices. I >>> checked the patch and it use the same problematic part with eth*, wifi* and >>> bond* check which fails with virtual devices like gre, ipsec,.. >>> >>> Am 10.01.2014 um 17:18 schrieb Dietmar Maurer < [email protected] >: >>> >>>>> Sure? Do you have additional information? I think it's not correct and it >>>>> works! >>>> >>>> We tested that a few times (and failed), so nobody is keen to test that >>>> again. >>>> >>>> We currently try to use the new bridge VLAN features - that looks more >>>> promising (see patches from Alexandre). >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> pve-devel mailing list >>> [email protected] >>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >>> _______________________________________________ >>> pve-devel mailing list >>> [email protected] >>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >>> >>> >>> >>> >>> _______________________________________________ >>> pve-devel mailing list >>> [email protected] >>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >>> _______________________________________________ >>> pve-devel mailing list >>> [email protected] >>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >>> >> _______________________________________________ >> pve-devel mailing list >> [email protected] >> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >> _______________________________________________ >> pve-devel mailing list >> [email protected] >> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >> _______________________________________________ >> pve-devel mailing list >> [email protected] >> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list [email protected] http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
