Wtf is "Ethernet switch: eth0"?

Can somebody who speaks dsa explain to me what exactly is eth0 and how this thing works?
I don't want advice on how to make it work, I want to understand what's going on.

In old pre-dsa devices, there was a CPU(eth0) in the switch config that had to be included in every vlan, tagged. Or well, that's what I used to do in any case.

In dsa devices, there's a cryptic "Ethernet switch: eth0" network device that just sits there, isn't part of the default bridge and you can make vlans bridging the rest of the ports without specifying anything regarding this eth0 device and it all works just fine.

Can somebody please give me a clear explanation on how this all works?
What is eth0 in DSA, what was eth0 pre-DSA. How and when should it be used or not used?

And yes, I did read everything relevant I could find in the documentation, but as you probably know it's all very messy and largely outdated. Couldn't find anything concrete to clarify things.


1 Like

Your router has a CPU and a switch.

The ethernet "cables" that reach the CPU are called eth0, eth1, etc. On a typical router, eth0 is the connection from the CPU to the switch; on some devices, eth1 is connected directly to the WAN. The switch is also connected to the LAN ports, and sometimes to the WAN port too.

Since all the traffic from the switch reaches the CPU on eth0, when you want to know on which port is arriving each packet, you need to use VLANs between the switch and the CPU.


Ok, so if this is still the switch port going to the cpu, why is tagging vlans on it not necessary now? Why was it necessary previously?

And wtf is this?

I'm trying to wrap my head around what's going on in that post which I randomly found by searching on the subject and it's not making any sense.

1 Like

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 ] 


                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.


Greatly done. Thanks for the effort!


I marked your post as solution because it's the best explanation I've seen on the subject and I've searched for this stuff for quite some time. Thank you.

So, to clarify practically, throw all switch ports under one bridge, make a bunch of vlans with various configs that autospawn vlan bridges. And this automatically creates the flows, whether you bother attaching any interfaces to them or not, correct?

Essentially every autospawned vlan-bridge is an unmanaged interface?

So if you want to mix dumb bridges and routing, just make a few vlans for the dumb bridges you want and the autocreated network devices will take care of their traffic, no need to set an unmanaged interface for them.

Then just make interfaces for the vlans you want to actively route between.

no need to set an unmanaged interface for them

Correct, unless you need WiFi on a VLAN. To add a wifi AP on a specific VLAN, you have to first setup an (unmanaged) interface with br-lan.X and then select it in the AP settings.


Excellent. Thank you once more.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.