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?
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:
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.
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.
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:
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
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.
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.
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…
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)
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.
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 ?
Just to ensure, because that has not been asked before (or maybe I haven’t noticed):
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?
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
