OpenWrt DSA VLAN Configuration: Bridge VLANs Explained

2026年10月4日 LOG admin

OpenWrt 21.02 replaced the old swconfig model with DSA — the Linux kernel's Distributed Switch Architecture — and the change rewrote how VLANs are configured. Instead of a switch/switch_vlan block describing a hardware switch, each physical port is now its own Linux interface and VLANs are declared as bridge-vlan sections on a bridge device. If you have been copying OpenWrt VLAN guides written before 2021, this is why nothing works. Here is the DSA model, explained through the configurations you actually need.

The Mental Model

Under DSA, the switch chip presents lan1, lan2, wan and so on as separate network interfaces. You create a bridge across the ports you want to switch together, then describe VLAN membership as bridge-VLAN entries. Because the bridge is a Linux device, the router's own CPU interface participates in a VLAN by attaching to a subinterface such as br-lan.1. That is the DSA equivalent of the old eth0.1.

# /etc/config/network - single network, all LAN ports
config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4'

config bridge-vlan
    option device 'br-lan'
    option vlan '1'
    list ports 'lan1'
    list ports 'lan2'

config bridge-vlan
    option device 'br-lan'
    option vlan '2'
    list ports 'lan3'
    list ports 'lan4'

config interface 'home'
    option device 'br-lan.1'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'

config interface 'office'
    option device 'br-lan.2'
    option proto 'static'
    option ipaddr '192.168.13.1'
    option netmask '255.255.255.0'

Ports listed without a flag are untagged members — access ports. That is the simple case: two physically separate networks, no tagging anywhere.

Tagged Uplinks and Trunks

When one port carries multiple VLANs to another switch or access point, tag it with the :t suffix:

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4'

config bridge-vlan
    option device 'br-lan'
    option vlan '1'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4:t'

config bridge-vlan
    option device 'br-lan'
    option vlan '2'
    list ports 'lan4:u*'

config interface 'lan'
    option device 'br-lan.1'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'

Here lan4 is a trunk carrying VLAN 1 tagged; lan4:u* in VLAN 2 also makes it the untagged primary member (PVID) of VLAN 2. Mixing the two on one port is legal and common, but only one VLAN may be untagged on a given port — the switch does not have a second PVID to give you.

The Port Flag Syntax

Flag	Meaning
`lan1`	Untagged member (access port for that VLAN)
`lan1:t`	Tagged member (trunk carrying the VLAN with a tag)
`lan1:u*`	Untagged AND the port's PVID for this VLAN
`lan1:*`	PVID member without untagging semantics
`lan1:-`	Port explicitly excluded from the VLAN

Attaching the Router (CPU) to a VLAN

If the router itself should route or serve DHCP in a VLAN, give that VLAN a local participation by naming the bridge subinterface as an interface device, as in the br-lan.2 example above. If you deliberately do not want the router in that VLAN, set option local '0' on the bridge-vlan and it becomes a pure L2 pipe between ports.

config bridge-vlan
    option device 'switch'
    option vlan '90'
    list ports 'lan1:u*'
    list ports 'lan2:u*'
    list ports 'lan4:u*'
    option local '0'

Firewall Zones for Each New VLAN

A new network is not automatically allowed anywhere. Add a zone and forward rules in /etc/config/firewall:

config zone
    option name 'iot'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    list network 'iot'

config forwarding
    option src 'iot'
    option dest 'wan'

config rule
    option name 'Allow-DHCP-IoT'
    option src 'iot'
    option proto 'udp'
    option dest_port '67'
    option target 'ACCEPT'

Then confirm clients get leases before you start tuning: if the VLAN interface exists but the zone is missing, guests associate to Wi-Fi and never receive an address.

Wireless VLANs

With DSA you no longer must bridge a wireless interface to a tagged ethX.X side interface. Assign the SSID to a network directly in /etc/config/wireless and the wireless interface joins the correct bridge VLAN automatically:

config wifi-iface 'guest_radio0'
    option device 'radio0'
    option mode 'ap'
    option ssid 'Guest-WiFi'
    option encryption 'psk2'
    option key 'changeme'
    option network 'guest'

Applying and Verifying

# Config changes to network should be applied from the console if you are remote
uci commit network
service network restart      # or /etc/init.d/network reload

# Inspect the real kernel state
bridge link show
bridge vlan show
ip -d link show br-lan

bridge vlan show is the ground truth: it prints every port with its VLAN IDs and the PVID Egress Untagged flags, which is exactly what you wrote in the config translated into kernel terms. If a VLAN is missing here, the config did not parse and the network service log on the console will say why.

The Safety Rule

Configure VLAN changes over a serial console or with a physical fallback port you have deliberately left as an untagged member of the management VLAN. A tagged-only management VLAN plus a remote SSH session is the most reliable way to lock yourself out of your own router.