Ok... next test...
reconnect the router to the 'Tik switch.
On the 'Tik, configure one port as an access port for VLAN 20. That is: untagged + PVID VLAN 20 on a 'Tik port. Then plug in your test computer to that port.
The purpose of this test is to verify that the VLAN is operating properly on the router and through the switch.
Not shure how to set PVID.
See there are probably a few ways to configure vlans.
One way is to create "virtual" interfaces from vlans on other interfaces. I mean you have interface ethernet4. You create virtual interface smth dev name ethernet4.33 vlanid 33 parent ethernet4. Now you have two different interfaces ethernet4 and ethernet4.33 which you can bridge with other interfaces or do anything else.
I did it on openbsd.
I did it mikrotik.
I did it on regular linux.
It is simple and makes sense.
What i cant understand is this current config on openwrt device.
So yes, i have a few ports on that mikrotik that have 192.168.20.0 traffic untagged.
I confirm when i connect test notebook to this ports it gets ip 192.168.20.0/24 from dhcp.
I don't know how to configure Mikrotik devices, but it sounds like you've already done the effective test I was looking for:
So good... we know the router + 'Tik is working.
Let's edit one thing to reduce confusion -- rename config interface 'vlan10-aka-vlan20' so that it looks like this:
config interface 'vlan20'
option device 'br-lan.20'
option proto 'none'
Then restart this device and try again. If it doesn't work, please post the complete network configuration again.
Both (192.168.10.0 on port lan2) and (192.168.20.0 on ports lan3 and wan) are working now!
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fde9:54b5:7e19::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'wan'
config interface 'lan'
option device 'br-lan.1'
option proto 'static'
option ipaddr '192.168.10.249'
option netmask '255.255.255.0'
option gateway '192.168.10.1'
list dns '192.168.10.1'
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
config bridge-vlan
option device 'br-lan'
option vlan '20'
list ports 'lan1:t'
list ports 'lan3:u*'
list ports 'wan:u*'
config interface 'vlan20'
option device 'br-lan.20'
option proto 'none'
And finally there are no errors in luci on pages "Network > Interfaces" and "Network > Routes"
Also created a few wifi aps on different networks. Tested. Its working.
Thank you!!
And maybe you know how to create interfaces from vlans and bridge them? Like i said in previous post.
Because i dont understand current config. Why bridge everything and then create another bridges with vlans? It's counter-intuitive. Then those tagged/untagged-with-primary for each interface for each vlan except vlan-id-1 is not even real... Too complex. Just cant wrap my head around it.
Switches don't rewrite the VLAN number on packets as they pass through. They can change from untagged packets on a certain port to tagged within the switch matrix (this is called an access port, connected to a PC etc that is not VLAN-aware) but not be tagged on both sides with a different number.
That is the nature of how DSA is implemented in the Linux kernel. A port can only be in one bridge. Bridge-vlans are used to segregate traffic within the bridge and tag incoming/outgoing packets. This structure is amenable to optimizing traffic flow by taking advantage of hardware switching.
Awesome! I wonder if the problem was my fault with the vlan10-aka-vlan20 interface name... seems like the dashes messed it up. I was beginning to question that which is why I suggested you rename it in the last comment. Glad we did that!
Can you describe your goal here? Normally, you don't want to bridge different intefaces/VLANs as it defeats the purpose of VLANs... but maybe we're using slightly different terms.
The DSA syntax takes a while to wrap your head around... it will make sense if you do this enough, though.
DSA treats each physical port as an individual entity. A port may only be a member of a single interface or bridge. Therefore, where there is overlap, we create a single bridge that encompasses all relevant ports.
Then, we create bridge-VLANs -- this allows us to specify the VLAN-port-membership and the tagged/untagged status.
For each VLAN, we include only the relevant ports. The :t option specifies that a VLAN is tagged on that port. When we use :u* it means that the VLAN is untagged on that port (and PVID/default/native -- all untagged traffic on ingress/egress will be associated with that VLAN).
Meanwhile...
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! 
if you mean switches=bridges then yes i get it. Please see below
Maybe.
Why? Those vlans are just a few additional bytes to mark packets as they are belong to another "imaginary" cable that is parallel to real cable. And when i say create virtual interface from vlan-id-x with parent interface if-x - i mean just create that abstract interface. If it see packet on real cable with correct vlan-id-x then packet now belongs to this interface.
For example we have host pca with interface etha, host pcb with interfaces ethb1. You connect them with cable. Now they can talk to each other over the network let say 192.168.1.0.
But you want more. You add vlans. One way of thinking about it is this - assume all packets inside pca or pcb are without any vlan marks, then you create "virtual" interfaces for each vlan which will deal with vlans.
This way you don't need to create bridge-vlans and think about should you set tag or not. You deal with interfaces and don't care about vlans. Maybe it is tun, macvlan, ethernet, anything. If some particular interface was created from vlan on another interface - then this "virtual" interface will take care of vlan. All happens automagically.
I have this setup on my desktop - one cable from mikrotik switch with tagged and untagged traffic, some bridges. Now if i want to create virtual vm - i can add macvlan interface to one or other bridge (depending which 192.168.x.0/24 network i want to use), and vm will get real ip on this network, fully accessible from other computers or host machine. (Interesting observation - i haven't seen anyone else using this. Most setups use nat for virtual machines, or host can't access guest vms).
I used systemd-networkd for this, works reasonably fine.
I think the issue is that you are conflating L2 and L3 connections -- see the OSI model.
At the ethernet switching (L2) layer, we work with MAC addresses, not IP addresses. If we have multiple VLANs/subnets, we need to specify the VLAN to which a packet belongs using the 802.1q tagging, because the IP address isn't relevant at L2.
An untagged network doesn't carry these tags, but as a result, there can only be one untagged network on any given port/cable because otherwise the VLAN membership would be ambiguous since there would be no identifiers to keep them separated. The tags are interpreted by the switch such that the switch keeps them separate.
It isn't until L3 that we deal with IP addresses. And yes, you associate your L2 VLAN with an L3 network interface complete with an IP address/subnet at that layer. But this is now the routing layer.
It is important to remember that an all-in-once wifi router device is actually 3 devices in 1: a router/firewall (L3), an L2 ethernet switch, and a wifi AP (also L2). So at the risk of being slightly pedantic, when we are talking about VLANs, it only applies to the L2 ethernet functions. Often in our every-day discussions, we use VLANs interchangeably with "multiple subnets" -- but technically they are different things entirely.
And with the DSA syntax, we're really only talking to the switch itself within the all-in-one wifi router device.
As for the bridges and the bridge-VLANs...
Within OpenWrt, there are two ways to address the switch, depending on the underlying hardware: DSA or swconfig (it is an XOR -- devices that use DSA cannot use swconfig and vice versa). The transition to DSA stared with 21.02 the number of targets using DSA has increased with each subsequent version of OpenWrt (I think ideally all devices with built-in switches will eventually use DSA).
In general, each OS/or vendor has a slightly different method of configuring the switch fabric for VLANs, so the terminology and configuration syntax will differ, but the end result is that ethernet frames have 802.1q tags added for tagged VLANs (or no tag for the untagged network) on any given port for egress/ingress.
Nah. Because terminology is muddy. Maybe if i call all the packets that should be in the subnet 192.168.10.1 "bananas" it will be less confusing. And "tomatoes" for other subnet. So for example i have bananas untagged and tomatoes tagged vlan id 20 in one cable, or create a bridge with all my bananas.
I suspect this "switch" and surrounding firmware and software are somehow different from "real" (one rj45 - one chip) ethernet interfaces. Because again, I used this approach with non-openwrt OSes with non-switch interfaces and it worked (and mikrotik switch also works).
So is this some DSA limitation or maybe there is bug somewhere?
It can be confusing at times, but L2 and L3 terminology, when applied precisely, is not muddy.
Your fruits are defined at layer 3 (subnets). The ports and the underlying switch, operate at L2. VLANs and tagged/untagged ethernet frames apply to layer 2, but not to layer 3. Yes, there is a 'connection' between the L2/VLAN and L3 functions, but to be precise, the L2 stuff is what is happening at the switch layer, and the subnet/IP happens above that.
The idea behind DSA is that it allows each port to be treated independently and it abstracts the underlying switch functions and configuration. So, yes, the syntax is actually telling the OS how to configure the switch, not directly instructing the switch to do things.
I've used a bunch of managed switches from different vendors and/or operating systems. They each have slightly different implementations at the user-level with respect to the switch configuration syntax and methods. DSA is just another approach, but it is one that will likely become more common because the adoption into OpenWrt is in response to the fact that it originated in the upstream linux stack.
No these are not bugs. The 'recipe' I provided is not a work-around, it is the way it was designed to work.
It just takes a bit of time to work with it and wrap your head around it. Believe it or not, I actually learned how to do the DSA config without even using DSA hardware -- I just read the documentation/tutorials and some user threads, and then it suddenly became very clear to me how it works. At first, I was quite confused since I was used to the old swconfig methods... but now, it's pretty much second nature.
Nah. I mean all the traffic. Maybe there is device which connected to bananas but it have completely different ip addr like 10.12.13.14/18. And on my pc connected to bananas i can temporarily add second ip like 10.12.55.66/18 and communicate with that device. Or even without ip address like mikrotik's mac telnet.
But i can't reach tomatoes (unless the router decides so and forwards some packets).
Having two IP subnets co-mingle on the same physical connection is not a recommended practice, as there is no security against someone changing their IP and gaining access to the other network. That is why VLANs exist.
That was an example. It happens sometimes i need this. Like today i reset my openwrt device a dozen times. Or camera installed somewhere. Or wifi relay. You have a device with borked config and it is less work to temporarily add another ip address than to go grab a ladder and notebook or to shutdown power to ceiling lights, rip relay from the wall and connect with usb-ttl adapter.
Oh you know what? I took my initial config, deleted my bridge-vlan workaround. And used 'wan' interface as a trunk port. And it is working!
config device
option type 'bridge'
option name 'br-lan10'
list ports 'wan'
list ports 'lan1'
list ports 'lan2'
config device
option type '8021q'
option ifname 'wan'
option vid '20'
option name 'wan.20'
config device
option type 'bridge'
option name 'br-lan20'
list ports 'wan.20'
list ports 'lan3'
config interface 'owrt_brlan10'
option device 'br-lan10'
option proto 'static'
option ipaddr '192.168.10.249'
option netmask '255.255.255.0'
option gateway '192.168.10.1'
list dns '192.168.10.1'
config interface 'owrt_brlan20'
option proto 'static'
option device 'br-lan20'
option proto 'none'
So 'wan' port is real ethernet device and ports 'lan1', 'lan2', 'lan3' belongs to switch.
This config would not work if i needed vlans on switch ports.
I think this should be added somewhere in faq. All ethernet ports are equal but some ethernet ports are more equal than others. And if (your ethernet port belongs to switch) and (you want there tagged traffic) then you must use DSA config bridge-vlan.
Maybe, but not necessarily... the wan port could be connected to the switch, too. Like I said, the ports are treated individually in DSA, so it isn't immediately obvious.
There are several ways in which the ports may be implemented:
That is interesting.
Any links for more info like this?
From the Ubiquiti EdgeRouters:
And the example of 2 CPU ethernet ports connecting to the same switch -- not an EdgeRouter, but a TP-Link Archer C7 (default config example). The logical ports (in swconfig terms) 0 and 6 correspond to eth1 and eth0 respectively.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.