In the non-DSA setup, you have a utility to configure the switch - swconfig, and you also have physical ethernet interfaces on the SoC. On devices with switches that support DSA, you don't have swconfig but instead see additional network interfaces created by the kernel, in most cases defined in the .dts (Open Firmware Device Tree Source) files.
In non-DSA setup, in the standard setup, you commonly have routers with one network interface connected to WAN (let's say eth1) and another connected to the switch (let's say eth0), or you would have only one network interface eth0 and all physical ports connected through a switch:
lan1 2 3 4 wan
eth0 -------- | | | | | | not connected
0 1 2 3 4 5 6 7
[ switch with 8 ports ]
or
lan1 2 3 4 wan
eth0 -------- | | | | | | ------ eth1
0 1 2 3 4
[ switch with 5 ports ]
In the non-DSA case with eth0 and eth1, you wouldn't need any VLAN setup, as the lan switch can be configured to not use VLANs at all, or you can enable VLAN tagging and forwarding like any L2 managed switch.
In the non-DSA case with only eth0, if you want to have a router with separate WAN, you would need to have at least two VLANs configured, both tagged on switch internal port connected to the eth0 interface, one untagged on lan1,2,3,4 and the other untagged on the wan physical ports - a default in many OpenWRT devices.
DSA changes this and allows for much more diverse setups *
.* some rare cases have DSA_TAG_PROTO_NONE or DSA_TAG_PROTO_8021Q which complicate things, and are better left for another post.
With DSA, you still have normal ethernet interfaces on the SoC and still have a switch (the hardware didn't change), but in addition to eth0, linux kernel automatically creates virtual network interfaces for each user-facing port defined in the .dts. Then, you will see additional network interfaces - commonly named lan1, lan2, lan3, lan4 and wan. They work similarly but differently to what vlan interfaces in the network stack already do: when you send a packet through one of them, they are first wrapped in the switch-specific DSA_TAG and sent via eth0. When a packet arrives on eth0 and has a DSA_TAG, it gets stolen, the tag is stripped and it looks like it arrived from one of the virtual interfaces - similarly to what vlan virtual interfaces do.
But, importantly, in addition to stripping and adding DSA_TAGs, if you add two DSA virtual interfaces belonging to the same switch or to interconnected switches (if you have more than one switch) to the same bridge, the kernel isn't going to forward packets between these ports, but instead configure the switch to forward them:
- let's say you have lan1, 2, 3, 4 and wan on one switch connected to the cpu via eth0
- let's say you create a bridge between lan1, 2, 3 and 4 and keep wan not in any bridge (default for many DSA OpenWRT devices
The DSA code will then configure forwarding between lan1, 2, 3 and 4 but keep wan separate (even without configuring any VLANs) - thus allowing more flexibility than the old setup.
Since DSA code is not magic, it can't work if you try creating virtual vlan interfaces on top of the dsa virtual interfaces - let's say lan1.2, lan2.2 and then adding them to a bridge. This will allow devices on lan1 with vlan2 to talk to the router, and will allow devices on lan2 vlan2 to talk to the router but won't enable forwarding between these.
Instead, the way VLANs are meant to be configured with DSA is Bridge VLAN Filtering - a feature of OpenWRT 21.03. There, you configure VLANs inside the base bridge itself (in a similar way to what swconfig did), and it maps that configuration to the switch, while still allowing you not include all ports in the bridge.
Bridges with VLAN filtering also allow you to add ports that are not on the switch (let's say eth1 connected to the WAN port), and it will do the right thing - forward packets between switch ports and eth1. You can even add lan1, lan2 and eth1(wan) to one bridge, and separately add lan3 and lan4 to another bridge, and it will do what you expect.
Importantly, with DSA, you don't have to touch eth0 as everything can be done directly with the virtual DSA interfaces.