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.
René Jorissen
Latest posts by René Jorissen (see all)
- MacOS Big Sur and SSLKEYFILELOG - November 23, 2021
- ClearPass, Azure AD, SSO and Object ID - August 12, 2021
- ClearPass – custom MPSK - July 20, 2021