Connecting the world…


Wireless controllers – the discussion continues

There is already a lot said and written about wireless controllers and it’s architectures. During my recent holiday my thoughts were wandering about this subject. At the beginning we had the stand-alone access-points, which were all configured as unique identities. Choosing the correct channel and power level could be a challenge in dense environments, so everybody was happy with the centralized wireless controllers.

The centralized wireless controllers were the solution to manage channel and power allocation with their build in ARM functionalities. But also the centralized management of the entire wireless environment was a great improvement for the management burden of IT personnel. Key players, like Cisco Systems and Aruba Networks, adopted this architecture and developed some outstanding wireless controllers. Over time more and more feature were added to the controllers, like spectrum analysis, wireless intrusion prevention systems, L3 roaming and advanced reporting. For some features you have to buy a separate license or you should use dedicated software or hardware, but nonetheless you have a easy to manage and flexible wireless design.

Some people started to discuss this architecture and found some disadvantages, like availability and scalability. The access-points are all managed by a centralized wireless controller, but what happens if the controller goes down? Who much time does it take to failover to a backup wireless controller? What license construction do I need when I would like to implement a redundant wireless controller architecture? Why do I need to tunnel all traffic from the access-points to the wireless controller, before the data of wireless clients accesses the wired infrastructure? Isn’t this a disadvantage for latency, delay and jitter characteristics? What is the impact for the controller when tunneling all traffic and who can I scale the controller to the future? These are all valid questions and some vendors decided to develop another wireless architecture.

Maybe the most well-known is AeroHive with their controller less wireless architecture. The wireless controller functionality is integrated in the access-points, but the management is still centralized. Every access-point is operating as an autonomous entity, but all access-points communicate with each other to form a hive (in AeroHive terminology). All configuration and monitoring is done through a centralized management platform. The impact of access-points loosing their connection with the management platform is minimal. The access-points stay online and stay operational for wireless purposes. This means that the wireless environment doesn’t depend on one or more wireless controllers.

But is this the most ideal situation……. not in my opinion. A few weeks ago a customer couldn’t’ access this manager for a couple of days. No problem, because the wireless infrastructure kept working like a charm. However the customer wasn’t able to do any kind of management and monitoring. He couldn’t see what was happing on his wireless LAN and he couldn’t add additional guest users to the AP user database. The question at that moment was: “Do we keep using the wireless infrastructure without any kind of monitoring and management with all risks associated or do we physically shut down the wireless network by disabling the PoE on the switch ports?”

There are some more “disadvantages” for a controller less architecture. VLAN extension (to a remote location) is difficult. This can be accomplished by configuring GRE tunneling between the remote AP’s and the HQ AP’s. With GRE tunneling you can extend the corporate VLAN to remote locations. The remote AP is the source of the GRE tunnel and the HQ AP is the destination. Another topic is RADIUS authentication. In a controller less architecture every AP acts like a RADIUS client. This can have impact on your RADIUS server. For example a Windows Standard server has a limit of 50 RADIUS clients. This means that you have to use a Microsoft Enterprise or Data Center server. You can also configure RADIUS proxy on the wireless environment. This means that all RADIUS from the AP’s are routed to the a couple of designated AP’s, which act as RADIUS proxy. You should also keep in mind that all traffic is directly routed to the wired network at the access-point. If you are using different VLAN’s, you shouldn’t forget to tag this VLAN’s on the uplink connections to the access-points.

I was talking about disadvantages. The topics aren’t real disadvantages, but more design issues. The point that I am trying to make, is that even a controller less architecture is sometimes working as a controller based wireless architecture. Because building GRE tunnels from remote locations to central AP’s or using AP’s as RADIUS proxy behaves, in my opinion, as a controller based environment.

So the discussion of a controller based architecture, a controller less architecture with a separate manager or a controller less architecture with a virtual controller will continue and every vendor will be saying that his solution is the best. I am very curious about your thoughts on the different wireless architectures.

Please keep in mind, this article is based on my experience and opinion. Also note that I am NOT saying that the solutions of the different vendors aren’t good choices to build your wireless network. I am using and will be using the solutions from the mentioned vendors in this article. Every solution has its advantages and disadvantages. Just look at the requirements for your wireless networks and choose the best suitable solution.

AeroHive HMOL Redirector issue

When using the HMOL solution from AeroHive, an access-point will discover the correct HiveManager by connecting to Within the HiveManager management interface you can see which access-points have been redirected to your HMOL. This can be down by checking the Device Access Control List within the Redirector configuration.

Sometimes you will notice that not all the serial numbers are listed on this page. When this is the issue the new access-points will not connect to your HiveManager. You can try to enter the serial numbers yourself by using a csv file or enter the serial number separately. Most times I receive an error message for multiple serial numbers, like shown below.

Same serial number “serial number” already exists. Cannot override the catagory information.

When you receive this error message, you have to redirect the access-point yourself. This can be down very easily. Connect via SSH to an access-point, which is redirected to your HiveManager. Enter the following command and look for the following two lines:

AH-001#show config current
capwap client server name <AeroHive HMOL hostname>
capwap client vhm-name <Hive-name>

Now login to the access-point, which aren’t redirected to your HiveManager. You have to retrieve the IP address settings of these access-points and just login with the default username (admin) and password (aerohive). Just paste the 2 commands in the config.

The only thing you need to do now is, sit back and enjoy your coffee.

AeroHive – access to MyHive landing page

The AeroHive user, which is created by default, gets a landing page, when logging into The user can choose between the HiveManager Online and the Redirector.


When the users chooses the HiveManager Online or the Redirector, the user has the option to return to landing page by choosing the MyHive option in the upper right corner.


Subsequent users don’t get the landing page by default and don’t have the option to choose the MyHive option. Subsequent users (even if the belong to the group Configuration and Monitoring) don’t have the permissions to access the Redirector.

The default user has the option to provide access to the landing page. This configuration is done per user and can only be done by the default user. Just edit the user and enable the option “Give user access to MyHive landing page”.


When the users logs in to his HiveManager page, he will get the landing page to choose between the HiveManager Online and the Redirector.

AeroHive Spectrum Analysis

One cool feature about AeroHive is the build-in Spectrum Analysis feature, which is enabled by default from HiveOS 4 and higher. Spectrum analysis is very useful to get a view of the RF environment near an access-point.  This is especially useful when troubleshooting bad connections (high volume of retransmissions) or other problems related to the RF environment. A spectrum analysis can help to detect interfering components, like bluetooth devices, cellular phones or a micro wave.

HiveAPs even have the possibility to recognize device types, which interfere with the wireless environment. Device identification is only possible with HiveAP 110, 120 and 170 access-points. The HiveAP 320 and 340 cannot perform any kind of spectrum analysis and the HiveAP 330 and 350 can perform a spectrum analysis, but don’t have the device identification feature.

To perform a spectrum analysis with AeroHive, you need to configure at least one SSID. When the SSID is configured you have the option to perform the analysis in both the 2.4 Ghz and the 5 Ghz band.

To start the analysis, open the HiveManager, click Monitor – Access Points – HiveAPs and select a HiveAP, then click Tools – Spectrum Analysis to begin the spectrum analysis. The screenshot below shows the spectrum analysis pane.


A full description of the different panes can be found in the online HiveManager WebHelp. I like the spectrum analysis feature, because of it’s power and strength during troubleshooting and planning of a wireless environment.