Alexandre,
Am I right in thinking that for 4x bridges each with a different SVID
(101,102,103,104) that the config would look like this ?
auto vmbrcustomer1
iface vmbrcustomer1 inet manual
bridge_vlan_aware yes
bridge_ports customer1lp
bridge_stp off
bridge_fd 0
pre-up ip link add dev customer1l type veth peer name customer1lp
post-up ip link set customer1l up
auto vmbrcustomer2
iface vmbrcustomer2 inet manual
bridge_vlan_aware yes
bridge_ports customer2lp
bridge_stp off
bridge_fd 0
pre-up ip link add dev customer2l type veth peer name customer2lp
post-up ip link set customer2l up
auto vmbrcustomer3
iface vmbrcustomer3 inet manual
bridge_vlan_aware yes
bridge_ports customer3lp
bridge_stp off
bridge_fd 0
pre-up ip link add dev customer3l type veth peer name customer3lp
post-up ip link set customer3l up
auto vmbrcustomer4
iface vmbrcustomer4 inet manual
bridge_vlan_aware yes
bridge_ports customer4lp
bridge_stp off
bridge_fd 0
pre-up ip link add dev customer4l type veth peer name customer4lp
post-up ip link set customer4l up
auto vmbr0
iface vmbr0 inet manual
bridge_vlan_aware yes
bridge_ports eth0 customer1l customer2l customer3l customer4l
bridge_stp off
bridge_fd 0
post-up echo 0x88a8 > /sys/class/net/vmbr0/bridge/vlan_protocol
post-up bridge vlan add dev customer1l vid 101 pvid untagged
post-up bridge vlan add dev customer2l vid 102 pvid untagged
post-up bridge vlan add dev customer3l vid 103 pvid untagged
post-up bridge vlan add dev customer4l vid 104 pvid untagged
On Wed, Aug 5, 2015 at 11:54 AM, Andrew Thrift <and...@networklabs.co.nz>
wrote:
> Hi Alexandre,
>
> This looks like it should work.
>
> Something to be aware of, QinQ does not always have an outer tag with
> ethertype 0x88a8, it can also have a tag of 0x8100 or 0x9100 depending on
> the implementation.
>
> For example:
>
> 0x88a8--0x8100 Outer-tag (SVID) of 0x88a8, Inner-tag (CVID) of 0x8100
> 0x8100--0x8100 Outer-tag (SVID) of 0x8100, Inner-tag (CVID) of 0x8100
> 0x9100--0x8100 Outer-tag (SVID) of 0x9100, Inner-tag (CVID) of 0x8100
>
> We typically use "stacked" tags of 0x8100 so both the outer and inner tag
> are 0x8100, this seems to be the most compatible method and is supported by
> all vendors that I am aware of.
>
>
>
>
> On Wed, Aug 5, 2015 at 12:25 AM, Alexandre DERUMIER <aderum...@odiso.com>
> wrote:
>
>> This seem to work.
>> (I'm not sure about tcpdump result when vlan are stacked)
>>
>>
>> auto vmbrcustomer1
>> iface vmbrcustomer1 inet manual
>> bridge_vlan_aware yes
>> bridge_ports customer1lp
>> bridge_stp off
>> bridge_fd 0
>> pre-up ip link add dev customer1l type veth peer name customer1lp
>> post-up ip link set customer1l up
>>
>>
>> auto vmbr0
>> iface vmbr0 inet manual
>> bridge_vlan_aware yes
>> bridge_ports eth0 customer1l
>> bridge_stp off
>> bridge_fd 0
>> post-up echo 0x88a8 > /sys/class/net/vmbr0/bridge/vlan_protocol
>> post-up bridge vlan add dev customer1l vid 10 pvid untagged
>>
>>
>> ----- Mail original -----
>> De: "aderumier" <aderum...@odiso.com>
>> À: "Andrew Thrift" <and...@networklabs.co.nz>
>> Cc: "pve-devel" <pve-devel@pve.proxmox.com>
>> Envoyé: Mardi 4 Août 2015 14:02:46
>> Objet: Re: [pve-devel] [PATCH] tap_plug : add support for vlan aware
>> linux bridge
>>
>> Another way,
>>
>> but I'm not sure it's working, is to tag 802.1ad on the physical interface
>>
>>
>>
>>
>> eth0.10---->vmbrcustomer<--(vlanX)------tapX
>>
>>
>>
>> auto vmbrcustomer1
>> iface vmbrcustomer1 inet manual
>> bridge_vlan_aware yes
>> bridge_ports eth0.10
>> bridge_stp off
>> bridge_fd 0
>> pre-up ip link add link eth0 eth0.10 type vlan proto 802.1ad id 10
>>
>>
>>
>>
>> ----- Mail original -----
>> De: "aderumier" <aderum...@odiso.com>
>> À: "Andrew Thrift" <and...@networklabs.co.nz>
>> Cc: "pve-devel" <pve-devel@pve.proxmox.com>
>> Envoyé: Mardi 4 Août 2015 12:22:47
>> Objet: Re: [pve-devel] [PATCH] tap_plug : add support for vlan aware
>> linux bridge
>>
>> >>Hi Alexandre,
>> Hi,
>>
>> >>We also use QinQ and have submitted patches for the previous network
>> implementation that made use of a "bridge in bridge" design to achieve the
>> QinQ functionality.
>>
>> They are also a new way to implement q-in-q with vlan aware bridge
>>
>> http://www.spinics.net/lists/linux-ethernet-bridging/msg05514.html
>>
>> +----+ +-------+p/u +------+ +----+ +--+
>> |eth0|--|802.1ad|----veth----|802.1Q|--|vnet|--|VM|
>> +----+ |bridge | |bridge| +----+ +--+
>> +-------+ +------+
>>
>> p/u: pvid/untagged
>>
>>
>>
>> Currently we have implemented 802.1Q bridge.
>>
>> for qinq, we need to create a root bridge, with 802.1ad enabled, linked
>> through a veth pair to 802.1Q bridge.
>>
>>
>> The qinq bridge is managed exactly in the same way than 802.1ad, but it's
>> enabled with
>> echo 0x88a8 > /sys/class/net/XXX/bridge/vlan_protocol
>>
>> for example
>> ------------
>>
>> eth0----vmbr0--(vlan10)<---brigelink-------bridgelinkpeer---->vmbrcustomer<--(vlanX)------tapX
>>
>>
>> brctl addbr vmbr0
>> echo 0x88a8 > /sys/class/net/vmbr0/bridge/vlan_protocol
>> ip link add dev bridgelink type veth peer name bridgelinkpeer
>> brctl addif vmbr0 bridgelink
>> brctl addif vmbrcustomer1 bridgelinkpeer
>> bridge vlan add dev bridgelink vid 10 pvid untagged
>>
>>
>> something like that
>>
>>
>> I can try to make a patch, but I don't have hardware which support q-in-q
>> for testing.
>>
>>
>>
>>
>> ----- Mail original -----
>> De: "Andrew Thrift" <and...@networklabs.co.nz>
>> À: "aderumier" <aderum...@odiso.com>
>> Cc: "pve-devel" <pve-devel@pve.proxmox.com>
>> Envoyé: Mardi 4 Août 2015 10:49:26
>> Objet: Re: [pve-devel] [PATCH] tap_plug : add support for vlan aware
>> linux bridge
>>
>> Hi Alexandre,
>> We also use QinQ and have submitted patches for the previous network
>> implementation that made use of a "bridge in bridge" design to achieve the
>> QinQ functionality.
>>
>> The new vlan aware bridge implementation will be a lot cleaner.
>>
>> When your patches are ready we will test them and provide feedback.
>>
>>
>> Thanks,
>>
>>
>>
>> Andrew
>>
>> On Tue, Jul 28, 2015 at 2:09 AM, Alexandre DERUMIER < aderum...@odiso.com
>> > wrote:
>>
>>
>> does somebody have tested my vlan bridges patches ? (note that that need
>> iproute2 from debian sid, for vlan ranges)
>>
>> It's working really fine here, I'm looking to add a patch for Q-in-Q
>> bridge too. (I think Stefan Priebe use them)
>>
>>
>>
>>
>>
>> ----- Mail original -----
>> De: "aderumier" < aderum...@odiso.com >
>> À: "Wolfgang Bumiller" < w.bumil...@proxmox.com >
>> Cc: "pve-devel" < pve-devel@pve.proxmox.com >
>> Envoyé: Vendredi 24 Juillet 2015 18:49:18
>> Objet: Re: [pve-devel] [PATCH] tap_plug : add support for vlan aware
>> linux bridge
>>
>> >>Why is `bridge_add_interface` now restricted to the firewall-else
>> >>branch?
>>
>> I manage it like openvswitch,
>>
>> vlan tagging is always done on the main bridge, not firewall bridge.
>>
>>
>> > + if ($firewall) {
>> > + &$create_firewall_bridge_linux($iface, $bridge, $tag);
>>
>> create_firewall_bridge_linux($iface, $bridge, $tag)
>> have
>>
>> - &$bridge_add_interface($bridge, $vethfwpeer);
>> + &$bridge_add_interface($bridge, $vethfwpeer, $tag); #tag on the main
>> bridge
>> - return $fwbr;
>> + &$bridge_add_interface($fwbr, $iface); # add vm tap interface on
>> fwbridge without vlan tag
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ----- Mail original -----
>> De: "Wolfgang Bumiller" < w.bumil...@proxmox.com >
>> À: "aderumier" < aderum...@odiso.com >
>> Cc: "pve-devel" < pve-devel@pve.proxmox.com >
>> Envoyé: Vendredi 24 Juillet 2015 15:20:06
>> Objet: Re: [pve-devel] [PATCH] tap_plug : add support for vlan aware
>> linux bridge
>>
>> On Fri, Jul 24, 2015 at 01:52:59PM +0200, Alexandre Derumier wrote:
>> > - $newbridge = &$create_firewall_bridge_linux($iface, $newbridge) if
>> $firewall;
>> > + if (!$vlan_aware) {
>> > + my $newbridge = activate_bridge_vlan($bridge, $tag);
>> > + copy_bridge_config($bridge, $newbridge) if $bridge ne $newbridge;
>> > + $tag = undef;
>> > + }
>> > +
>> > + if ($firewall) {
>> > + &$create_firewall_bridge_linux($iface, $bridge, $tag);
>> > + } else {
>> > + &$bridge_add_interface($bridge, $iface, $tag);
>> > + }
>> >
>> > - &$bridge_add_interface($newbridge, $iface);
>>
>>
>> Why is `bridge_add_interface` now restricted to the firewall-else
>> branch?
>> _______________________________________________
>> pve-devel mailing list
>> 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
>>
>>
>>
>> _______________________________________________
>> pve-devel mailing list
>> 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
>>
>>
>
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
