Total obsolete VLAN documentation

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 https://doc.turris.cz/doc/en/start 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.

Indeed

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 https://lore.kernel.org/patchwork/patch/575746/ 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 https://lwn.net/Articles/650480/

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

Else

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst

https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html

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 https://docs.turris.cz/ ?
I got few things that I posted just here at the forum but it may deserve to be in official documentation.

This?
https://wiki.turris.cz/doc/en/howto/start

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 https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge/.

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:

2 Likes

with

the kernel advises the DSA driver that kernel has management control over the 802.1Q tags on the DSA interfaces. That in consequence leads to this sort of routing and processing of 802.1Q tagged packages on the Lan segment (Lan port just picked randomly)


Letting instead DSA manage control over the 802.1Q tags on the DSA interfaces the traffic on the Lan segments stays within the swtich fabric instead


This is just for the TO. Now If you go with Mox and one or tow of the E modules one would likely prefer any 802.1Q tagged traffic to remain with the switch fabric and not being bounced up and down to the CPU for processing.

3 Likes

Thas old doc and yes I have registration there at https://wiki.turris.cz/doc/en/start but I had new one on my mind which is here https://docs.turris.cz/ and it is obviously on different platform and I dont see login there. Is it really the same ?

No,

This is reserved for the (new) documentation provided by the manufacturer only and sans community section.

I thought it is like that and could not find where to register for new docs.

@anon82920800 Hi, I have a question then, not clear here for me.

Does use Turris Omnia DSA and chip switching when i use

config interface 'lan'
        option type 'bridge'
        option vlan '1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.1.1'
        option bridge_empty '1'
        list ifname 'lan0.10'
        list ifname 'lan1'
................

Or not ? If not, can I get HW Offloading for switching on the Omnia ?

Thank you.

Just to ensure, because that has not been asked before (or maybe I haven’t noticed):

  1. When wanting VLAN-ID 10 tagged on WAN should I use
bridge vlan add dev eth2 vid 10 master

as eth2 has slaves wan/sfp or

bridge vlan add dev wan vid 10 master

because DSA uses directly slave interfaces?

  1. The benefits of hardware-offloading are clear to me. But does using DSA (bridge/ip) provide any benefit over kernel activities, when I only have one interface?
    Example 1: MOX with only one ethernet-jack at all available (eth0)
    Example 2: Turris Omnia with only one connected ethernet cable in lan4

As no one answered I will answer the question myself: There is very low to no benefit in invoking hardware offloading, if TO or MOX is only used as an access point and therefore only connected via 1 single ehternet cable.
Reason: The traffic is in this scenario always directly adressed to or comes from the router and needs then to pass CPU (as it has to be processed).
Therefore in this case the existing VLAN documentation (which can be found here: https://docs.turris.cz/basics/luci/vlan/luci-vlan/) shows everything needed to create an VLAN.