Page MenuHomeVyOS Platform

Add support for VLAN-Aware bridges
Open, NormalPublicFEATURE REQUEST

Description

Newer linux kernels have gotten support for vlan aware bridges, that also support tagged and untagged switchports

Implementing this into vyos should be quite easy as there's not allot of parameteres to fiddle with to get this working.
I've implemented an example for this in http://github.com/runborg/vyatta-cfg-system/ that has the basic implementation for it. but for the moment does not have any safety-checks in place in the configuration scripts, and are also missing the op-mode scripts to get information out of the bridge.

As this is a extension of the interface bridge implementations existing today it is implemented in the old style syntax for cfg-mode templates, op-mode is a decision point if they should be implemented in the new or old style. if they are implemented in the old-style syntax all scripts has to be made in python and follow the new-style layout.

Enable vlan-aware bridge

interfaces {
  bridge br0 {
    vlan-aware
  }
}

This will activate vlan awareness for the bridge. from this point on everything will be blocking on members until the phy interface is configured with vlan information. it sets the vlan_filtering option the bridge to 1

Creating Vlan L3 interfaces

interfaces {
  bridge br0 {
    vif 3 {
      address 10.0.0.1/24
      ....
    }
  }
}

This is done exactly like on ethernet and bonding, it creates a vlan subinterface with the .1q tag specified in the vif statement
it is created as a normal br0.3 interface of the type vlan linked to the interface br0.
In the same step the vlan-awareness is added on the bridge so that traffic is accepted into this bridge vlan interface.

technically in the backend there is no connection between the vlan id and the sub-interface-id, but in vyos this is fixed to the same value.

Adding bridge on ethernet interface
to add this interface to a physical interface two new parameters are added to specify tagging and untagged vlan on the bridge interface.

interfaces {
  ethernet eth0 {
    bridge-group {
      bridge br0
      native-vlan 1
      tagged-vlan 2
      tagged-vlan 3
    }
  }
}

native-vlan and tagged-vlan here adds the bindings to the correct vlan inside the bridge.

Improvements

  • For not this is only implemented on physical ethernet interface, but there might be other places it needs to be implemented.
  • There is for now no op-mode changes, op-mode scripts for getting vlan/mac tables needs to be created for a full implementation.
  • As linux does not have a native understanding of vlans as eg. cisco and juniper switches do, you don't create a vlan in itself, but the vlan is created when the first binding to it is created on a interface. it might be that its better to create a list of "allowed" vlans on the br interface where you can name interfaces and so on.. that also makes it posible to make a tagged-vlan all on the physical interfaces to make it tag all created vlans. i've not decided on the best thing to do here yet.
  • There needs to be created checks so that the user don't configure ip parameters on the br interface itself when in vlan-aware mode. because when in this mode all ip parameters are configured inside the vlan submode (also for the native/pvid vlan) (this needs to be verified, but is at the moment my understanding)
  • you are able to create a brX vif Y interface without enabling vlan-aware bridge.. but that should not be supported. and a check has to be made to check that no vifs exists if vlan support is disabled.. and check for vlan-awareness on creation of a vif
  • The current implementation only adds the options needed for the basic implementation in vyatta-cfg-system, to get a working solution vyatta-quagga, vyatta-firewall, vyatta-cfg-qos and vyatta-ipv6-rtradv needs to be extended to create templates for these interfaces.

As a side not this is a router acting as a switch not a switch acting as a router and the switch part will not function exactly as on commercial switches.

This is a new feature it could potentially be merged back to crux, but i'm developing it for current and it's not my choice if this will be back-ported.

if anyone else wants to contribute to this you are all welcome to create PR's against my branch for now.
I'm also interested in comments and other input on this before i create a PR on current.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close

Event Timeline

Added a sidenote about switching on router and routing on switch

added not on old-style cfg-mode templates

syncer triaged this task as Normal priority.
syncer removed a project: VyOS 1.2 Crux.

There have been some time since i've managed to work on this now, and in the mean-time the whole ethernet/bridge sertup have been rewritten into python, so i need to restart my work on this implementation , also the bridge membership part is moved around in the cli so information in this ticket is out-of-sync with the current implementation and needs to be rethinked

It seems to be the same as the task list, but my basic realization is basically completed, see:

PR: https://github.com/vyos/vyos-1x/pull/594

@runar The latest image already supports VLAN aware bridge, so this task list can be closed

vyos@vyos:~$ show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
br1              -                                 u/u  Primary switching bridge
br1.1            192.168.0.1/24                    u/u  server
                 *************/64              
                 fc00:470:f1cd::1/64                    
br1.2            192.168.101.1/24                  u/u  terminal
                 *************/64              
                 fc00:470:f1cd:101::1/64                
eth0             -                                 u/D  Huawei Switch
eth1             -                                 u/u  DELL R410(Trunk)
eth2             -                                 u/u  DNS/SNMP
eth3             -                                 u/D  LAN
eth4             -                                 u/u  netgear R6260 AP
eth5             -                                 u/u  ISP WAN
lo               127.0.0.1/8                       u/u  loopback
                 ::1/128                                
pppoe0           100.64.10.62/32                   u/u  ISP
                 *************/64
vyos@vyos:~$ show br
bridge name     bridge id               STP enabled     interfaces
br1             8000.00982bf83f11       yes             eth0
                                                        eth1
                                                        eth2
                                                        eth3
                                                        eth4
vyos@vyos:~$ show interfaces bridge vlan 
port    vlan ids
eth0     2 PVID Egress Untagged

eth1     1
         2

eth2     1 PVID Egress Untagged

eth3     2 PVID Egress Untagged

eth4     2 PVID Egress Untagged

br1      1
         2

Hi @jack9603301 !

I'm sorry for the delay in response but i've now have had time to look at your initial implementation of vlan-aware bridges.
As a first implementation your implementation in T3042 looks it look and feels quite good!
But i've noticed a few things, and have some questions and suggestions:

  • the main bridge interface is not tied to vlan 1. but this i suppose will be fixed by: T3137? another issue here is that tying the main interface to vlan 1 will disallow the creation of av vif 1, this is supported on ethernet interfaces but will be a limitation here
  • There are no distinct way to enable vlan-aware'ness, it looks like it is activate when you enter the first native-vlan or allowed-vlan command on one of the member interfaces. i think this is a bit non-forgiving to the user as the state of the whole bridge is changed with one change on a member. i think this should be added as a command to explicit enable vlan-awareness. eg set int br br0 vlan-aware so the user is fully aware that he activates it. But this might be less important if the defaults will render to no change for the user if its activated or not.
  • to mimic non-vlan-aware bridges, if no native-vlan is defined on a member interface, it should default to vlan 1 as native vlan, and also no vlan should be in the allowed-vlan list.
  • There are no way to disable the use of native-vlan on a port (to make all vlan's tagged)
  • The vlan memberships on the brX interface in the bridge seems to be a combination of all allowed/native vlans on all member ports. from a first look, the vlan memberships on the brX interface should be controlled by the defined vif's on the brX interface. and only the vlans corresponding to a vif should be present on the brX interface. these should also be added on vif creation time and not when its added to a member interface. is this intentionally done and why is it done this way?

Apart from this this seems to be a good implementation :)

@runar If we assume that all untagged packets are members of VLAN 1 by default, then the behavior of the device bridge is actually the same as the behavior without VLAN awareness. In this case, set interfaces bridge br1 vlan-aware may not necessary

edit: Oh, I forgot the VLAN sub interface as a bridge

There is no need to use set interfaces bridge br1 vlan-aware, as soon as the vif node is present, it will be vlan aware. We should not randomly add all kinds of new CLI nodes.

  1. vif 1 should not be used as a required option for VLAN-aware bridges, it is only used when Layer 3 routing is required
  2. Are native-vlan and allowed-vlan necessary options for VLAN-aware bridges? Worth thinking about? After activating the VLAN-aware bridge function, if you do not set these two options, you can use the default VLAN parameters to run (all untagged packets are members of VLAN 1, which is in line with the behavior of most professional equipment)

Since VLAN-aware bridges allow the use of default VLAN configurations, and most devices have default VLANs, these options may not be necessary. Adding an explicit function switch does have the following benefits like @runar:

  1. The user realizes that he has explicitly enabled VLAN awareness
  2. For the configuration script, it is clear that the user enables the VLAN-aware bridge, so we can easily configure the default parameters of the VLAN-aware bridge on the interfaces that are not set with native-vlan and allowed-vlan, which is similar to most professional The equipment behaves the same. Lower the operating threshold and simplify the programming logic

@c-po

There is no need to use set interfaces bridge br1 vlan-aware, as soon as the vif node is present, it will be vlan aware. We should not randomly add all kinds of new CLI nodes.

If a vlan-aware bridge is used to only forward L2 traffic, or vlan 1 is a L3 and all other are L2, there will be no VIF with the current implementation. The reason for this is that vlan 1 will be configured on the parrent poX interface and not on a VIF. if the existence of a VIF will determine if the bridge will be a vlan-aware or not then it will not take these senarios into account.

possible scenarios:

  1. Only forwarding L2 (no ip)
  2. vlan 1 on L3 no L2 vlans, but vlan 1 should exit as tagged on a member port.
  3. vlan 1 on L3, other on L2
  4. vlan 2->4096 as L3 vlans

using the existence of a L3 vif will only take scenario 4) into account as the tree other will not need a VIF

As we discussed yesterday about enforcing the creation of a vif to enable forwarding of a vlan tag, this will also only work on scenario 2) and 4) and again because vlan 1 does not use a VIF.

I also do not think that this is randomly add all kinds of new CLI nodes., as this infact changes the operational mode of the bridge, we can hide the fact that it changes mode pretty well, but we cant make it behave exactly alike in all scenarios..

One think that is clear is that the current implementation is quite fragile as enabling the native-vlan or allowed-vlans commands on any of the bridge members will change the state of the bridge and possibly stop forwarding of traffic on ports without native-vlan or allowed-vlan configured.

Another question i'm asking myself is. What happens if we enforce the bridge to always have vlan-filtering enabled? at the first glance i do not think that there will be much difference in a non-vlan-aware bridge and as a non-vlan-aware bridge is working like a bridge with only vlan 1 and using it as native on all ports. but i have not enough information about whats happening inside the kernel to be sure what actually happens..

This is the reason why i would like to have a vlan-aware command to enable vlan-awareness on the bridge, doing so will make the user fully aware that this will be a vlan-aware bridge and we can set the default on all ports when changing from non-vlan-aware to vlan-aware to make it support all scenarios listed above.

@jack9603301

Are native-vlan and allowed-vlan necessary options for VLAN-aware bridges?

In the backend(the kernel) they are, but if no vlan information is supplied when adding a port it will default to vlan 1 PVID Egress Untagged(all packets untagged on the port goes to vlan 1) without anything else. but to be sure to reflect this on in all schenarios we could explicitly set it when the port is added. the default should be native-vlan 1 without any allowed-vlan's

@c-po @runar If there are no other problems, I will change the VLAN aware bridge code and update the description of T3137 in the near future