Small question regarding managed switches.

[micronta]

Hello, folks.

Picking up some hardware to upgrade our home network. My current plan is:
OPNsense box --> switch1 --> AP1 + switch2 --> AP2

It is my understanding that switch1 has to be a managed switch if I want AP1 to have a guest network on a separate VLAN?
Does switch2 also have to be a managed switch if I want AP2 to broadcast the same main and guest SSIDs? or can it be an unmanaged switch, as it is downstream from switch1?

Thanks!

 

[SlowmoDK]

The very short answer is yes, it has to be managed as well.

 

[micronta]

The very short answer is yes, it has to be managed as well.

Thanks. Learning a lot. Wish me luck.

 

[Jelmer]

Some dumb swtiches preserve the vlan tag and traffic from AP1/2 flows fine to the router. Other dumb switches can't cope with vlan tags and strip them which makes everything go south.

 

[nexox]

The specs for unmanaged switches will usually list 802.1q support if they forward tagged frames, though managed switches don't cost that much these days and do offer more flexibility for future network changes, I'd just go for all managed.

 

[Kirby perkins]

You might get away with a dumb switch if it happens to pass 802.1Q tags through unharmed, but it's hit or miss depending on the firmware/hardware. Managed switches are so cheap now that it makes way more sense to just get another managed one and avoid the risk altogether.

 

[unmesh]

When I added VLANs to my home network, all my unmanaged switches including no name ones passed along 802.1Q tags. To OP, my APs are VLAN aware so I did not need managed switches

 

[tgl]

When I added VLANs to my home network, all my unmanaged switches including no name ones passed along 802.1Q tags. To OP, my APs are VLAN aware so I did not need managed switches

It's "do not need" only if you don't really need VLANs. The behaviors you might get with an unmanaged switch are (1) drop tagged packets on the floor, or (2) forward them indiscriminately to any port, or (3) strip the tags and then forward them indiscriminately. I have switches that do (1) and (2), and I've heard that (3) is a thing too. While case (2) is sort of usable, it's not providing any VLAN isolation, because devices that are supposedly confined to a VLAN can still reach devices that are on other VLANs. So I have to wonder why you'd bother.

 

[gregsachs]

Tp-Link and unifi both have pretty cheap managed switches if you don't need more than a few ports.

8-Port Gigabit Easy Smart Switch

8-Port Gigabit Easy Smart Switch, Plug and Play, Intelligent Management, Desktop, Wall-Mounting, Sturdy Metal Casing, Shielded Ports, Green Technology, Gigabit

www.tp-link.com

Switch Flex Mini - Ubiquiti Store

A compact, 5-port, Layer 2 switch that can be powered with PoE or a 5V USB-C adapter.

store.ui.com

Obviously with unifi you also need a controller of some sort, but that can be a VM or similar.

 

[louie1961]

why two switches? seems like too many points of failure to me. I would rather run more coax and hang everything off of switch 1.

 

[unmesh]

It's "do not need" only if you don't really need VLANs. The behaviors you might get with an unmanaged switch are (1) drop tagged packets on the floor, or (2) forward them indiscriminately to any port, or (3) strip the tags and then forward them indiscriminately. I have switches that do (1) and (2), and I've heard that (3) is a thing too. While case (2) is sort of usable, it's not providing any VLAN isolation, because devices that are supposedly confined to a VLAN can still reach devices that are on other VLANs. So I have to wonder why you'd bother.

You make excellent points so let me elaborate on my use case.

I'm switching entire trunks on my wired network because the only VLAN aware devices are my router and my APs, the latter of which map SSIDs to VLANs. Those SSIDs are used by various classes of wireless IoT devices and there is a primary SSID for non-IoT devices that uses the untagged VLAN. So I am able to achieve VLAN isolation for the devices that I needed to isolate since the APs are adding/stripping the VLAN tags.

If tagged packets are being dropped or the tags being stripped, I wouldn't easily notice (unless they were doing it all the time) because TCP/IP would do a retry.

Regarding point #2, the switches are forwarding based solely on MAC learning so that some ports carry VLAN traffic that they don't need to. Also the L2 broadcast domains are larger than they would have been with VLAN aware switches. My network is lightly used so I can live with that.

I should have been careful not to imply that VLAN unaware switches provide the level of functionality that VLAN aware switches do.

 

[tgl]

I should have been careful not to imply that VLAN unaware switches provide the level of functionality that VLAN aware switches do.

Fair enough: you can use a case-2 switch for this so long as you realize that all its ports are effectively trunk ports. My concern about indiscriminate forwarding only matters if you have some ports that need to be VLAN-restrictive.

BTW, as far as I know, an unmanaged switch will do the same thing every time with tagged packets. Whether it's (1) (2) or (3) depends on how the switching fabric is configured, but whatever that configuration is, there's no way to change it.

 

[unmesh]

I do have a 5-port "web managed" switch that I bought for the purpose of testing the operation of access ports that I did not eventually deploy. It was particularly nice to see status of every port on a web page.

I read about LLDP based topology discovery but did not want to invest the time or money in implementing it.