Large vlans, are they the way to go?

[david_henderson]

Over the next 6 months we will be ripping out our current wireless network and installing 400 Ruckus APs and two virtual SmartZone controllers. We will be dropping traffic at the edge and not tunneling it back to the controller per Ruckus best practice

We will be using Cloudpath to onboard personal devices. We are thinking about using just two SSIDs and five vlans

1. Guest SSID - this will just be used to get initial connection to network for staff, student and guest personal devices. This would have a single vlan. Once authenticated through Cloudpath they will be transitioned to the Secure SSID and placed in the proper VLAN
2. Secure SSID - all devices would end up here with four vlans
   a. District owned devices
   b. Personal devices owned by staff
   c. Personal devices owned by students
   d. Personal devices owned by guests

Each of the 4 vlans will be be large, perhaps /18 or /19
I am seeing more and more large vlan designs to accompany campus large wifi networks

Does this design seem reasonable? Can large vlans like this work fine for wlans?

[monnat_systems]

i think large VLAN is NOT a problem but the BC/MC traffic from Large VLAN is. Better to have a switch which can prevent such traffic to hit the AP..

[david_henderson]

Can the Ruckus APs be set to block certain types of broadcast/multicast traffic?
I kept thinking I read somewhere that certain types of traffic like WINS, etc. can be blocked completely

We use Juniper EX4200 switches at the edge, I can check if they can be set to block certain types of traffic.

The traditional thought has always been to have small vlans otherwise a lot of traffic could be broadcast traffic causing congestion. Even 6-8 years ago Cisco recommended vlans no larger than /24. It seems that recently the thought process has changed with various mechanism to cut down on broadcast traffic and change multicast into into unicast

[monnat_systems]

well controller based network can block multicast traffic from network to "tunnel" and Block broadcast traffic from network to "tunnel" except ARP and DHCP.

any legimate MC/BC traffic destined to wireless user is indeed unicasted.

[david_henderson]

The other way to handle this is with vlan pooling. Instead of one /19 subnet, have four /22 subnets. I am assuming with Ruckus if vlan pooling is used there is some type of load balancing across these vlans with DHCP handing out a fairly equal number of IP addresses in each. Is that the case? Is vlan pooling a good way to go?