So you will never win an argument with an @Aerohive
employee about controllers. I’ve discussed with them how there are some things (a lot really) that HiveManager does that is a function that controllers do. “Management Plane!” they scream in unison. No-one who has faced an @Aerohive
employee with the word controller has lived. We are survived by not mentioning controllers around them, but sooner or later someone is going to have to fight them.
Well, this isn’t the matrix Neo, but what @Aerohive does with their HiveManager product is implement a system of control. That system is designed to turn this:
*EDIT: This is a joke. I’m not saying that HiveManager is a WLC.
It’s a good article, well written and she articulates her point clearly, although I don’t agree with most of it. Please don’t take this as an attack on your blog, but I think that the good ol’ WLC will be around for a long time no matter how much the cooperative control marketing gets thrown around.
But Abby does try to define exactly what a wireless LAN controller is. Something I challenged her to define. And I did warn you #ItsATrap
She goes on to define what she calls a wireless LAN controller, but i think she misses a lot. Her definition is: “A wireless LAN controller is a device that directs or regulates traffic on the wireless network…” I’m truncating her definition. Not because I want to be snarky, but because you cannot define a WLAN controller by a vendor that sells WLAN controllers.
I actually find her definition pretty weak. A WLC does a LOT more than directing and regulating wireless traffic. I would say a better definition would be “A WLAN Controller directs or regulates the operation of a Wireless LAN.” While the distinction is small, a WLC is much more than the regulation of wireless traffic. You could even say that a WLC is a collection of multiple “System of Control.” A WLC also regulates what a wireless AP can or can’t do based on its features. I’m going to take a discussion that I’ve had with Abby and other @Aerohive guys around their BR series of routers/APs.
Did you know that a BR200 can operate as just an AP/Switch? Bet you didn’t. That’s because it isn’t supported by @Aerohive. Now the BR100 does this and is supported. So what I did was take the config that my HMOL pushed down to my BR100 (Thanks @Aerohive for providing me with one for attending #WLPC) and applied those same commands to my BR200 and Voila, an AP with a swiitch. All the commands are documented in their CLI Reference guides http://www.aerohive.com/support/tech-docs-and-online-training but they are supposedly not supported because HiveManager does not support this on the BR200 platform.
The moral of this story is that HiveManager, a supposed “Network Management System” regulates what an AP can or can’t do. I would say that it is not a NMS because it regulates and/or directs what can or cannot be configured on the equipment. And once you configure things via the CLI,
forget about managing it with HiveManager. Especially if you configure something that isn’t possible with HM. Here’s another example:
When trying to configure a port-forward on a BR200, I ran across the limitation that HMOL will only allow you to forward a port that is directly connected to the BR200 (the BR200 is the L3 interface for). I was trying to setup connectivity from my BR200 over to my home lab, and wanted to forward a port across a L3 routed link to my console server. No dice, HMOL pukes when trying to configure this. But if you configure the port-forward from the CLI of the BR200, it works, and works well (although likely unsupported).
There you have it, HiveManager, while not a controller, is certainly a system of control. I’ll tell you something else, even with a WLC not always do you “HAVE TO” have a NMS. I can deploy a WLC in a small network and configure and operate it without deploying the NMS. And while I’m sure you *could* deploy @Aerohive gear without HM or HMOL, it would be easier to try to rescue Morpheus from a military-controller building being held by three agents. I believe even the @Aerohive team-members would suggest spinning up a temporary version of HiveManager to get the initial config implemented.
P.S. Please don’t take this as “I don’t like Aerohive equipment.” The hardware is what you would expect from an enterprise equipment manufacturer. It’s been great in the lab and my 330 has been driving my wife’s wireless network for over a year with very few issues. The BR200 and 100 have been also been good, but the lack of support in HMOL for features has left a bitter taste in my mouth especially around HiveManager. I really think @Aerohive needs to take a hard look at Hivemanager and follow the philosophy of “As simple as possible, but no simplier.” Right now, the biggest thing holding back @Aerohive is HiveManager.
After a lengthy and good discussion on twitter, I thought i would clarify that I’m not saying that HM is a controller. It is fun to make correlations between HM and functions that common WLCs perform. When I say control, I do not mean a control plane. I just mean that the HM exerts control over the equipment. While it doesn’t participate in the control plane, limiting what you can do on the equipment in my book is defined as control.
While I disagree with how you've laid out your argument of what constitutes a “controller” and what constitutes an “NMS”, I'm not really going to comment on any of that because I feel like this whole effort of categorizing functional implementation points is one of futility in the bigger picture. Instead, we as an industry, should be focusing on the overall system capabilities, performance, stability, and high availability (interwoven with the inevitable pricing discussion). Does the system meet the requirements of the customer for their current use-case and future needs at a price they can live with? If it does, great! Who cares if it is implemented as an NMS, controller, APs or any combination thereof? I don't. Customers shouldn't.
Unfortunately, the reality is that all WLAN vendor's like to play these marketing definition games in order to show product differentiation and advantages in their own cooked-up scenarios. Sure, there are a few scenarios where these implementation differences make a difference. But more than likely it all comes down to a pricing difference to achieve the same result. And we know that vendors will play the pricing war with one another in most circumstances.
Let's forget about arguing marketing and keep the focus on meeting customer needs.
Andrew von Nagy