The Downsides of Big Wireless
Lee H. Badman
September 11, 2012
Wireless networks have come a long way in the last decade. But the evolution hasn't necessarily been all good for customers of today's super systems.
Today's high-performance 802.11n networks have their roots in the less sophisticated standards that came before them. Data rates of 300 Mbps are impressive, but back in the day, 2 Mbps of airborne data was buzzworthy. Back then, access points (APs) had their own intelligence that had to be managed on each unit, and the general wireless landscape was a lot more sparse.
- Forrester Study: The Total Economic Impact of VMware View
- Operational Insight for Running IT at the Speed of Business
- SaaS and E-Discovery: Navigating Complex Waters
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
Around 2006, I made the same jump that many of my peers were making: With an eye to the future and knowing that my 600 AP WLAN would eventually grow exponentially, I migrated from stand-alone access points to a thin-AP-based "wireless super system." With enough budget, a super system promises that you need to manage only a small number of central controllers that in turn manage APs, that location-based utilities will open exciting new possibilities for the WLAN, and that robust management, monitoring and reporting are yours for the taking. What's not to love?
Though my own high-dollar wireless system has provided hundreds of thousands of client devices with respectable connectivity through the years, the modern wireless system is not without drawbacks, and it matters little whose gear is being discussed. Everyone has a white paper proclaiming them the best, but most vendors all share in common sins, as well.
Unlike with routers and Ethernet switches, "standards-based wireless networking" is, at best, a half-truth. What comes out of antennae and interacts with client devices certainly has to play by 802.11 rules. But that's where standards pretty much end and vendor lock kicks in. In the wiring closet, no one is the wiser if I simply replace a Juniper switch with one from HP. Chances are they'll dance nicely together to the tunes of SNMP, VLAN trunking and QoS if I ask them to. But when I get a hankering to try Engenius' new ENH700EXT Dual-Radio Outdoor Wireless-N AP/Client Bridge with my Cisco-based wireless network, I'm screwed. Basically, no one plays with anyone in the modern wireless sandbox, and it's a bit frustrating when you find a wireless device that might fill a niche that your own vendor doesn't, or doesn't to your liking.
Even within a single manufacturer's product set, there can be frustrating lines in the sand that can't be crossed. A typical scenario: You need to move controllers to a new code version in response to an operational or security bug in the current firmware, or a desired feature that's long awaited--but when you do, your older APs are no longer supported. Good times.
Then, there's the proverbial management plane, or whatever you choose to call the "keep it all going" side of the system. I have found that the management systems for Big Wireless can be their own headaches. Costing righteous bucks and bringing their own complexity to the network, management systems are critical resources when lots of APs and clients are present. When the management tools go down, you're screwed again--and they do go down. I recently lost my own WLAN management system for over two weeks while the vendor poured through database tables, logs and my VM environment, leaving my management needs basically unfulfilled. I learned how good I am at tap dancing to minimize the embarrassment of having no reporting and limited monitoring capabilities when I very much needed them at semester opening on my very large university WLAN. Ugh.
Let's not forget that even when the management system is healthy, there tend to be annoying gaps between what can be done through your *ahem* single pane of wireless management glass and what has to be done via controller GUI or command line. Those gaps can be significant, confusing and time consuming to work through when you have to hit dozens of individual controllers because the central management system doesn't have a given config capability.
Where used, controllers also bring another layer of cost. Until controller virtualization goes mainstream, these appliances not only fetch a big up-front cost when licensed for use in big environments, but they also get you with ongoing support fees. BYOD and the trend to go all wireless mean more APs; APs mean more controllers; and more APs and controllers mean bigger expenditures on hardware in a time when many IT shops are looking to reduce device counts in favor of virtualization (or cloud services). Expect a paradigm shift here in the next year or so, as market leaders look for ways to mimic creative controller alternatives already provided by Bluesocket, Meraki and Aerohive.
And the rant goes on. Big Wireless can leave you lacking in per-AP config granularity. Depending on the solution and code version, you may have to configure all APs identically, with no nuance where different data rates and such are needed. At the same time, the modern wireless system is trying to do ever more: NAC, supplicant configuration, guest access, security, mobile device management and spectrum analysis. All of which is great, when it all works to your liking. But it often doesn't, which means you change how you do things to match what's offered by Big Wireless, or you look for a third-party solution while leaving features that you likely paid for unused because they often feel like they were developed by folks who have never ran a real network.
Ah, well. The good old days of wireless are gone, and I really don't pine for them that much. If I put my mind to it, I could easily pen a column on what we've gained with modern wireless systems. At the same time, today's WLAN is getting ever more complex, and complexity can be problematic in and of itself.