The £20 Switch That Forced My Hand: L2, L3 and the Multi-SSID Field Fix

We’ve reached the finale, and it’s fitting that the whole series — which began with me being cheap about a router — ends with me being cheap about a switch. I am nothing if not consistent.

If you read Part 4, you’ll remember the cliffhanger. Omada attaches its wireless rules to the SSID, which had nudged me toward a separate Wi-Fi network per child and per IoT device. Functional, but inelegant. The clean way to do it was to sort devices into VLANs and write my rules against the VLAN instead.

I knew exactly which device should make that possible: my switch. And I’d bought a switch that, it turned out, couldn’t.

Meet the TL-SG108E

The TP-Link TL-SG108E is a little eight-port “Easy Smart” switch. It’s cheap, it’s reliable, it’s everywhere, and for a lot of homelabs it’s the perfect first managed switch. I want to be clear: it’s a good little box. It just wasn’t the right box for what I was about to ask of it.

The trap is that on paper, it looks like it should be. It supports VLANs! It says so right there — MTU VLAN, port-based VLAN, and 802.1Q VLAN, the proper tagging standard, with PVID settings and the full VLAN 1–4094 range. (TP-Link 802.1Q VLAN guide.) When you’re shopping on price and you see “802.1Q VLAN supported,” you tick the box and move on.

I moved on. I should have read two more lines of the spec sheet.

The two things it couldn’t do

1. It’s a Layer 2 switch. No routing.

The L2 vs L3 thing, quickly: A Layer 2 switch moves traffic around within networks based on MAC addresses (the hardware ID burned into every network device). A Layer 3 switch can also route between networks — it understands IP addresses and can pass traffic from one VLAN to another by itself. L2 is a junction; L3 is a junction with a traffic warden who can also send you down a different road.

The TL-SG108E is firmly L2. It has no routing capability and can’t route between VLANs on its own. (Search summary of TL-SG108E capabilities.) In my setup that’s survivable — the Omada gateway does the inter-VLAN routing — but it’s the first sign that this switch is a simpler animal than its spec sheet implies. It also has a genuine security wrinkle: VLAN 1 is the default management VLAN, it can’t be removed, and it has to be a member of every port, so the switch’s own management interface is reachable from every port. Not ideal.

2. The dealbreaker: no MAC-based VLAN assignment.

This was the one that actually sank my plan. I wanted devices to land in the right VLAN automatically based on their identity — their MAC address — so a given tablet was always in the Kids VLAN no matter which port or access point it touched. That feature is called MAC-based VLAN, and the TL-SG108E doesn’t have it. Its VLANs are port-based and 802.1Q tag-based — you assign VLANs to physical ports, not to devices. (TP-Link 802.1Q VLAN guide.)

For a wired setup where each port has a known device, port-based VLANs are fine. But my kids’ devices and smart TVs are wireless. They don’t live on a port — they roam between access points. Without the ability to say “this MAC address belongs in this VLAN,” I had no clean, switch-level way to sort wireless devices into VLAN lanes by identity.

So the elegant design — sort everyone into VLANs, write rules against VLANs, broadcast one tidy Wi-Fi network — was dead on arrival. Killed by a feature I didn’t buy because I didn’t know to look for it. Classic me. Classic this entire series, frankly.

The field fix

Here’s where it gets fun, because being blocked is where homelabbing actually starts. I couldn’t sort devices into VLANs by MAC at the switch. But I could control behaviour by SSID at the Omada controller — that’s exactly what Part 4 established.

So I leaned all the way into it. The field fix — and yes, I’m calling it a field fix, because “MacGyver’d” is more honest and “jank” is just rude to a network that works — looks like this:

• One SSID per child. Each child’s devices connect to their own named Wi-Fi network, and each SSID carries its own bedtime schedule (the two-rule ACL sandwich from Part 4) and its own content filtering.
• Separate IoT SSIDs for the smart TVs and devices, so I can put them on their own schedule and keep them walled off from everything else — the smart TV does not need to chat with my laptop, ever.
• Omada doing the per-SSID rule enforcement that the switch couldn’t do per-device.

It is, I’ll freely admit, more SSIDs than a tidy network should have. A purist would wince. But it achieves every goal I actually cared about — per-child schedules, kid-safe filtering, isolated IoT — using the tools I had rather than the tools I wished I’d bought. It’s a workaround born entirely of my own thriftiness, and I have a sneaking fondness for it precisely because of that.

Want to copy the field fix? A full step-by-step — SSID layout, the two-rule ACL schedule, and the IoT isolation setup — is coming as its own standalone guide. This article is the why; that one will be the how.

The upgrade path (a.k.a. doing it properly)

The clean version of all this is absolutely achievable — it just needs the right hardware, which is the whole moral of the story. To collapse my pile of SSIDs back into something elegant, the move is a switch (and access points) that support MAC-based VLAN assignment, so a device’s identity determines its VLAN automatically, wherever it connects. Then the rules attach to VLANs, the Wi-Fi simplifies, and the per-child SSIDs retire with honours.

That’s a deliberate, researched purchase for a specific job — which is exactly the thing I failed to do at the start of this series, three separate times.

The one lesson, finally learned

If you take a single thing from this whole journey, take this: research the spec before you buy the box — specifically the spec that maps to the job you actually need done.

Every painful detour in this series came from the same root cause. The free mini PC with one NIC. The cheap USB dongle with the wrong chipset. The bargain switch without MAC-based VLAN. Each time, I optimised for the price on the sticker instead of the capability I needed, and each time I paid the difference back — with interest — in workarounds and weekends.

And here’s the twist I didn’t expect: the workarounds turned out to be the best part. The field fixes, the two-rule ACL sandwiches, the creative routing-around of my own bad calls — that’s where I actually learned how networking works. You don’t learn much from hardware that does exactly what you wanted on the first try. You learn a ton from hardware that forces you to get clever.

So research properly so you don’t overspend — but don’t be so afraid of a mistake that you never have to improvise. The improvising is the hobby. The improvising is the fun.

That’s the network journey: one spare mini PC, three avoidable hardware mistakes, a pile of SSIDs I’ve grown weirdly attached to, and a network that’s genuinely safe for my kids and genuinely mine. Worth every wrong turn.

Thanks for reading along. The standalone build guides — OPNsense, the Omada + Proxmox controller setup, the AdGuard DNS layer, and the kid-safe SSID field fix — are on the way.

Previous: ← Bedtimes, Blocklists and Broken Promises · Back to: The Network Journey hub