APs in same VLAN as controllers?

[david_henderson]

We will using bridge mode for all of our APs per Ruckus best practice. All of our servers on campus run under VMWare and all of them whether running Windows, Linux, or some form of Unix reside in vlan 125. Normally we would place our Ruckus vSZ controllers in vlan 125. This is a vlan that at the moment we do not trunk outside the data center with our layer2/3 core switch providing routing to this vlan.

Two questions

1. Is there any reason to have the Ruckus APs also in vlan 125? It appears that a simple DNS entry can point the APs to the controller in a different vlan
2. We will be dividing wireless client traffic into different vlans based on type (district owned device, staff or student personal device, or guest device). Should the APs themselves be in a separate vlan from the vlans that carry wireless traffic? In other words, should the 400 APs that we plan on installing be in a vlan by themselves?

[bill_burns_6069]

I would not (in general) want my AP management addresses in the same subnet as my datacenter / servers.

If you've got (or will have) 400 Ruckus APs, then yes, they should have their own subnet.
(at least one)

If you really want them all in the same subnet/VLAN, then that subnet will need to be larger than a "class C" or  "/24" subnet.
If you're in a school district with different address space for each building / school then you'll probably want a different AP management subnet for each school. (otherwise, you'd have to build an overlay network or something like that)

Right now, we're talking about management subnets for the APs.
Personally (with all the APs in one management subnet) I'd be fine w/ putting the controller in that same subnet. Other people in that position might find a reason to secure the controller behind some kind of firewall. That would be one reason to keep it in another subnet than the APs.

If the APs will not all be in the same management subnet then you might-as-well keep the controller in your VLAN 125 (or some VLAN other than the APs) so that (for consistency) the controller would not be in the same subnet as *any* of the APs. (as opposed to being in the same subnet as *some* of them)

re: Question 2:
Yes, the AP management subnets+VLANs should be different from the VLANs (associated w/ WLANS and SSIDs) that carry the users wireless traffic.

[seanmuir]

All you need to know is that the vSCG has 3 planes:

Management

Control

Data

The management plane is simply for you to access the UI of the SCG.

The control plane is what is used for the AP management traffic.

Note: AP management (control plane) and vSCG management (management plane) cannot be on the same subnet so you will have to seperate them via VLAN.

The data plane is mainly used for the following:

• Encrypted data tunneling: Provides flexible options for data tunneling from all types of Virtual LANs (VLANs), including guest traffic encryption; point of sale data tunneling for PCI compliance; VoIP traffic tunneling; and seamless roaming across Layer 2 subnets.

• Dynamic data plane scaling: Provides scale and resiliency for large deployments supporting 1Gbps, 10Gbps or higher throughput – which can be dynamically tuned without needing software updates.

• Cluster architecture: Provides scale and resiliency for large deployments supporting up to 30,000 access points and 300,000 devices. One Virtual SmartZone controller can manage up to two vSZ-D instances, and four-controller cluster can manage up to 8 vSZ-D instances.

• Support for multiple hypervisors: Provides initial support for two of the industry’s most widely deployed virtualization engines – VMware vSphere and KVM (OpenStack).

When deplying AP's they do not necessarily need to be to on the same subnet as client traffic, but to administer VLAN tagging for AP WAN interface (AP management) can only be done using the CLI at the moment:

set interface wan vlan 10 10.10.10.2 255.255.255.0 10.10.10.1

The client traffic can also be tagged if you like and this achievable via the vSCG UI

Note: If you want to simplify things and have client traffic and AP management on the same VLAN, this is no real issue, as you can prevent access to your management network via the use of ACL's on your venue router.

I hope this answers your questions

Good Luck!

[david_henderson]

Thanks for the quick replies
I have a class A address space so lots of available IP addresses
Here is a summary along with a few scattered questions

• Put the controller in vlan 125. In other words, the management IP address will be 10.121.125.xxx
• Put the APs in vlan 8 which is a /22 vlan. This gives me plenty of IP addresses to hand out to APs via DHCP
• Put the vSZ control plane in vlan 8 as well so the APs and controller's control plan are in the same vlan. How can this be done?
• I know that data plane and control plan traffic can be separated via the purchase and deployment of vSZ-D. In our situation is there any advantage to doing this?
• Put the wireless client traffic in a different vlan(s)

It was mentioned about AP management address. My understanding  is once the APs connect to the controller then you cannot go to the IP address of the AP and do any type of management, all of it is done via the controller. Is that correct?

[seanmuir]

Here are my responses:

Put the vSZ control plane in vlan 8 as well so the APs and controller's control plan are in the same vlan. How can this be done?

If its a local vSZ and the AP's are in the same locality, just make the port facing the Control plane an access vlan 8 port.

If they are not in the same locality and they are remote AP's, then the router will do this via VLAN pruning.

I know that data plane and control plan traffic can be separated via the purchase and deployment of vSZ-D. In our situation is there any advantage to doing this?

What are you using the data plane for? If you are clustering then you will need a data plane for HA.