Wednesday Dec 13
Nov
30/11
The 4 Wireless Controller Architectures You Need to Know
Updated on Tuesday, 31 January 2012 12:33
Share

Here are the 4 wireless controller/management architectures you NEED to know, and an overview of what vendor solutions fall where.

In the past several months, as we’ve been working on a variety of NAC implementations, I’ve had the grueling task of explaining to customers that their wireless system wasn’t quite what they expected. Instead of the super-easy management they anticipated, their choice in solution resulted in quite a bit of additional overhead, manual configuration on the wired side and in many cases, severe limitations.

With several new wireless solutions popping up in the last 18 months or so, there’s been an added layer of confusion piled on to an already mind-boggling suite of wireless systems. In the past, we had the simple categorization of autonomous AP systems and light AP or controller-based systems. Now, the controller-based category has sprouted branches of its own, and the myriad options are confusing the heck out of even the most technical buyers. Here, I’ve outlined the 4 types of wireless controller systems that can be used to describe all types of products in the marketplace.

With each of the 4 types, you’ll find a brief technical background explaining what’s going on under the hood, as well as some pros and cons to consider when selecting a wireless technology for your environment. I’ve even thrown in graphics to illustrate the functions. I can’t say there’s one single option that’s best, but you’ll see there are some that offer much more flexibility than others, although that may come at a cost and complexity not well-suited for some organizations.

As always, I’ll leave it to you to decide what’s best for your organization, but if you specifically selected one type of solution over the others, I’d love your feedback.

 

1.  Autonomous AP Architecture (no controller)

Full heavy APs, no central management design

We’ll start with the wireless system that is the oldest and easiest to explain – the autonomous AP system. Frequently referred to as heavy APs, autonomous APs are stand-alone access points with full intelligence integrated. You can have one, you can have many, and they’re all managed individually. In this system type, you can think of an autonomous AP as you would a switch.

If you want to add VLANs to support SSIDs, configure routing or set policies, it’s all done on the AP through its web GUI or CLI management. Each AP has an IP address for management, and each AP drops traffic on the switch it’s directly connected to. Because of this, routing and ACLs to control the traffic must be handled on a switch or firewall acting as the default gateway for each of the wireless networks.

Pros: If you just need a single or a couple of APs, an autonomous system will almost undoubtedly be the least expensive and fastest to procure. If you’re accustomed to using and configuring heavy APs, then this technology offers a small learning curve.

 Cons: If you have more than just a couple of APs, managing them all individually can be a nightmare. Updating wireless network SSIDs, upgrading firmware, managing management security and certificates, authentication details and pre-shared keys all have to be configured on each device individually and often results in mis-configurations, mis-matched configurations and frequently non-configurations, where someone adds an AP and just drops the traffic right on the wired production network. With this system, management is difficult, which leads to security vulnerabilities. In 99% of organizations I’ve seen still using heavy APs, at least 1 AP (and usually many more) has been forgotten or not secured.

Examples: Apple Airports, Cisco Aironet standalone APs, HP MSM (legacy Colubris) in autonomous mode, HP legacy HP AP420 and AP530, (Cisco) Linksys wireless routers

 

2.  Controller-based Management Only

Heavy APs with a central management software or hardware

To ease some of the management woes from the Autonomous AP System above, vendors began offering a Controller-based Management Only solution. Interestingly, this wasn’t the most prominent immediate follower to the Autonomous AP Systems. With these systems, the vendor offers a management system that can be used to centrally monitor and manage what would otherwise be autonomous APs. Think of it as you would any switch management tool, but modified a bit for wireless.

These controllers will help push firmware updates to APs, push security settings, push wireless networks and SSIDs, etc. But, underneath the hood, it’s just a management system modifying the configuration of each individual AP.

Pros: Controller-based Management Only systems offer a low entry price for a much more manageable wireless solution than autonomous APs. Some of these vendors offer the management controller as a virtual appliance and even as a cloud-based hosted service. Wireless-as-a-service and wireless-management-as-a-service is an extremely attractive option for organizations that don’t have the resources in-house to manage a more complex wireless system. Centralized management also makes monitoring and trending of wireless usage more easily accessible.

 Cons: Because the AP is still autonomous, it must be configured as such. The cons associated with these systems are usually related to the infrastructure needed to support the wireless, as opposed to management of the wireless itself. In general, the biggest pain comes from the need to extend wireless VLANs through the network and out to the port the AP is attached to. If you want 3 wireless networks on 3 different VLANs, you’ll need to deliver the VLANs to each AP port. If you decide to add a new wireless network in 6 months, you’ll have to repeat the process for that VLAN. If you’re using RADIUS- or NAC-assigned VLANs, you’ll need to bring every possibly-returned VLAN to each AP. On a similar note, if you’re using 802.1X for any wireless authentication, each AP will need to be registered with your RADIUS server as a RADIUS client and configured on both sides with the shared secret. With cloud-based hosted wireless management solutions, changes can be more time-consuming as larger configuration files and firmware have to be pushed from a server on the Internet through a WAN link and to your APs. And, from cloud-based controllers, the success of configuration changes can be spotty, and network admins may have to push settings multiple times for complete success on all APs, and in some systems the updates are pushed linearly, or to only a handful of APs at a time, proving to be quite an impediment during changes.

Examples: Aerohive, Cisco HREAP, Meraki, Xirrus
 

3. Controller-based with Traffic Tunneling

All wireless traffic is tunneled to a controller, APs have various capabilities

Controller-based with Traffic Tunneling solutions were most prominent immediately following autonomous APs, as the needs for central management emerged and grew rapidly. In these products, all traffic is tunneled back to the controller. The APs are light or semi-light and have little to no intelligence. In many of the original products of this type, the APs are really nothing more than a radio, whereas newer solutions offer more intelligence in the AP in the way of traffic management, monitoring and security features like rogue mitigation and WIDS/WIPS.

 With these products, the APs communicate to the controller over a tunnel, which may be encrypted, or may be a simple GRE tunnel. All traffic coming through the AP will be sent over the tunnel to the controller for traffic processing and management. The connection can be layer 2 or a layer 3, depending on the network. Some products offer an auto-provision feature that uses the controller and the switch to automatically put APs in a specific VLAN to ease deployment for layer 2 implementations. Whether layer 2 or 3, once the connection is up between the controller and the AP, all traffic is encapsulated in the AP-Controller tunnel and sent along. At the controller, traffic could be firewalled, routed, filtered or simply dropped on the network. By virtue of the technology (not the method of connection) most novel solutions in this category will also bring advanced RF management and troubleshooting.

Pros: The advantages of a Controller-based with Traffic Tunneling system are varied. In solutions with less-intelligent APs, the cost of the APs or radios is likely to be half the cost of their full-featured cousins. The smarter APs and more advanced controllers come with a higher price tag, but you’ll get many added features for your coin. With all products of this type, deployment is swift and simple. Knowing all traffic is being tunneled back to a controller gives network administrators ease of mind that wireless traffic isn’t benefiting from a rogue route or mis-configuration on the wired side. These solutions may offer encryption from the endpoint to the controller (versus just to the AP), adding some security on the wire. As with the previous type, monitoring and reporting on wireless usage is simplified, and newer products in this category will offer the more advanced RF management and troubleshooting needed in enterprise and campus environments.

 Cons: The cons can be as varied as the pros for this wireless system type. The most pervasive issue with a full traffic-tunneled solution is the inflexibility of design implementation. Products in this category must send all traffic back to the controller, and there exists no option to bridge or drop it locally on a switch. In most environments, this may never be an issue. In logically larger environments, environments that are passing large files over wireless and environments that are geographically disperse, this solution may not be well-suited. 

Examples: Aruba (except Remote AP), Cisco controllers including WiSM, HP WESM line (legacy)
 

4. Controller-based with Split Traffic

Wireless traffic can be tunneled to a controller, or bridged locally and dropped on the wire

 

Wireless products that offer a Controller-based solution with Split Traffic design are by far the most flexible of the 4 types here. In this arrangement, a controller can be configured to either tunnel traffic back to a controller, as in our previous system type – or – it can be set in bridge mode and drop wireless traffic on the switch it’s directly attached to. Most often, this behavior is desired when organizations want to drop authenticated wireless traffic on the wired network, while tunneling guest traffic to the controller and directly out to the Internet. In other scenarios, this configuration might be used to secure specific types of traffic to and from protected resources in the network, since this behavior can allow for encryption all the way to the controller, protecting data on most of the wired network as well as on the RF side.

 

Let me go one depth further here and tell you that the capabilities of this vary slightly from product to product. Some products can support split traffic on different wireless SSIDs within the AP, whereas other solutions may only be able to support an entire AP in either tunnel or bridge mode. If one method is of significant importance to you, make sure the vendors you’re exploring support your chosen method.

 

Pros: A solution of this nature is extremely flexible and can be configured to support a variety of enterprise needs. Although I’ve most often seen organizations choose a complete implementation of one or the other (tunneled or split), knowing the option to modify the wireless to meet changing business needs is comforting for network administrators and CFOs alike. As with the previous controller-based class, these solutions usually offer rich tools for monitoring and managing the wireless, both on the RF side and the configuration side, and all offer built-in and add-on tools for advanced troubleshooting and reporting. And also as found previously with traffic tunneling controllers, these products usually offer options to extend encryption all the way to the controller, instead of terminating just at the AP. At least one vendor in this category offers Fourth Generation Wireless technology (a term coined by Gartner), which although not directly related to the categorization here, usually accompanies these more advanced systems.

 

 Cons: Because of the added functionality and more developed management features, you can plan on these solutions being the most steeply-priced of our 4 wireless types. Due to the extensive options available when implementing these technologies, wireless managers that don’t have a solid grasp of both wireless (RF) technology and networking may find the array of menus and check boxes daunting, at best. Misconfigurations are more common in the more complex products.  Having said that, the remaining disadvantages are minimal, as this solution addresses concerns raised in all three previous wireless types.

 

Examples: Aruba (using Remote AP feature), Cisco controllers using Flex mode, HP MSM line (legacy Colubris), HP WX line (legacy 3Com), Juniper WLC line (legacy Trapeze), Meru Networks

 

I hope this clarifies some of the mystery behind the wireless, and specifically the wireless controller system capabilities. If you think any vendors or products should be added to examples, please let me know, post here, or have a manufacturer SE contact me. Other technologies charted in this year’s Gartner’s Magic Quadrant for Wireless LAN Infrastructure include Bluesocket, Motorola, Juniper (legacy Trapeze), Brocade.

Good luck on your wireless adventures!

# # #