APs in same VLAN as controllers?

  • 1
  • Question
  • Updated 1 year ago
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?
Photo of David Henderson

David Henderson

  • 92 Posts
  • 13 Reply Likes

Posted 2 years ago

  • 1
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
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.
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
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!
(Edited)
Photo of David Henderson

David Henderson

  • 92 Posts
  • 13 Reply Likes
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?
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
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.
(Edited)
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
I use a physical controller.
I don't know about vSZ.
So.. if you prefer Sean's answers, feel free to go w/ that.

What I would do is configure each network port (where an AP is connected) to be trunked but w/ your VLAN 8 as the "native VLAN". (A.K.A untagged VLAN)
Then, use the DNS method you described to point the APs at the controller.
..and that could be your "total solution".

I (personally) think that's a better/easier solution than reconfiguring APs to understand what their management VLAN is supposed to be.
But maybe that's 'cause I'm familiar w/ switch configs.

..or maybe a virtual controller has options to put an IP in your AP management subnet but that requires bringing your AP management subnet into your datacenter which is something you wouldn't have to do otherwise.

Some network people like to segregate datacenter and access-layer VLANs
You can keep your datacenter VLANs segregated by routing the controller traffic into the datacenter instead of bridging it in on the same VLAN.
(Edited)
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
Hey Bill,

ZD's are different to vSZ's in the manner that I have described above in my earlier post:
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.
This is the same on a physical SCG, you just can't have LWAPP (control plane) and SCG management (mangement plane) on the same subnet.

In terms of AP deployment I have to use tagging on managemnt sometimes as I have to integrate our AP's with other networks and do a semi overlay, and sometimes our default VLAN's are already used.

I guess  you can really do it either way. Your way your altering the native VLAN on the switch, and my way I am altering the VLAN on the AP, either way you to change a VLAN to accomodate the management element someway or another.

Note: I also change the native VLAN on the switch to an unused VLAN, it is just what I do to add a little security.

There is no definitve way on doing this, I guess if it works, and there is secruity, then all should be fine.
(Edited)
Photo of David Henderson

David Henderson

  • 92 Posts
  • 13 Reply Likes
We have a single campus that contains all of our academic and support buildings
Our network is simple with a layer2/3 core switch and 20 data closets scattered across campus with a stack of switches in each closet
Each academic building has there own vlan where all desktop computers, printers, and a few static IP devices reside. Of course we have other vlans for our VMWare setup, secure wireless, and guest wireless

For example our High School has vlan44 which is 10.121.44.0/22
With a huge move towards wireless devices in the last 5-7 years, even the HIgh School vlan is not that large. With a bit over 1,000 IP addresses in a /22 vlan, we only use 414.

For testing purposes we had a few Ruckus R700 APs. We hung those in our High School and plugged them into an access port on a switch. Through DHCP this gave one of the APs the IP address of 10.121.44.201. A client hooked to this AP also got an IP address in vlan44. Our Ruckus vSZ controller is sitting in vlan125 and the APs found the controller via a DNS entry.

This Ruckus setup works fine for testing but when we roll into production with 400 APs this summer it might be different. We are going to use Cloudpath to onboard all staff personal devices, student personal devices, and guests. I am assuming we will use vlan tagging to place devices in the proper vlan.

I am still a bit foggy on the APs themselves. I could make the switch port where an AP plugs into a trunk port that includes a vlan for the AP itself as well as vlans for the wireless client traffic. In this case, how does the AP know which vlan to be in? I am thinking about having a vlan for just the APs and of course it will have a DHCP scope so each AP gets an IP address.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
Sean and I mentioned 2 different methods. (of getting your APs onto a particular VLAN)

Sean's method was to configure the AP to understand that it's management traffic belongs on your VLAN 8 (for example)
This requires the AP to be connected to a trunked port that carries VLAN 8.
Sean additionally recommended that the native/default/"untagged" vlan on that trunk be set to some random unused VLAN number. (for "security" reasons)


My method was to leave the AP unconfigured (in regard to what VLAN it's management traffic rides on)
By default the AP will use the native/default/"untagged" VLAN for management.
Then, connect each AP to a trunked port on your switch that's configured with the native/default/"untagged" VLAN set to VLAN 8.


Either method should work.
Either way, you need a trunk port connected to your AP. (that includes all the VLANs used by your SSIDs and your management VLAN)
It's a matter of whether you'd prefer to apply the "VLAN 8" part of the config to the AP or to the switch.


FYI 1:
By default, switches use VLAN 1 as their native/untagged VLAN on a trunk.
If the concept of 802.1q VLAN tagging is unfamiliar then you should either start learning about switch configs or find a "network" person to help you w/ your project.

FYI 2:
You seem to be confirming that each of your buildings uses a different set of subnets.
('though that's not clear)
If that's the case, you might have a different AP Management VLAN in each building, along w/ a different "secure wireless" VLAN in each building, etc.

The alternative would be "end to end" VLANs (and subnets) that span between buildings and possibly across your entire school district.

The choice between these 2 approaches is a major design decision that involves what IP address ranges are available for use by your APs (and WiFi clients) in each building.

If you're not clear on that, please consult your network professionals.
Photo of David Henderson

David Henderson

  • 92 Posts
  • 13 Reply Likes
Thanks for all of your help on this. I will be working with some networking professionals from the company who is installing the Ruckus gear. We do have vlans that span the entire campus so we will probably use a vlan that spans the campus to place all the APs in. Looking forward to have a new Ruckus wireless network

Dave
Photo of David Henderson

David Henderson

  • 92 Posts
  • 13 Reply Likes
I just wanted to follow up with how we are setting things up. Our 400 R710s arrived a few days ago and we just stood up our first Smartzone Controller. The controller sits in vlan 125. Since we have a single campus, we have vlan 8 extended to every edge switch. This is the vlan that will carry AP management traffic. We choose to make trunk ports with vlan 8 and all the other vlans carrying client traffic and to make vlan 8 the native vlan on the port. This should allow the AP to get its IP address on vlan8 since we have a DHCP scope setup for this vlan.

We have the proper DNS record to point to the controller so once we configure the controller next week and plug in the first AP, it should find the controller and we can do some testing. We are hoping to have one building switched over to Ruckus before school starts and the rest to follow in the fall.

Thanks to everyone who responded to this post
Dave