Page MenuHomeVyOS Platform

Support VLAN filter and VLAN sub-interface on the bridge
Closed, DuplicatePublicFEATURE REQUEST

Description

Please refer to the following link:

https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge/

This article shows how to turn on the vlan filter of the bridge under linux

Starting from linux 3.8, linux supports the opening of vlan filter on the bridge, this function can make the linux bridge close to the switching function of a real switch, and supports vlan awareness, with the SVI virtual interface, it can be on the same bridge Complete the VLAN isolation and routing process between VLANs without creating a separate network bridge for each VLAN network

Assuming that there is a bridge br0, the command to open a bridge's vlan filter is as follows:

ip link set br0 type bridge vlan_filtering 1
# echo 1 > /sys/class/net/br0/bridge/vlan_filtering
bridge  vlan add dev veth0 vid 100 pvid untagged master
bridge  vlan add dev veth1 vid 200 pvid untagged master

Set the VLAN sub-interface command as follows:

ip link add link br0 name br0.100 type vlan id 100
ip addr add 192.168.10.1/24 dev br0.100
ip link add link br0 name br0.200 type vlan id 200
ip addr add 192.168.11.1/24 dev br0.200

VM1 and VM2 Point to the default gateway:

ip route rep default via 192.168.10.1
ip route rep default via 192.168.11.1

Node: The above commands have not been tested and perfected, and come from external sources

Confirm the command as follows:

set interfaces bridge br1 member interface eth0 vlan 10 pvid
set interfaces bridge br1 member interface eth0 vlan 10 untagged
set interfaces bridge br1 vif 10 address 10.1.1.1/24

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)

Event Timeline

jack9603301 changed the task status from Open to In progress.Nov 3 2020, 11:03 AM
jack9603301 moved this task from Need Triage to In Progress on the VyOS 1.3 Equuleus board.

@c-po I think you may have referred to the wrong worksheet in your WiFi implementation? This task list is used to track and implement the VLAN filter of the bridge and the VLAN sub interface pairs of SVI

Hello everyone

I am considering the possibility of implementing a bridge vlan filter, but if the VLAN settings are bound to the bridge, it means that the following code needs to be executed:

bridge  vlan add dev veth1 vid 200 pvid untagged master

There is already a vif setting in the command line design. How to set the command of the bridge vlan filter is a big problem?

Use the following command?

set interfaces bridge br1 member interface eth0 vlan 101 pvid 
set interfaces bridge br1 member interface eth0 vlan 101 untagged
jack9603301 renamed this task from Support vlan filter and SVI on the bridge to Support VLAN filter and VLAN sub-interface on the bridge.Nov 4 2020, 10:20 AM
jack9603301 updated the task description. (Show Details)

Hmm.. i have a few sugestions about the syntax.
The linux kernel allows the user to have different pvid vlan's on ingress and egress of a router port,.

  • this is if you ask me not a common use case and i think we should merge the pvid(ingress) and untagged(egress) so that they will be ONE command..
  • my second note is that the syntax shown above is quite verbose when creating a lot of vlan's and interfaces. consider creating 20 vlans on 5 ports, that will make a minimum of 100 lines of code in the config.

i would like to purpose a different syntax like this:

# Enable vlan filtering
set interfaces bridge br1 vlan

# enables pvid and untagged for vlan 101
set interfaces bridge br1 member interface eth0 untagged 101   

# creates a vlan-mapping for vlan 2 and 4 -> 9 allowed as tagged out this interface  
set interfaces bridge br1 member interface eth0 tagged 2,4-9

# Create a vlan
set interfaces bridge br1 vif 2
  • if the untagged command is not enetered, a default of "vlan 1" should be applied. also possibly a untagged disable should be created to allow disabling a native/untagged vlan? the tagged command will be mapped over to the command: bridge vlan add vid 2,4-9 dev eth0 and removing it should disable all tagged vlans on the interface.
  • if a vlan is entered in the tagged vlan list, and also specified as the untagged vlan. the untagged configuration needs to take presence over the tagged configuration. e.g: entering untagged:10 and tagged:1-4094 will result in a configuration like:
# bridge -c vlan show
port    vlan ids
eth0    1-9
        10  PVID Egress Untagged
        11-4094
  • when doing this also make sure the main bridge interface, eg. set interfaces bridge br1 address without any vif's will be mapped to vlan 1 in the vlan table

@runar There is a question, that is, how to set the pvid flag according to this command format? Is the pvid flag automatically attached to the untagged option by default?

I feel that the mapping result of this command is not very normal:

set interfaces bridge br1 member interface eth0 tagged 2,4-9
# bridge -c vlan show
port    vlan ids
eth0    1-9
        10  PVID Egress Untagged
        11-4094

@runar The modified command is as follows:

# Enable vlan filtering
set interfaces bridge br1 vlan

# enables pvid and untagged for vlan 101
set interfaces bridge br1 member interface eth0 untagged 101   

# creates a vlan-mapping for vlan 2 and 4 -> 9 allowed as tagged out this interface  
set interfaces bridge br1 member interface eth0 tagged 2
set interfaces bridge br1 member interface eth0 tagged 4-9

# Create a vlan sub-interface
set interfaces bridge br1 vif 2

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

I wonder what happens if I have a eth0.10 bridge member interface? Also what should happen when the user jas eth0 and eth1.10 bridge members? should this feature still work or is it exclusively only for native non vlan interfaces?

Should existing configurations be migrated?

If two different vlan processing methods are not used for the same interface, then the two are not currently in conflict, unless the user sets vlan filter and eth0.10 on the same interface at the same time

When eth0 is set as the access mode of br1, such as:

set interfaces bridge br1 member interface eth0 untagged 10
set interfaces bridge br1 member interface eth0 tagged 11

Then, the user should not use the following commands to set the sub-interface of the interface, such as:

set interfaces ethernet eth0 vif 10
set interfaces ethernet eth0 vif 11

This operation of using two processing methods at the same time is meaningless. The setting of untagged will set the pvid flag on the specific physical interface of the bridge at the same time, which means that the data packets flowing into the interface will be forced if there is no VLAN tag attached Attach a vlan tag (that is, PVID). When data flows out, the untagged flag of the interface will remove the specific vlan tag

For the trunk interface, you can use the following command:

set interfaces bridge br1 member interface eth0 tagged 11

By design, this should allow specific vlan flags to pass through the physical interface without disassembling them

Should existing configurations be migrated?

Therefore, the answer to this question should be that there is no need to do any migration, and migration cannot be done. The two are different in vlan management. If the user needs, the user should re-modify the bridge configuration and interface configuration to manually migrate.

I really like the idea of this interface and alwaysed watned to implement it - but I lacked of time, so first thank you @jack9603301 for picking this up.

I propose the following syntax:

  • set interfaces bridge br0 member interface eth0 priority <prio>
  • set interfaces bridge br0 member interface eth0 cost <cost>
  • set interfaces bridge br0 member interface eth0 allowed-vlan < 1,2,4-6,10 >
  • set interfaces bridge br0 member interface eth0 native-vlan < vlan-id >
  • set interfaces bridge br0 vif < vif-id > ...
  • set interfaces bridge br0 vif-s < vif-id > ...

Constraints:

We either should strictly forbid configuring allows-vlan and native-vlan on vlan interfaces like eth0.10 or in generall disallow the use of vif subnode in bridge once there is a member interface which reflects a VyOS VLAN interface (eth0.10

set interfaces bridge br0 member interface eth0 allowed-vlan 2,4-9
set interfaces bridge br0 member interface eth0 native-vlan 101

The following writing methods can currently be used, such as:

set interfaces bridge br0 member interface eth0 untagged 101
set interfaces bridge br0 member interface eth0 tagged 2
set interfaces bridge br0 member interface eth0 tagged 4-9

At least this kind of syntax currently has no problem in the implementation of the execution command, which means executing the following code:

bridge vlan del dev eth0 vid 1
bridge vlan add dev eth0 vid 101 pvid untagged master
bridge vlan add dev eth0 vid 2 master
bridge vlan add dev eth0 vid 4-9 master

effect:

  1. This means that if the data packet of eth0 does not have the vlan 101 flag, then it will be marked with a 101, and when the data packet with the vlan 101 flag is ready to be transmitted through the device, the vlan flag will be removed
  2. Allow VLAN packets in the range of 2 and 4-9 to enter the bridge through eth0

I have read the syntax you suggested, and it is not much different from my current structure. The key is that I think the use of ʻuntagged` and tagged may be easier to understand than ʻallowed-vlan` and native-vlan

As I'm raised by A vendor starting with C and now switched to another vendor starting with A they both reference the function as native-vlan and allowed-vlan - this makes it easier for users which operate cross-platform.

OK, I understand, PR has been updated

@c-po i agree with using "native-vlan", but i dont agree on using "allowed-vlan".
"allowed-vlan" for me it dosn't actually describe that this vlan will be tagged on the port

Cisco: native-vlan and allowed-vlan
Juniper: native-vlan-id and vlan members
HP: untagged and tagged <-- but done from a vlan point of view, not on the port
Huawei: port default vlan and port trunk allow-pass vlan
Arista: trunk native vlan and trunk allowed vlan
cumulus: bridge access vlan and bridge trunk vlans

I would suggest a small poll on slack on what wording should be used :)

Hey, it seems that the big trouble now is the difference in the definition of the command line. If possible, I agree to conduct a survey to see your opinions.

I want to have native-vlan and allowed-vlan

erkin set Issue type to Feature (new functionality).Aug 29 2021, 12:22 PM
erkin removed a subscriber: Active contributors.