Tag Archives: Cisco RRM

Contemplating Auto RF Functions In WLAN Systems

Once upon a time, wireless networks were completely the product of the person or persons who designed, installed, and configured them. The WLAN couldn’t think for itself, per se, and important settings like channel and power were determined by the human hands and minds behind each Wi-Fi network. This was mostly a hallmark of the age of Fat Access Points, when our wireless networks were more about general coverage and less the stuff of carefully weaving high-density signal tapestries that support ever increasing client device counts. Now, there is impressive (or utterly maddening, depending on vendor and code version) magic behind the typical modern business WLAN; access points get their configs from some version of a mothership, and mystical “algorithms” choose what power and channel settings each access point will use. 

If you let them, that is.

After a recent spirited Twitter dialogue with a couple of dozen really smart fellow wireless networkers, I found myself a bit taken aback by the general distrust of “auto RF” functionality that comes with almost any new Wi-Fi gear that uses multiple access points to form a WLAN. After all, these systems are not cheap, and the auto RF stuff is a major feature that adds to the cost. I’m not aware of any system that lets you order system code without auto RF to lower the price, yet a lot of WLAN professionals aren’t really embracing it. Is it a matter of general disdain for something that has caused pain for their end users that have lead my colleagues to speak somewhat unflatteringly about auto RF features, or is there something else at work?

From my own experience, I’ve been *generally* satisfied with Cisco’s Radio Resource Management (RRM) and use it extensively in my extremely large WLAN environment. At the same time, there have been a few cases where I’ve had to manually override RRM’s selected values. Usually, I can look at these exceptions and point out a design trade-off that we were forced to make (the real world is rarely perfect) that probably threw the RRM algorithm for a loop. It’s not that RRM failed me- in fact you could say that at times my design failed RRM.

I think this is some of the essence of skepticism behind auto RF from my wireless homies. Auto RF features are not divine cure-alls for bad design, nor can they be trusted to simply come to life and make everything OK with manufacturer’s default values in all cases. You have to learn how they work in your environments and with your design approaches, and realize that not all vendors are going to implement the same way. For me, I’ve got the most experience with Cisco’s RRM (generally pleased), Meraki’s version (can be weird at times), some Aruba (did a building-wide pilot a few years back, Aruba’s ARM did fine for me back then) and Aerohive on a small scale. Making things even more complicated, vendors can change their algorithms as they choose (potentially negating what you think you understand) and some document the technical underpinnings better than others… it gets tricky, yet I can’t imagine trying to keep my own 4,000 AP network up without it.

Here are some vendor links relating to auto RF functions (No slight intended to anyone I left out, this is just a sampling), and I have no clue whether there are newer versions available :

You get the point… some vendors are more explicit in explaining the theory of operation behind their auto RF mechanisms, others seem to have added it because it’s what you’re supposed to do anymore. Regardless, it’s very interesting.

I’d love to hear your opinions on the notion of auto RF, whether for a specific vendor or in general. What have you found that works? That doesn’t work? What’s your advice for people just getting started with auto RF capabilities? Any good auto-RF links to share?

Thanks for reading!

Some Rogue APs You Just Gotta Live With

As I look in on the management console of my big Cisco WLAN, I see at the moment I have 711 detected rogues on my biggest campus. Detection in this case loosly equals:

  • Being heard by one or more APs that have been configured to take part in rogue detection
  • Breaking our threshold of concern (I have set to RSSI of -78)
  • Being heard within the last few days

Because of where this WLAN sits geographically and the fact that we have thousands of APs (with hundreds participating in rogue detection), our rogue dashboard stays pretty busy. We’re in a city, surrounded by hospitals, businesses, and residential neighborhoods. I asked The Google for graphical help:


This is a quick and dirty view of our main campus area, and doesn’t show several of our local remote sites or our mile-away other large campus. But- you can see we’re surrounded by lots of buildings. And… those buildings have lots of Wi-Fi. Because we’re so close, we can’t help but to mutually interfere with our neighbors. Our high density design keeps our APs usually running very low power, and we try to be good neighbors.

For giggles, here’s a partial list of interfering SSIDs along with channel and signal strength (perceived by our APs) that I really can’t do a thing about. This DOES NOT include the known “regulars” that have already been “acknowledged”- the hospitals, JPMC, local hotels, etc,  Each of the following is absolutely outside of our own buildings:

  • SSID: PA 217A, Channel 6, Strongest AP RSSI: -41 (yes, -41)
  • Guest Network, 11, -43
  • On Route (several instances, all very strong, scattered all over 2.4 GHz and 5 GHz, very transient)
  • Apple, 6, -47
  • Netgear, 1, -49
  • AirDelt, 10, -57 (Asustek)
  • TWCWIFI and TWCWIFI Passpoint. 11, -57 (These are Ruckus)
  • IACNY (multiple), 4, -60
  • <non-broadcast>, 3, -61
  • prettygirlthreadz, 11, -62 (Actiontec)
  • Braka Air, 1, -62
  • Themis Corporate, 2, -62 (Apple)
  • Tits for Password, 1, -63 (Belkin)
  • EnvySalon. 1, -63 (Cisco-Linksys)
  • Dr Cohen, 9, -63 (Cisco)
  • DTD Ground1, 3, -63 (Cisco-Linksys)
  • PsyMiFi, 2, -63 (Novatel)
  • ATT912, 8, -65 (Motorola)
  • DensityAP431, 6, -65 (Tp-Link)
  • <non-broadcast>, 9, -65 (Z-com)
  • MidValleyHospice, 8, -65 (Netgear)
  • CrepeandGelatoEspressoBar, 6, -66 (Actiontec)
  • <non-broadcast>, 10, -65 (Nintendo)
  • 2WIRE260, 4, -67 (2wire)

I’m hoping you get the point. Remember- my current view shows over 700 of these. To the trained wireless eye, there are many stories in this sample of my overall reported rogue list:

– lots of consumer-grade stuff
– lots of default channel 6
– lots of CCI, ACI, and every xCI you can think of afoot
– lots of nearby networks that likely aren’t performing all that well, and certainly not up to their potentials
– most of the noise is in 2.4 GHz (but certainly not all on the full list)
– our own network has a lot to contend with on our geographic edges

Given the wild-west nature of unlicensed wireless, this snapshot is just another day in the life of my WLAN. I can’t do much about the neighbors, but occasionally do help them when one of them reaches out. The conversation usually goes like:

“I hear you’re the campus wireless guy”
What can I do for you.
“I’m your neighbor and my wireless sucks. Any thoughts?”

(this is where we gather a little info, talk about what else they see in their client utility and whether they can access their wireless router’s admin pages)

Change your channel and expect to have to do that now and then. Stay on 1, 6, or 11. Here’s how to tell what’s best (point to free tools). Buy a 5 GHz router.

The problem usually goes away, or at least gets better.

Back to topic: rogue detection is nice, and I’d hate to be without it. And the quest for clean channels is worthy, never-ending, and can be frustrating at times when your WLAN lives in a busy, dynamic, unpredictable RF neighborhood. But I will give Cisco’s RRM a lot of credit, when tuned properly it does a pretty effective job of adjusting to the sort of variability and contention shown above, without being overly disruptive.

Competing signals are a way of life, and many of us WLAN types simply have to make the best of complicated situations.