Wireless-based vlans across unmanaged switch>
-
Probably. Maybe not. Try it. A device that is not 802.1q compliant is not required to do anything in that case. The biggest issue you might face is not handling the extra 4 bytes added to the frames.
Not sure why you wouldn't just get the right gear, but it's your network.
-
i guess I had assumed I needed a fully managed switch, but it looks like I can get a "smart switch" that supports 802.1q for a relatively low price.
-
yeah there are smart switches that can be had for like $30 8 port gig that will do vlans. Some are better than others - stay away from the tplink cheap ones they are supposed to be working on their vlan implementation - but last I checked they had not updated the code. And you can not remove vlan 1 so its not much better than just running vlans over a dumb switch and crossing your fingers ;)
Keep in mind while you might be able to run vlans over the same dumb switch, there will be no actual isolation and every device would have to be configured with the tagging on their specific interfaces..
-
yes, agree. The APs ensure the isolation. Anything physically connected to the switch isnt expected to have isolation (in my setup).
-
No not really… Just because you tag the traffic on you AP and then send that data over a dumb switch - any device on that switch could see that traffic or send to that vlan. Your not isolating it at the switch.
Now if you connected the AP directly to pfsense, and used your vlans to isolate your different wifi networks would be a different story.
Per you drawing you want a smart switch... I have played with all the cheap ones, the dlink one works as advertised
https://www.amazon.com/D-Link-EasySmart-Gigabit-Ethernet-DGS-1100-08/dp/B008ABLU2I
$35
-
i agree except that the isolation im trying to enforce is for wireless clients on a specific ssid from being able to communicate with the default vlan subnet. Would you agree that if the unmanaged switch passes the tagged frames unmodified, then that goal is still met? (assuming appropriate pfsense config)
But, I agree, I should buy the compliant switch (I will). Any recommendations for a rack mount, 16+ port variant?
-
What is your budget?
I just got a 28 port sg300 that I am very happy with, and moved the sg300-10 that use to be my main switch to my av cab to replace the dlink smart switch.
I show the sg300-28 under the $200 mark on amazon
https://www.amazon.com/Cisco-Small-Business-SG300-28-Switch/dp/B00A8BEK9SNo just because your dumb switch passes the tags doesn't mean there is any sort of isolation.. Any client can view any broadcast traffic flowing across the switch no matter what vlan its in, and any device could just join any vlan they want by setting a tag on their device.
The only point where a dumb switch that passes vlans might be viable is as say a relay on a long run.. Where the only things connected to it were the 2 uplinks from vlan switches..
While the lack of true isolation might be ok for a home/lab setup - it just doesn't make any sense to do such a thing when hardware that would do it correctly can be hand for the cost of a case of beer.. Or a freaking pizza for gosh sake.. Your not talking $$, your talking a fraction of the cost you spend on your 2 AP ;) Even if you got the lite models. A switch that can handle the vlans is less than 1/2 the cost of even the AC lite model of 1 of your AP.
For a few bucks more you can get something with real feature set and fully managed.. The sg300 can do L3, and acls and supports private vlans and port security, etc. to just scratch the surface of the feature set.
-
i agree except that the isolation im trying to enforce is for wireless clients on a specific ssid from being able to communicate with the default vlan subnet. Would you agree that if the unmanaged switch passes the tagged frames unmodified, then that goal is still met? (assuming appropriate pfsense config)
But, I agree, I should buy the compliant switch (I will). Any recommendations for a rack mount, 16+ port variant?
The tagged frames will pass trough the unmanaged switch unmodified but all you're doing is using the switch as a cable extender.
-
I didn't realize a a wireless client could change their vlan tag after the AP sets it. Additionally, I assumed that broadcast traffic on the unmanaged switch would not make it to the wireless client via the ap. Anyways, yes, I'll be buying the switch ;)
-
Wireless clients can't. I do not believe there is a facility for anything resembling a VLAN tag in an 802.11a/b/g/n/ac (etc) frame.
The VLAN tag is added by the AP based on the network the client is connected to.
You should be OK as long as everything connected to the switch is VLAN-aware and properly-configured. Just know that anything connected to the switch can hop on any VLAN at any time by simply tagging correctly and that all ports will see all broadcast traffic for all VLANs all the time.
-
I went over that already ;) hehehehe
"You should be OK"
To be honest this bugs me… Just because you can doesn't mean you should!! Especially at the amount of $ we are talking to do it correctly.. If it cost $1000 for a switch to do vlans, and you could "get by" with doing it with a dumb switch and just tagging your devices interfaces you might have a use case.
But when your talking someone that has the money for multiple APs, a pfsense router and enough devices to warrant multiple AP and the desire to do all that at even understands vlans to the point he understand its a "dumb" switch, etc. Just get the smart switch and do it correctly vs all this should be can do might work discussion..
Don't by coffee at starbucks for a few days and you pay for the freaking switch ;)
-
I don't like it either but sometimes you are forced to make a decision to use gear.
For instance my MoCA bridges do not specifically support dot1q but I pass tags over them anyway. I could swear this was not the case the first time I tested it but it must have been just me being lame.
Perhaps they're incrementing a giant frame counter somewhere but it works fine.
I could also swear I saw a set of powerline adapters that choked on > 1518.
I really don't see being adamant it not be done temporarily especially if the plan is to replace the switch with something more appropriate.
-
Fair enough… If its something that is in a home/lab for a while waiting for the new switch to get here is one thing. Making compromise after it works and never updating is another ;)
