I am having trouble getting VLANs working with OpenWRT (running in an x86 VM right now) and a TP-Link TLSG108PE managed switch. Ports 1-4 are attached to Unifi Wifi APs that handle VLAN tagging. I think they are trunk ports. Port 5, is for untagged traffic (e.g., printer and a wired desktop) on my "home" VLAN (VID 16), port 6 is for untagged traffic on my IoT VLAN (VID 17), and port 7 is for untagged traffic on my Guest VLAN (VID 18). I think these are access ports. Port 8, is attached to eth3 on my OpenWRT router. I am not sure if that is a trunk port or something else. The switch also has VID 1, which I am not using, but deleting it causes me to lose access to the switch.
When I plug an untagged device (e.g., a desktop) into port 5 (or 6 or 7) of the switch, it is unable to get an IP address. I have not yet checked to see if the tagged ports work with the APs. The OpenWRT VM also has additional untagged NICs that seem to be doing what I expect: eth0 (VID 16), eth1 (VID 17) eth2 (VID 18) and eth4 (WAN).
The VLAN configuration appears to be correct. It is possible that the issue lies with the way the VM/host interacts with the actual hardware, but I'm not convinced about that yet.
Let's see your complete config from the router:
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
I suspect that the problem is here... you probably don't want to have everything part of a bridge like this.
Typically, these 4 port cards are setup as individually routed ports, not part of a switch.
Before making any changes, make a backup of your current config. This way, if I'm wrong, you can easily get back to where you were.
Delete this:
Next, create bridges using dotted notation like this:
config device
option name 'br-home'
option type 'bridge'
list ports 'eth0'
list ports 'eth3.16'
config device
option name 'br-iot'
option type 'bridge'
list ports 'eth1'
list ports 'eth3.17'
config device
option name 'br-guest'
option type 'bridge'
list ports 'eth2'
list ports 'eth3.18'
then, modify your network interfaces to use the bridges:
But this card has 4 routed ports, not part of a switch. Yes, you can bridge them and use bridge vlan configurations, but it is not necessary here. And I find that it is often easier and more predictable to use dotted notation when working with individually routed ports (that are not part of a switch).
@danielshub - have you implemented my suggested changes? Did things work as expected for eth0-2? and what about your switch?
I have not tried your suggestion yet. I will after work.
The hardware has two physical NICs that are passed through to the OpenWRT VM. One NIC is connected to my modem and the other to the physical TP-link switch. The other 3 NICs are virtual bridges created in the host with a "tap" provided to the VM. I am not sure that these virtual NICs have anything to do with my problem. I can delete them and simply have two physical NICs passed through to the VM.
So if they are distinct virtual bridges, they are indeed individually routed virtual ports and therefore should be treated as such.. typically this means using dotted notation. DSA doesn't apply here because there isn't a swtich. FWIW, though, I believe that the bridge-vlan approach could be used even though your system doesn't actually have anything to do with DSA. But, as I said earlier, I think dotted notation is the optimal approach here.
Regrding the 3 vitual NICs -- are they used for virtual connections to other VMs?
No, I don't think they are having any impact here. But becaue you are using each virtual NIC for exactly one untagged network, I would not bridge them together and use bridge-VLANs... it's just easier and cleaner with the syntax I have presented.
User error. My original configuration works if you get all the bits to stick at the same time. The TP-Link switch likes to reset the PVIDs when changing the VLAN settings. The warning is right there at the bottom of the PVID page.
The UX on these switches is not great (pretty, but not intuitive)... yet another reason why I avoid the entry level smart switches from TP-Link. But glad you figured that one out and fixed it!
