[pve-devel] [PATCH] Virtual vlan tagging to bridge interface
Alexandre DERUMIER
aderumier at odiso.com
Fri Jan 17 09:35:48 CET 2014
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" <s.priebe at profihost.ag>
À: "Alexandre DERUMIER" <aderumier at odiso.com>, "Johannes Ernst" <info at filemedia.de>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
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" <info at filemedia.de>
> À: "Alexandre DERUMIER" <aderumier at odiso.com>
> 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 <aderumier at odiso.com>:
>
>>>> 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" <andrew at networklabs.co.nz>
>> À: "Alexandre DERUMIER" <aderumier at odiso.com>
>> Cc: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag>, pve-devel at pve.proxmox.com
>> 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 < aderumier at odiso.com > 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" < aderumier at odiso.com >
>>
>> À: "Stefan Priebe - Profihost AG" < s.priebe at profihost.ag >
>> Cc: pve-devel at pve.proxmox.com
>> 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" < s.priebe at profihost.ag >
>> À: "Alexandre DERUMIER" < aderumier at odiso.com >, "Andrew Thrift" < andrew at networklabs.co.nz >
>> Cc: pve-devel at pve.proxmox.com
>> 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" < andrew at networklabs.co.nz >
>>> À: pve-devel at pve.proxmox.com
>>> 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 < aderumier at odiso.com > 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" < info at filemedia.de >
>>> À: pve-devel at pve.proxmox.com
>>> 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 < dietmar at proxmox.com >:
>>>
>>>>> 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
>>> pve-devel at pve.proxmox.com
>>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>> _______________________________________________
>>> pve-devel mailing list
>>> pve-devel at pve.proxmox.com
>>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> pve-devel mailing list
>>> pve-devel at pve.proxmox.com
>>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>> _______________________________________________
>>> pve-devel mailing list
>>> pve-devel at pve.proxmox.com
>>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>>
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel at pve.proxmox.com
>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel at pve.proxmox.com
>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel at pve.proxmox.com
>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
More information about the pve-devel
mailing list