Alright, this was a process but I think I finally got through it. Following up with the final outcome to help me brain dump everything in a referenceable format.
First, my end goal was 3 separate vLANs across both a wired and wireless network. The tricky part was that I was using flashed Lumas as my APs throughout and these Lumas are not supported with DSA yet. So although my main router has DSA support, I had to also implement non-DSA configuration which I was finding confusing and frustrating because even when I thought I was following everything as I was supposed to, it still wasn't working.
Turns out, that's because any device with a target of ipq40xx has some very tricky weirdness with how the internal switch architecture maps and associates vLANs across the ports. This is actually well discussed but I never came across it because I wasn't searching on ipq40xx or qca87xx.
From those three forum postings, I was able to kind of figure out how to possibly hack things together to get things working. There is a highly detailed comment that goes into how/why/what can be done but it's still well over my head. I have concerns this hack will cause network issues as mentioned in the comment, but I will have to try to better understand that another time.
So the gist is, ipq40xx devices have a switch that highjacks the WAN and LAN ports (eth0 and eth1 in my case) and vLANs 1 & 2 by default. For example, with my Luma's, the eth1 and eth0 ports pass-through traffic by default, but OpenWRT does not recognize them as separate devices even though the switch does. My Lumas' default /etc/config/network file only show eth0, even though each device clearly has a eth1 that passes traffic to eth0 by default.
If I ran swconfig, Lumas default tagging would look like this:
VLAN 1:
vid: 1
ports: 0t 1 2 3 4
VLAN 2:
vid: 2
ports: 0t 5
So I am using VIDs of 10,20,30 so I could ignore and not use 1 & 2 easily. Through the links above and testing the output of swconfig by connecting/disconnecting ethernet to the ports I was able to determine that 0t references the internal cpu switch and 3 somehow is tied into eth1 while 5 is eth0. Still not 100% certain, but that allowed me to do the following configuration that finally got my vLANs working properly across multiple Lumas.
The one thing to note is that port 5 is eth0 and I will use that to tie-in a device to a specific vLAN. So the Luma has trunked connections to the switch so it brings the 3 vLANs across for use by their wireless radios, but I then just need to use remaining eth0 port like it's its own 1-port switch tying the connected device to the appropriate vLAN.
Take note of the difference between what I have set in the /etc/config/network
file and what swconfig
shows ipq40xx/qca87xx as actually allowing:
/etc/config/network
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 'fd94:b2eb:40d1::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0.10'
list ports 'eth1.10'
option ipv6 '0'
config interface 'lan'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.1.2'
option gateway '192.168.1.1'
list dns '192.168.1.1'
option device 'br-lan'
config device
option name 'br-devices'
option type 'bridge'
list ports 'eth0.20'
list ports 'eth1.20'
option ifname 'eth0'
option vid '20'
option ipv6 '0'
config interface 'DEVICES'
option device 'br-devices'
option proto 'none'
config device
option name 'br-guest'
option type 'bridge'
list ports 'eth0.30'
list ports 'eth1.30'
option ifname 'eth0'
option vid '30'
option ipv6 '0'
config interface 'Guest'
option device 'br-guest'
option proto 'none'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '10'
option ports '0t 1 2 3 4'
config switch_vlan
option device 'switch0'
option vlan '20'
option ports '0t 1 2 3 4 5'
config switch_vlan
option device 'switch0'
option vlan '30'
option ports '0t 1 2 3 4'
config switch_port
option device 'switch0'
option port '0'
option pvid '10'
config switch_port
option device 'switch0'
option port '3'
option pvid '10'
swconfig output
VLAN 1:
vid: 1
ports: 0t 1t 2t 3t 4t
VLAN 2:
vid: 2
ports: 0t 5t
VLAN 10:
vid: 10
ports: 0t 1t 2t 3 4t
VLAN 20:
vid: 20
ports: 0t 1t 2t 3t 4t 5
VLAN 30:
vid: 30
ports: 0t 1 2 3t 4
So weird. It's like it has a tagging mind of its own. And maybe one day I can better understand what is going on, but for now, even with the hijacking this seems to work just fine for what I need.
ToDo:
- Finish testing to make sure expected behavior of the vLANs is actually what is happening, so far so good.
- Look more into how to migrate my Luma's boards in the DSA pull request
If anyone is still reading this, thank you for the feedback. Starting from ground zero learning all of these was not fun for a little while until I was nudged in the right direction.