Wireless Access

Hello folks,

I'm trying to determine the optimal design (high level) for a large campus wireless solution. I've read through the ArubaOS 8 Fundamentals guide and it is packed with info; but I'm left curious if anyone has any hands on experience or strong preferences for the Centralized vs Distributed Cluster architecture.

The campus is very large and will have two data centers with several thousand APs. As mentioned in the Guide, primary applications are only in the DCs so it seems Centralized would be the logical choice.

Thank you for any guidance, experience, or even just opinions!

Opinion:

Centralized as much as possible. 

- As long as you can provide enough bandwidth to controllers from access points in that scenario (1 gigabit connection for every 100 access points to each controller), that is the preferred scenario. 

- Configure as much as possible in common at the folder level.  Controllers would have minimal configuration in specific and you would add or remove controllers to a cluster to add and remove capacity and leverage redundancy without tons of configuration.

- If you have two datacenters that data is actually being served out of, you would have the option of having two separate clusters, if it would make you more comfortable. 

- A cluster boundary would be anywhere that all layer 2 VLANs can be shared with a group of controllers.  If you cannot do that between your controllers, you should create a separate cluster, where you can do this.

Again, this is my opinion from working with organizations to both (1) Migrate from 6.x to 8.x and (2) Deploy enterprises from scratch on 8.x.

Hi Jordan,

Without all the details, only a generic advise can be given.

Questions : 

1. Where is the internet breakout?

2. Are there secondary application that are not DC-only that require bandwidth (use of streaming devices (AppleTV's), AirPrint, etc) 

3. Are you designing the wired network with a seperate campus and DC core?

With Centralized design you have the advantage of less complexity in your wired campus network as the wireless traffic is tunneled all the way to the DC's.

A global schematic of the wired layout could help to follow trafficflows and determine bottlenecks and strongpoints.

Hope it helps

Thanks for the replies.

In regard to the questions:

1. Everything will go through the data centers for local applications and for external to outside.

2. Not to speak, the biggest portion of the traffic will be guests accessing external networks.

3. Not sure I follow, but yes we are designing (again from a high level only) the wired core for the site as well. Its a typical three tier access > distribution > core.

Hi Jordan,

Then centralized (like Colin already advised) should be your best option.

Look into Colins post, that will help.

 And please make sure you have the right amout of bandwidth in the three tier design. Wireless is depending on it!

Adding my $0.02 from a decently sized higher ed deployment . . .

Your core and distribution topology will undoubtedly have influence on your chosen WLAN deployment. You essentially are looking at two options:

1. Manage lots of lower capacity controllers in a distributed fashion, or
2. Manage fewer high capacity controllers in a centralized fashion

With AOS 8, both methods are easy, as whether it is 1 controller or tens/hundreds, the configuration hierarchy makes them fairly easy to manage. However, I chose centralized in order condense the amount of infrastructure we are managing.

We have two data centers and each one has a separate "MM domain" (not sure that is a correct term, but it's what I use). Both DCs have 2 primary clusters of 7240XM controllers. One of the DCs has a third smaller cluster that we consider "early release" - a place to first install new code, try new features, etc, as it represents a sampling of academic, staff, residential, and classroom environments. Ideally, we would've only maintained a total of three clusters instead of five; however, we were exceeding the number of devices per Airwave server and needed to slice things up a bit to accommodate those limits.

Our configuration hierarchy for the controllers is set up as follows:

/md

/md/osu

/md/osu/cluster1

/md/osu/cluster1/controllers...

/md/osu/cluster2

/md/osu/cluster2/controllers...

• All controller-specific configuration is added at the controller level. This includes things like hostname, vrrp, time, spanning-tree, management vlan, and interface config, including port-channeling
• All vlans, vlan pools/mapping, and airwave configuration is added at the cluster level. This ensures that we can maintain the L2-cluster configuration and avoid scenarios where an L2 cluster breaks and resorts to L3.
• ALL other configuration, including ap-groups and profiles therein, are created at the orgainzation level (/md/osu). This ensures that no matter where an AP first lands during master discovery, the cluster it first touches has the correct LMS IP (read: cluster VIP) and can migrate APs to the correct cluster.
• We write NO configuration at the top level (/md) as to avoid any Aruba defaults overwriting custom configurations made at that level

That's probably plenty of opinion, but if you have any targeted questions, feel free to follow up.

Good luck!