topic Re: Large vlans, are they the way to go? in To Be Moved

Large vlans, are they the way to go?

david_henderson — Sat, 19 Dec 2015 19:49:16 GMT

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

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
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?

Re: Large vlans, are they the way to go?

monnat_systems — Sun, 20 Dec 2015 15:48:16 GMT

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..

Re: Large vlans, are they the way to go?

david_henderson — Sun, 20 Dec 2015 16:07:05 GMT

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

Re: Large vlans, are they the way to go?

monnat_systems — Sun, 20 Dec 2015 16:23:54 GMT

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.

Re: Large vlans, are they the way to go?

david_henderson — Sun, 20 Dec 2015 16:29:06 GMT

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?

Re: Large vlans, are they the way to go?

seanmuir — Sun, 20 Dec 2015 23:44:37 GMT

Large VLAN's should not be an issue.

I have a HD deployment with a /17 and I have no issues at all.

For my deployment I used VLAN pooling to limit the overhead in conjuntion with a loopback interface on the router.

Notes on VLAN Pooling:

1. VLAN pooling allows up to 16 VLAN's per VLAN pool (1 VLAN pool per SSID).
2. The SZ only supports MAC hash algorithm at the moment for VLAN pools, unlike the ZD which support least used and round robin as well as mac hash (there are no immediate concerns in regards to the use of the mac hash algorithm).

I would also enable Proxy ARP on the WLAN, this will also reduce overhead and improve battery life to the client.

Final considerations would be to look at your beacon interval (be careful as some clients need the 100ms beacon interval) and lower your BSS minrate.

In regards to multicast traffic, you can either drop it or not, depending on whether you have services that require it.

Re: Large vlans, are they the way to go?

david_henderson — Mon, 21 Dec 2015 00:55:40 GMT

Sean,

So using vlan pooling with the virtual smartzone controller is OK even though it only support mac hash for an algorithm?

Not sure what you mean by this:
"For my deployment I used VLAN pooling to limit the overhead in conjunction with a loopback interface on the router."

I thought vlan pooling is used to make smaller vlans to cut down on broadcast traffic. If you have a /17 vlan that is still very large

Dave

Re: Large vlans, are they the way to go?

seanmuir — Mon, 21 Dec 2015 10:38:01 GMT

Re your:

So using vlan pooling with the virtual smartzone controller is OK even though it only support mac hash for an algorithm?

As per my comment in my original post:

(there are no immediate concerns in regards to the use of the mac hash algorithm).

Re your:

Not sure what you mean by this:
"For my deployment I used VLAN pooling to limit the overhead in conjunction with a loopback interface on the router."

We have a core DHCP server and for DHCP too work we had to use a loopback interface on our edge router to allow clients to connect using the VLAN Pool.

Re your:

I thought vlan pooling is used to make smaller vlans to cut down on broadcast traffic. If you have a /17 vlan that is still very large

I am splitting my /17 in 16 smaller /22 subnets using VLAN pooling, so I don't understand your question

Re: Large vlans, are they the way to go?

david_henderson — Mon, 21 Dec 2015 11:25:47 GMT

Thanks, it is all clear now. I have three Windows Server 2012 R2 Active Directory, DNS, DHCP servers. I will have to read up on how IP addresses are pulled from these servers in the case of using vlan pooling on the Ruckus side.

In the end, it sounds like a combination of using vlan pooling along with controlling broadcast and multicast traffic will work.

Re: Large vlans, are they the way to go?

david_henderson — Tue, 22 Dec 2015 22:03:34 GMT

I just started a new thread about on-boarding with Cloudpath and then placing the user in a vlan pool
https://forums.ruckuswireless.com/ruckuswireless/topics/cloudpath-with-vlan-pooling-can-it-be-done

This would give me plenty of IP addresses to hand out but keep vlan sizes small to cut down on broadcast traffic