Who remembers the announcement from December 2012 when Aruba jumped into the Application Visibility and Control arena with their 7200 controller and plans for AppRF? It was a very exciting time in the wireless world seeing how mobility is impacting networks and the level of visibility required in order to move towards a mobile-first enterprise.
What I find surprising, however, is that even after a year, Aruba only just now has the actual “control” part available in their 6.4 software for the 7000 series controllers. Ooops. I suspect real-time packet processing in a central appliance was harder to deliver than anticipated. Maybe we should take a step back and investigate what happened as we wonder how long customers have been waiting for this promised functionality in their shiny new controllers?
I have to admit, when I first saw the announcement from Aruba back in 2012, it was exciting. I loved the cool new video that accompanied the launch and I thought to myself - man, this is neat stuff. Then I started reading more about their brand new controller “optimized for 11ac” and delivering “integrated visibility and control over both traditional server-based applications as well as cloud-based and web-based mobile applications”, and realized that while their marketing department was clear on what they want, they may have gotten a little ahead of their actual technical product delivery.
Even the datasheet clarified that "Running on the 7200 series Mobility Controllers, AppRF identifies a variety of applications and who is using them.” It went on to say that you could use the PEFNG firewall to block or allow protocols, but not applications. So really, you can buy the fanciest new controller, plus the cost of feature licenses to apply firewall and security features, and still not have Application Control? Sounds like a heck of a deal!
But thankfully, I recently read the new documentation on ArubaOS 6.4 and it sounds like the 7200 series FINALLY gets the ability to create stateful firewall and QoS policies for applications (let’s hope you weren’t one of the unfortunate customers waiting for this feature on the 3000 series - sounds like a no-go :-/). This is great news right? I mean, in their press release from Dec 2012, they said they have a university that plans to support “3500 access points and 46,000 users” by replacing their controllers with the 7200s - so they can finally do all the application visibility and control they need for an “entire campus.” I just really hope they have budget for more than one of these $50k+ devices, though, because they are going to very quickly hit the limit of this massively expensive device:
Now you may be thinking “why would you design a network with a single controller for over 2000 APs or 32k users?” And I agree. Why indeed? I mean, if we do that math, that works out to what - 16 clients per AP? Is that how you’re designing your network? Gonna need a lot more than one AP per classroom to meet that ratio ;-).
More importantly are the specs posted on the 7200 web page. This device, custom-designed for supporting 802.11ac and gigabit speeds per user, notes a top speed of 40Gbps for large packets and a mere 2M concurrent firewall sessions. Uh oh. Now we have a true math problem. So you can connect up to 2048 11ac APs, each with at least one gigabit uplink, with 16-100 users connected per radio (with average speeds between 433Mbps and 1.3Gbps each, per this handy document: and top out at at just 40Gbps (and remember - most devices aren’t sending large packets, so let’s assume going downhill, with the wind blowing, that the IMIX speed is more like 25-30Gbps) and 60 sessions per device?
Let’s hope that most of them aren’t power users. Or using Skype, file sharing, or any other app that regularly opens many multiple concurrent sessions.
Ok, so we probably all agree that connecting all those devices through a single controller is bad network design anyway. But wait - we haven’t even discussed the application control part yet. These session limits and throughput numbers don’t include running deep packet inspection for AppRF, so the stateful firewall can actually categorize those packets!
Where are those numbers? If we assume a 15% degradation to speed and throughput that affects nearly every DPI implementation on flow-based systems from every vendor, this extremely expensive controller quickly becomes quite the bottleneck. That university will need at least 4 of them just to keep up with 46,000 users - assuming each of those users only has a single device. How many are in your briefcase?
Obviously, I have an opinion on this, but please do go check all the references I listed throughout this blog. People have wondered why Aerohive has put so much focus on our distributed and controller-less architecture lately. Well, the proof is in the pudding, folks. Mobility has changed how we operate, and any single device, even the shiniest, newest, fastest controller on the market, cannot come close to keeping up with the speed and visibility requirements of a large-scale 802.11ac enterprise.
So ask yourself why Aruba bifurcated their product line, created Instant, and yet still leads with controllers for advanced features? It sounds like they’re learning that creating a highly scalable, distributed architecture is more challenging than they anticipated. Features like AppRF, Layer 3 roaming, stateful policy-based firewall with flow-based forwarding, and sophisticated QoS require a Cooperative Control solution vs just a “controller-less” one.
The future of mobility is real-time application visibility and CONTROL, and the only way forward is to distribute the packet processing and scale linearly.
Even with deep packet inspection, distributing the load across the entire edge means that packet processing happens real time and is easily enhanced by adding another device when the load increases. Welcome to the mobile-first enterprise, folks. Welcome to Aerohive, the future of mobile-centric networking.