In my last blog post, I took some time talking about the Live Upgrade feature introduced within the latest ArubaOS. With the popularity of that post, I thought I would continue into a “Getting to Know” series discussing new features in AOS8 and how they are used/configured within the new OS. Today’s topic is Aruba AirMatch.

Background:

For those of you that may not be familiar with the Aruba technology, the AirMatch feature is an extension of the Aruba Adaptive Radio Management (ARM) technology that has been around the Aruba world for a number of years now. AirMatch builds upon the continuous efforts of Aruba engineering over the years, to provide a version of RRM that is actually useful in real world environments and doesn’t take a genius to configure. Let’s face it, we’ve all used some form of RRM over these years with various vendors and seen how poor the results of those algorithms were in real life. Just take a quick look at the picture here from twitter as one example.

ChannelFly example

Just for clarity, I’m not picking on Ruckus for the problem above. Typically, things like this are almost always caused by default ‘out of box’ configs. (Shame on you for calling yourself a wireless engineer if you leave an environment like this!) Whether it be Cisco, Ruckus, Aruba, etc, the practicality of actually using these features was useless, as their positive results were vastly overwhelmed by the problems they tended to create in the environment. It took a lot of time, patience, and observations of the environment to harness their abilities into something that could be useful.

Aruba decided to take RRM to the next level and build upon big data principles within the AOS8 architecture. AirMatch takes input from EVERY AP in the environment every 5 minutes throughout a 24 hour period, and then uses that information to calculate and create a solution to be applied once every 24 hours to the network. Yes there are ways that you can disable this, or even freeze certain AP to a predetermined channel & output power (see below italics), but I for one am pretty impressed with it’s ability to build pretty dang accurate solutions.

Freezing example command:

(arubavmc-lab) #airmatch ap freeze ap-name AOS8-AP band 5ghz channel 48 eirp 12

In most cases, it’s ability to evenly distribute channels amongst the APs while keeping channel reuse at good distances to reduce CCI has been good in the environments I’ve seen it running or had the ability to configure myself. Just take a look at this image from Aruba’s Atmosphere 2017 user conference and the job that it did. The values above each channel are the number of APs assigned to that channel by AirMatch.

Aruba AirMatch AP Distribution – Atmosphere 2017

Configuration:

So how do you harness this amazing feature, since we all know that sooner or later we’re going to have to tame the beast even as good as it is?

Even though we have already discussed how this is built upon the ARM legacy, as it turns out the configuration of AirMatch within the AOS8 Mobility Master has nothing to do with the ARM profiles. So if you are looking here and trying to configure it, I’ll save you some time by saying, don’t.

AOS8 ARM CLI Settings

AOS8 ARM GUI Settings

The actual information that you should be configuring is found in the Radio Profiles, which is a bit of a departure from previous ArubaOS.

In order to configure the settings like channels available, power output min/max you’ll need to navigate to this section of the GUI or CLI:

AOS8 RF Radio Profile CLI

AOS8 RF Radio Profile GUI

So you might be wondering, why are the ARM settings still around if AirMatch is enabled by default in AOS8. That’s a great question! As it turns out, the very valuable ClientMatch settings are still located in this profile within AOS8. So even though AOS will ignore any power/channel settings in the ARM profile, there is still a need to keep it around for the foreseeable future. I hope that Aruba will relocate the ClientMatch features and provide a way that under the correct circumstances the GUI/CLI will hide the ARM profile settings if not needed.

One final note is that while AirMatch ignores the ARM settings, there are times where the ARM settings are used. Within AOS8, there are times due to hardware or architecture decisions that a Mobility Master is not used to control the environment. When no MM is used, the environment will need to use standalone or Master Controller Mode (MCM) in which the ARM settings will be used for AP RF control. Hey, they had to have a reason to encourage you to run the Mobility Master right?

If you haven’t experienced ArubaOS 8 for yourself yet, I highly encourage you to check it out. AirMatch is yet one more feature that makes AOS8 worthwhile.

For more high level information on Aruba AirMatch, check out the data sheet here.

Comments/Questions? Go for it!

-Scott