Total obsolete VLAN documentation


I can point to completely invalid VLAN documentation here:

and on many other places (czech, english)

This is completely invalid for TOS 4 and 5. I have spent hours to find a bug before i have found notice on forum in deep history of this post:

which drived me to right DSA way.

Seems that directives with

config switch_vlan

doesn’t work anymore. But Doc page mention only change of the WAN from the eth1 to eth2, nothing more.

Please notice these facts in documentation, or better, fix this to reflect correct way how to configure VLANS on TOS 4 and TOS5. It can save time to other people who try to configure VLAN on turris/MOX

Thank you.


Well, that page starts with a big warning stating it’s only for 3.x. (For about a half a year.)

But from next line:

In Turris OS 4.x, the WAN is connected to eth2 interface and for LAN, there are interfaces eth0 and eth1.

You can easily get imagination that problem is only switch of the eth1 to the eth2 for wlan (What i exactly did in my yesterday try). By my opinion can be better to mention explicitly that whole page is obsolete and VLANs have to be configured by complete different way., not by use

config switch_vlan


And of course, light point on new config directives for VLANs on Turris can be better.

In Czech version (where I have started) notice about TOS4 change is missing completely

Then here is many ways how to get wrong…

Primary I have created this thread to save time to other MOX/Turris users to help them find that this way points directly to the wall…

1 Like

All well since long known and the partial lack of UI features been documented

and documentation been suggested [suggestion] explain (advanced) 802.1q protocol management (aka VLAN tagging) for DSA systems (#22) · Issues · Turris / user-docs · GitLab

Seems that attempts were made in the forum early on

Is that really true? That VLAN ID works only for small subset? VLAN ID 0 - 15?

Don’t expect buyers to read through really old forum threads… yes, it is known for a long time, but even in this long time there was no real guidance created on how to address dsa correctly. The forum thread I linked was in fact a try by an experienced user who finally gave up on this topic.

Its really sad our device has hardware ressources we cannot use.

Yes and no. When setting it via ui (/etc/config/network ), it’s limited to those 16 IDs, but when addressing dsa directly via command-line, you can use the full subset.

Not sure whether that was matter of the outdated TOS3, as far as I know that limitation is not applicable in TOS5, neither through creating virtual kernel interfaces on top of the physical once, e.g. eth2.107 or through DSA with the bridge command.

Actually, I think it was a hardware restriction rather than software.

That is not clear to me, which hardware components are not usable?

Notwithstanding DSA is still in development and maturing as those patches Git - openwrt/openwrt.git/commit evidence. And those are currently only in OpenWrt Master (kernel 5.4), not sure whether being backported either there or in TOS.

This invalid configuration you found in community documentation. If you are going to check that documentation, you would see that there is exists new official documentation, which you can found here Turris Documentation and it is mention in this thread:

Community asked is in the past for documentation, where they can add, edit and modify articles. So, feel free to register, and start writing.

VLANs requires some knowledge and that’s why you can setup it in LuCI and in CLI for now. We are using DSA since Turris OS 4.0 instead of swconfig and recently if I am not mistaken OpenWrt did the same change recently and without providing migration script and once they release a new version, you will be on your own if you would be using it.

There’s a way how to configure them and you will find it here:

Correct me, if I’m wrong, but that method (via configuration /etc/config/ network) does not invoke dsa, but software-level VLAN, right?

I’m thinking where did you see such wrong information. Many hardware chips are capable to handle 802.1Q. In the specs, there is a VLAN identifier (VID) and it’s 12 bits(^2) means there is possibility to allow to set 4096 VLANs (0-4095) including those two reserved.


and that is not what DSA is about at all.

As long as there is no clear how-to for it, it is not usable for me. I’m highly depending on VLAN and won’t proceed as long as there is no guide available.

So you seem to know, what it is about - would you write a clear how-to please?

There is quite a bit of upstream documentation, this one [PATCH v3 3/3] net: dsa: mv88e6xxx: add switchdev VLAN operations - Vivien Didelot might explain best the transition from what been and what is now

A configuration like “1t 2t 3t 4u” for VLAN 10 is achieved like this:

# bridge vlan add dev swp1 vid 10 master
# bridge vlan add dev swp2 vid 10 master
# bridge vlan add dev swp3 vid 10 master
# bridge vlan add dev swp4 vid 10 master untagged pvid

This calls port_vlan_add() for each command. Removing the port 3 from
VLAN 10 is done with:

# bridge vlan del dev swp3 vid 10

Or net: dsa: mv88e6xxx: add support for VLAN Table Unit []

Below is an example of what can be done with this patchset.

"VID 550: 1t 3u"
"VID 1000: 2t"
"VID 1200: 2t 4t"

The VLAN setup above can be achieved with the following bridge commands:

bridge vlan add vid 550 dev swp1 master
bridge vlan add vid 550 dev swp3 master untagged pvid
bridge vlan add vid 1000 dev swp2 master
bridge vlan add vid 1200 dev swp2 master
bridge vlan add vid 1200 dev swp4 master

Removing the port 1 from VLAN 550 is done with:

bridge vlan del vid 550 dev swp1


1 Like

The thing is that I would be more or less repeating what is mentioned in the upstream documentation.

With UI now catering only for

which is the same what was prior to DSA the user is basically left to read, learn and understand how DSA works and how to configure it, just 3 pointers perhaps

  • the CPU ports (since TOS4. being eth0 & eth1) facing the switch are not not exposed to DSA and therefore are not configurable/taggable with the bridge command
  • DSA is driver based tagging and offloads the task from the CPU to the switch chip
  • any/all DSA tag management is currently done through the bridge command

I do not see how I would be able to add value to the available documentation that been written by folks more knowledgeable about it. Stumbled in the forum across this, if it helps any

Community asked is in the past for documentation, where they can add, edit and modify articles. So, feel free to register, and start writing.

How can I register and contribute ? I am now at this moment at corporate firewall @ work that blocks some element on pages so I can not see where to register to ?
I got few things that I posted just here at the forum but it may deserve to be in official documentation.


1 Like

I am using TOS 4.0.5 with multiple VLANS in production. I can‘t tell how and where traffic goes through (CPU or switch chip). But I can tell you that you can set up VLANs using this method. Interfaces LANX are DSA ports, so creating Software VLANs on it will configure them (at least somehow).

If you want to create an additional VLAN, (e.g. an untrusted Network), just create a new network interface in LuCI and bridge it over the LAN ports you want in „physical settings“ (e.g. LAN0.5 and LAN1.5 if you want it on LAN ports 0 and 1 with vid 5). If you want to have an an untagged port you just add LANX to the bridge (e.g. you can add LAN0 and LAN1.5 to the bridge, so traffic on LAN0 will be untagged but traffic on LAN1 will be tagged with vid 5).

I then set up one subnet for every “VLAN Interface“ and set up traffic rules using forwarding rules in firewall between those subnets.

I read through multiple threads on this forum stating that LuCI/UCI configuration invokes ip command (which lacks some functionality regarding VLANs), not bridge command. But as far as I can tell I can‘t see any disadvantages using LuCI, at least in my SOHO setup… I get gigabit speed inside subnets and between subnets and they are isolated. vids seem to be added as I can communicate on tagged ports with linux clients attached to it sending tagged traffic. And clients on untagged ports can only reach the subnet is configured for this port.

With VLAN filtering such overhead can be saved, administrative as well as as for the CPU/kernel having to filter packets VLAN filter support on bridge | Red Hat Developer.

Maybe, I just wanted to point out that VLANs are still usable without noticable performance degradation in SOHO setups, because I often read in this forum that VLANs would be unusable since TOS 4… :slight_smile: