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.