A couple of practical example may help to illustrate....
Well again my basic case ... holiday resort.
The VLAN over wifi is used extensively in the wireless (and wired) backbone connections. The client facing AP's (not drawn in this diagram) are using the VLAN ID to untag either in the bridge (static) or in the wifi driver. As the assigned VLAN ID must be userid specific (RADIUS assigned) the bridge
static tag/untagging will be removed.
The backbone carries all VLAN's tagged. (this design coming from 4 VLAN's split and untagged by the Powerboxes, now all VLAN go to all endoint AP's, not to client devices)
Backbone network
... nodes are Powerbox Pro ,
interconnected with Cube or wired,
downstream to SXT SA5 ,
then PtMP to SXTsq's ,
going to RB260 ,
going to client facing hAP,wAP and cAP
backbone R.jpg
As clients are allowed to connect to any wAP,cAP or hAP, all VLAN go to all those AP (filtering would be useless) RB260's have no VLAN defined (dumb switch config)
Splitting clients over VLAN helps reduce broadcast, multicast traffic. And broadcast and multicast is horrible traffic for wifi if not tunneled. (basic rate airtime consumption)
Just check what on such a network a client device does when seeking it's home printer, the corporate laptop seeking it's AD server and file-shares, Apple devices with "Bonjour", casting app's like chrome cast, and app's like Skype, Dropbox, Windows upgrade downloads that try to get their data from any other device on the same LAN.
Using same bridge horizon value on the downlinks , and no forwarding in the PtMP SXT SA5 further reduces broadcast and multicast propagation.(depends on what you want to allow)
I just wonder how CAPsMAN would handle VLAN tag/untag for local forwarding. In bridge or WLAN driver ?
Other practical exemple ... anytime you want to have more VLAN's accessable via wifi, but do not want to create the extra SSID overhead.
At home it happens also: many new appliances have cloud access for service or for remote access to the units.
Airco Italian company, bathroom heating German company, sunscreen controller French Company, rainwater pump, expressomachine, doorbell, camera, chrome cast, domotica, ... all via different cloud services. There is one IOT VLAN now for this, but should heating and access control be in the same VLAN ? Better not. One VLAN per vendor or cloud server is the safest but that would be many SSID when VLAN handled by the bridge. And 6 SSID on 5 AP would already send 30 beacons every DTIM period, 300 per second at basic rate. With VLAN handling in the WLAN driver, and using ACL, just one SSID will do for "n" VLAN ("n" could become a large number).
In the city hall network we had many more services, most with wifi connected devices, interactively handled from the servicing offices (access control, heating, ventilation, airco, billboards, solar pannels, water pumps, ticketing system, sun screens, alarm systems, cameras, board room audio/video/voting system, auditorium projection, etc etc ... separation was manadatory ! Large building 35 AP with full wifi overlap.
You do not have the required permissions to view the files attached to this post.