I just bumped my install (actually fresh install is more accurate) from 19.07.
My setup relies on 2 routers: WRT3200ACM serving as a gateway, firewall & everything and a Netgear that is mostly Wi-Fi AP + Ethernet switch.
Now I have couple subnets setup with various firewall policies, these include: LAN, IoT & Guest networks. On WRT3200ACM (19.07) side I have default VLAN 2 for WAN (eth1.2) and VLAN 1 for 3 LAN ports (1 LAN port uses IoT VLAN 3). Guest Wi-Fi VLAN is 4.
I bridged each of local VLANs to n+100 VIDs so I have also 101, 103 and 104. Cable that goes to Netgear has untagged VLAN 1 and tagged 101, 103 & 104.
During initial 19.07 setup a while back I didn't touch WAN (let it use DHCP from WRT3200ACM), changed subnet CIDR from default on LAN and made sure LAN ports get untagged 101 while Wi-FI networks get 101, 103 and 104 respectively. Long story short it worked and didn't break WAN for Netgear (used for SSH/LuCI access).
Now with 21.02 I was following the same steps with DSA, i.e. creating another bridge, assigned all 5 ports (4 LAN and 1 WAN), untagged and "Primary" for all 4 LANs on 101 while having 101, 103 and 104 as tagged on WAN. LAN ports working just fine but WAN setup would no longer work (it is sending discovers but nothing happens).
For DHCP to properly retrieve IP I would either have to disable VLANs on main router or I discovered I could change default "wan" to "wan.1" to have it working.
I'm not really understanding this behaviour as my expectations of having untagged traffic on Linksys side is that on Netgear I should be able to receive this traffic without explicitly specifying any VLANs. Am I missing something here in either how DSA or VLANs work? Some unticked box in config? Or is it a bug and I should get more logs/config dumps?
Cheers!
UPDATE: Just rolled back to 19.07.8, wanted to clarify that WAN interface is on eth0.2 but in switch VLAN 2 is untagged for WAN port. I couldn't get my head wrapped around VLAN to Wi-Fi mapping even though it's supposed to be easier with DSA but for me "legacy" VLAN to bridge mapping somehow made more sense.
if you want to give a try, this how i am doing - probably not the best but seems logical to me at least. maybe you can find it useful too. but if someone more educated in DSA says it is rubbish please don't put it on me.
warning: as changing network settings you may lose your connectivity, even lock you out! i strongly suggest to fire up a virtual x86 owrt in virtualbox/vmware and test it first what happens if you divert from default network config like this!
so, my approach is to mimic what swconfig did so far, thus:
create a bridge device called e.g. sw0, include all lan ports as members
create the necessary vlans, map the necessary physical ports to vlans, make sure PVID is set correctly
create bridges for all your vlans including the corresponding vlan related logical port only!
create the necessary interfaces with IP addressing as you wish on top of the corresponding bridge devices created in step 3.
assign your wireless wlans to the corresponding network, which is at this point is already VLAN aware.
for example:
you have a 4+1 physical port switch (4 LAN, 1 WAN) create the 1st bridge include all 4 lan ports
/etc/config/network
# step 1
config device
option name 'sw0'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
# step 2
# this will create sw0.1 and sw0.3 VLANs
# with the physical mapping
config device
option name 'sw0.1'
option type '8021q'
option ifname 'sw0'
option vid '1'
config device
option name 'sw0.3'
option type '8021q'
option ifname 'sw0'
option vid '3'
# all first 3 ports in vlan 1
# lan4 is trunk port, carrying all vlan traffic tagged
config bridge-vlan
option device 'sw0'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:t'
# no physical port assigned to VLAN3 for untagged traffic
# but lan4 carries VLAN3 traffic tagged as well
config bridge-vlan
option device 'sw0'
option vlan '3'
list ports 'lan4:t'
# step 3
# creating 'lan' bridge on top of sw0.1
# so all VLAN1 traffic is visible in this bridge
# and wlan will use this too basically
config device
option name 'br-lan'
option type 'bridge'
list ports 'sw0.1'
# 'guest' bridge
config device
option name 'br-guest'
option type 'bridge'
list ports 'sw0.3'
# step 4
# creating lan interface on top of br-lan
config interface 'lan'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.1.x'
option device 'br-lan'
# creating guest interface on top of br-guest
# this is a dumb AP so no need IP for br-guest
# all IP/DHCP/DNS service is on my other router
config interface 'guest'
option proto 'none'
option device 'br-guest'
# step 5
/etc/config/wireless
config wifi-iface 'wlan0'
option device 'radio0'
option mode 'ap'
option network 'lan'
config wifi-iface 'wlan1'
option device 'radio0'
option mode 'ap'
option network 'guest'
A dumb AP usually does not have a wan network because it doesn't route anything (it is dumb). Its networks are a combination of hardware switching and software bridging back to the main router. One of the networks (usually lan) would hold an IP on the main router's lan for administration of the dumb AP. The other guest type networks are unmanaged (proto none) to form layer 2 bridges to the main router.
On a DSA device if you put all the Ethernet ports into one bridge and make bridge-vlans within that bridge, it ends up being something like swconfig. Except to connect to a network interface the syntax bridgename.vlannr is used. Do not use portname.vlannr e.g. wan.1 is wrong. Instead it would be something like
config bridge-vlan
option vlan '102'
option device 'br-eth'
list ports 'wan:t'
config interface 'vlan102'
option device 'br-eth.102'
option proto 'none'
(here br-eth is the Ethernet bridge, this can be extended from the default br-lan by adding the wan port and changing the name to reduce confusion) Now when you create an AP and in the wireless config attach it with option network 'vlan102', it will end up bridged to packets tagged 102 on the wan physical port.
Check with wireshark that your main router is doing what you expect it to on the trunk cable. Combining tagged and untagged on the same cable should be avoided. Tag all VLANs on the trunk cable.
I'm not sure what you mean here. The hardware cannot rewrite VLAN tag numbers (i.e. something going in tagged 1 can either have its tag number 1 kept or removed, but it can't be re-tagged with a different number like 101 on the way out). Use one consistent number for each VLAN network. These numbers have to match in all of your switches.
@grrr2 thank you for explicitly showing me that 8021q devices are meant to be created with that approach, I've done that but felt somewhat off. As for locking myself out of course I've done that already, as I decided nothing can go wrong with switch to DSA, I'll sort issues out step by step… Well, it's hard without SSH/LuCI access.
As an extension of my first question: does use of 8021ad make any sense in typical home environment or is it more data center/backbone network targeted?
@mk24 good point, I felt I might have been overdoing it. Good point on keeping only a single network. Untagged traffic on that port was meant as a way to:
a) easily access internet from secondary router and behind when upgrading/factory resetting network config (yeah, setting one VLAN is not that much of a work on a second thought)
b) possibility to insert 1Gb switch between routers so traffic that goes to other Ethernet endpoints may skip dumb AP totally and it will only focus on WiFi traffic
This is what I have on main… totally unnecessary and even bad for performance as retagging in bridge make it go through additional CPU usage? Some in-line comments to show my understanding of your post.
config interface 'lan'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option ifname 'eth0.1 eth0.101' # keep only 101
config interface 'iot'
option type 'bridge'
option proto 'static'
option macaddr 'X'
list ipaddr '192.168.3.1/24'
option ifname 'eth0.3 eth1.103' # keep only 103
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '5t 3 2 0' # 0 goes to secondary router
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '5t' # Wi-Fi only (but either way Wi-Fi is attached to bridge, not to vlan so that sounds plain stupid not that I think of it)
option vid '3'
config switch_vlan
option device 'switch0'
option vlan '8'
option vid '101'
option description 'LAN'
option ports '5t 0t' # tagged 0 for main Wi-Fi network on secondary router
config switch_vlan
option device 'switch0'
option vlan '6'
option vid '103'
option description 'IoT secondary'
option ports '6t 1 0t' #just noticed it's not even consistent because instead of giving untagged over Ethernet on port 1 to smart home device on vid 3 I assigned it to 103…
The secondary device:
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1' # should become eth0.101
option proto 'static' # dhcp client for keeping management access
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.10.1'
config device 'lan_eth0_1_dev'
option name 'eth0.1'
option macaddr 'Z'
config interface 'wan' # get rid of it
option ifname 'eth0.2'
option proto 'dhcp'
config device 'wan_eth0_2_dev'
option name 'eth0.2'
option macaddr 'Y'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan # remove
option device 'switch0'
option vlan '1'
option vid '1'
option ports '6t'
config switch_vlan # remove
option device 'switch0'
option vlan '2'
option vid '2'
option ports '6t 4'
config switch_vlan
option device 'switch0'
option vlan '3'
option vid '103'
option ports '6t 4t'
config switch_vlan
option device 'switch0'
option vlan '5'
option vid '101'
option ports '6t 3 1 0 4t'
config interface 'lan101' # skip as we're already doing managed DHCP client bridge to which Wi-Fi can be attached
option proto 'none'
option ifname 'eth0.101'
option type 'bridge'
config interface 'iot103' # kept for dumb AP
option proto 'none'
option ifname 'eth0.103'
option type 'bridge'
I'll start by simplifying using 19.07.8 and then if I feel adventurous I shall pull another R6220 from the drawer (mighty cheap but quite powerful devices in terms of both Gb switch and AC frequencies, loving them ain't gonna lie) and try to do the "proper" DSA-enabled setup.
Still a little afraid of performance penalty with DSA on multicore device such as WRT3200ACM.
this is not DSA config. are you sure using 21.02.x and you started from scratch, i.e. did not keep settings during sysupgrade as the release note suggests?
because a main + dump ap setup is kind of simple (after some try&error loops...) the main idea behind is:
your main router will do routing and provide services like DNS/DHCP, fw (access to WAN)
the dump ap is just a physical extension of main router's networks, providing no services at all (can stop fw + dnsmasq)
main and dump ap is wired connected (via phyiscal ports, lets call the main router port: lan4) so the networks you configure on main router should be virtualized (=> VLAN) and they can be extended via lan4 all VLANs tagged. on the dumb ap side, all your networks are coming in (via physical port wired connected to main, let's call it lan4 as well) marked with proper tags so just need to split based on VLAN tags into the proper local network. which local networks are logically the same networks as on main.
so logicially
main:[ members of a network "lan" on main who are wired or wireless clients are bridged together can talk to each other, and even to members connected on ap untagged ] <------> via main lan4 they are tagged <-----> cable <-----> via lan4 on ap, still tagged ----> ap: [ based on tag ap will split traffic into right network ] [network members on "lan" can talk each other on ap and main untagged ]
using VLAN tagging mechanism you basically extend many logical networks through various physical devices with a single cable.
Yeah, sorry for not getting back. Like I mentioned first step was to simplify the config and only then migrate to DSA. 2 days ago I motivated myself because I needed openfortivpn.
So now both routers are on 21.02:
Main (I skip over VPN entries):
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option device 'br-lan.101'
config device
option name 'wan'
option ipv6 '0'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
option auto '0'
config bridge-vlan
option device 'br-lan'
option vlan '101'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan4:t*'
config bridge-vlan
option device 'br-lan'
option vlan '103'
list ports 'lan3:u*'
list ports 'lan4:t'
config bridge-vlan
option device 'br-lan'
option vlan '104'
list ports 'lan4:t'
config interface 'iot'
option proto 'static'
list ipaddr '192.168.3.1/24'
option device 'br-lan.103'
config interface 'syf'
option proto 'static'
option ipaddr '192.168.4.1'
option netmask '255.255.255.0'
option device 'br-lan.104'
Dumb:
config interface 'lan'
option proto 'dhcp'
option device 'br-vlan.101'
config device
option type 'bridge'
option name 'br-vlan'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'wan'
option ipv6 '0'
option mtu '1500'
config bridge-vlan
option device 'br-vlan'
option vlan '101'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'
list ports 'wan:t*'
config bridge-vlan
option device 'br-vlan'
option vlan '103'
list ports 'wan:t'
config bridge-vlan
option device 'br-vlan'
option vlan '104'
list ports 'wan:t'
config interface 'iot'
option proto 'none'
option device 'br-vlan.103'
option type 'bridge'
config interface 'syf'
option proto 'none'
option device 'br-vlan.104'
option type 'bridge'
