I am using OpenWrt on both my main router (connected to ISP modem/router, provides all DHCP/firewall/etc.) and a secondary router I'm using simply as a managed switch/access point.
Today I ended up troubleshooting an issue with one of the wired devices connect to the secondary (access point) router. I thought I had fully set it up and tested but apparently not thoroughly enough.
One switch port I had set to be "untagged" on VLAN 42 and "off" on all other VLANs. On the main router traffic on this VLAN should be served a DHCP address in 192.168.42.xx range (troubleshooting mnemonic) and then restricted to a corresponding firewall zone as well.
This seemed to work initially, but today I discovered the device had received a DHCP lease of 10.0.0.x from the main router, although it was unreachable from that subnet. Upon investigation I noticed that apparently I hadn't set up, on the secondary router, any br- network interface for the VLAN 42. Doing so seemed to resolve the misconfiguration but I'm curious what access this device would have had in the interim?
If an untagged VLAN is configured on the secondary router's switch port but the secondary router doesn't have a bridge interface configured for that VLAN, what tagging logic would be followed as the packets make their way to the main router?
You don't need the bridge interface. What you need is a trunk port to pass the vlan 42 frames tagged upstream to the main router. You can create an unmanaged interface for vlan 42 on the dumbAP, since you are not going to manage it from than interface.
Yes the cable from this switching device to the main router should be configured as a "trunk" cable with all VLANs of interest tagged, and none untagged. Then for user ports (to be connected to a non VLAN-aware device) make them untagged in one VLAN and off in all the others.
This is hardware switching. There is no need to expose extra VLANs that are merely passing through to the switching device CPU at all. One VLAN should be switched to the CPU for administrative login.
Sorry, I wasn't real clear in my first post. I did create an unmanaged interface ("Protocol: Unmanaged") but also checked the box to "Bridge interfaces" and selected what it now calls "Switch VLAN: eth0.42" as the interface.
IIRC before I created this interface it was labelling what I had set up on the switch something like "Software VLAN" instead. I guess what I'm not getting is the difference between an "interface" in this case (which I assume is a CPU thing) vs. just telling the switch itself how to handle VLANs on each port.
Why would it be a "software VLAN" when only configured on the switch and a "switch VLAN" when also configured as a software interface? UPDATE: I retested this with a new sample VLAN number and I must have misremembered… it shows up as a "Switch VLAN" in both cases [i.e. before creating a corresponding network interface], the only difference is it doesn't have a "(interface name)" label next to it at first.
Thanks. I almost have that with one exception: on the trunk port all expected VLANs are tagged except that I left VLAN 1 as "untagged".
I did this out of caution and/or expedience I suppose… thinking it would ease my setup and reduce the chance of getting locked out if something got misconfigured. But perhaps this is what caused the odd results?
So if I leave my CPU switch port (already all tagged) and also make my trunk port to be all VLANs as tagged (without exception) then should I even need to set up an unmanaged and/or bridged-to-the-ethN.x network interface for every expected VLAN?
I'm guessing maybe this is a DSA based device not the older style swconfig device
Possibly? I'm currently still running a build provided by a community member for a device that had some special installation pre-requisites:
TP-Link WPA8630P v2 (Int.)
Qualcomm Atheros QCA956X ver 1 rev 0
OpenWrt SNAPSHOT r14868-dd651e54cc
If it's a swconfig based setup, there will be a Network-Switch page. On this page you set up the hardware switch. Traffic between the Ethernet ports is handled by hardware. The hardware switch can examine VLAN tags to determine how to switch a packet, and also and add or remove tags from every packet to convert from tagged to untagged connections. This is done at full line speed.
It is only when a packet must interact with the OS that software is involved. That includes both using Linux services and transmitting / receiving by wifi. In that case the hardware switches the packet into the CPU port, and the kernel picks it up on an eth0.N interface, with N being the VLAN number.
In a DSA setup the individual ethernet jacks get their own pseudo interfaces and the kernel configs the switch chip to handle tags based on whether you are using tagged vlan interfaces etc