I’m in the middle of the North American RuckU roadshow and one particularly intense segment is competitive. Of course Aerohive comes up in conversation given the great job they’ve done in penetrating the market.
You’d think a competitive session would focus on the negatives of a product however, with one exception, I really address their story more than the products.
Aerohive’s story surrounds it’s controllerless architecture. It has two distinct chapters:
1. No central bottleneck. Back in 2007 Aerohive saw the upcoming problem with 802.11n (and now 802.11ac) standard being so fast that centralizing all of that data to one point could be problematic. Does Aerohive have the best solution to this problem? Well, I think it’s fine but it is far from end-all. Here are two points of interest:
- One misconception that accidentally gets perpetrated is that all controller-based solutions centralize the data. False. Ruckus has controllers but doesn’t centralize the data unless you want to. Would a customer ever want to centralize (tunnel) all of the data to the controller? Sure. We have many customers that require the ability to centralize the data. I’m not talking about small customers here. I’m talking 500+ AP systems and major carriers. Aerohive doesn’t have a controller and therefore can’t do this.
- You could buy more controllers. Sure, this sounds crazy but if you are talking to a company that mostly centralizes it’s data (like Aruba and Cisco) then just buy more controllers. If you really like their solution then it’s the cost of doing business with them. Is it worth the cost? Just depends on what you want out of your Wi-Fi system.
2. No central point of failure. Of all Wi-Fi solutions out there their’s is the most resilient because it doesn’t have controllers. Just for fun I ask my audiences how many of them have a wired network with no central point of failure and doesn’t include redundant components. I have yet to have someone raise their hand. Your network either has single components that can fail or you have redundancy built in. If you have two controllers, each with 99.99% survivability, what are the chances that they both fail? Seriously, I’m asking. I don’t know the math but I suspect it’s a really, really slim chance. Your wired network has, at best, the same redundancy as your controller-based Wi-Fi system.
No matter what architecture your chosen system has it can NEVER increase the performance of your WLAN. The best a controller / controllerless architecture can achieve is “do no harm”. If you want to achieve phenomenal Wi-Fi performance you must start with the communication at Layer 1. Until your chosen system gets that right, nothing else matters.
Let the flogging begin. 
GT
P.S. Want a crazy prediction? Aerohive begins selling a controller.
When I first looked at Aerohive, I thought “this is great for my small customers with 2-5 APs”!
So… first potential customer I talk to is an insurance broker with 15 employees. Turns out that the broker knows another customer of mine that runs a 100 room hotel… I present the Aerohive solution and then the questions start. “Will my smart phone work in the elevator like “Mikes” hotel ? “Mike” can watch all 32 of his video cameras on his ipad, will I be able to do that? “Mike” has wifi video cameras watching his jag in the back parking lot, can i do that ? “Mike” says that his wireless network has been running for 4 years straight even when the power has gone off! Me- Well Mike has a big UPS powering everything to keep it running during a power failure. Customer- well make sure there is one of those UPS thingys on my quote.
Basically I have found that both large and small customers place controller resiliency way down on their list of priorities. Other than the occasional “we want all software and control at our physical location” , it barely gets discussed. Throughput and predictable performance seem to outweigh all other features. buy 2 controllers -resiliency dealt with.
Why would you want to tunnel all traffic through the controller? Aren’t you then just creating your own bottle neck for no reason?
I agree that without proper load planning that can happen for sure. There are many reasons to tunnel traffic. Since Ruckus can do either (selected by WLAN) we don’t really push customers one way or the other. Granted, the majority want distributed forwarding (no tunneling) but others really need the tunneling feature. Some want it so they can maintain their current switch configuration and others need the data to go through one central point for security, billing, monitoring etc.
GT
I guess its my calling to correct vendors mistakes in the posts
. A couple of weeks I pointed the mistake on Aerohive blog about DPSK features.
So here we go:
“Aerohive doesn’t have a controller and therefore can’t do this.”
Actually Aerohive can tunnel traffic to any location using GRE tunnels. This was supported for a while now (I think from 3.x FW) and they are extending this feature to their CVG product (HiveOS on the VM environment) so multiple 10Gb ports can be used to tunnel the traffic to (as VM environment scales so does CVG). Hardly a bottleneck in my book. While not as easy as clicking a tick for tunnelling WLAN as Ruckus has, the configuration is VERY simple and can be applied to thousands of APs. 2 minutes work at best.
I would add that Aerohive also has an advantage in that only data plane can be centralised to CGV while controller based solutions always transport control and management plane to the controller.
This allows for better implementation of time sensitive features like load balancing, band steering, RF management where the decision is made on the edge rather than waining for controller to make a decision (up to 100 ms away and that is a life time for RF decision making).
Furthermore applying goodies on the edge like Statefull firewall, QoS handling, WIDS/WIPS , Captive portal, Airtime allocations (that is like airtime fairness on steroids), L3 roaming, fast&secure roaming, etc., just make sense and provides for overall better performance.
And funny thing is that Ruckus also acknowledges this by implementing performance critical features like ChannelFly on the edge as well.
“You can just buy more controllers”.
Yes, if you are fine with the additional const of HW, licensing (double licensing for redundancy), cooling, powering, headend locations (remember, the boxes have to be within 100ms of the APs). Or, the client can spend the money saved for redundancy on their wired network side as it was the money problem that lead to not providing the redundancy in the first place
.
“Just for fun I ask my audiences how many of them have a wired network with no central point of failure and doesn’t include redundant components.”
Ruckus Wireless has one of the best management teams out there. It shows in their dedicated focus when pursuing market verticals. And Ruckus is strong in two of those: SME and Carrier market.
Now I doubt you will find any hand not being risen if the audience were tier1 carriers Ruckus has great success doing business with (and me personally being lucky to be involved with the couple of them). For SME it makes sense, especially if the wireless network is not mission critical for them. Saying that next time ask this question: “with the money saved from not needing to buy controllers and controller licences, would you be interested in investing that into network redundancy?”.
RF performance wise Ruckus is the king of the hill. No questions about it. Suggesting that it is the only technology being able to provide good WiFi service though… Just look at the Cisco performance on the Wembley stadium during the opening OI ceremony. Multi megabit client performance even on 2.4 GHz. Huge client density, press and photographs bringing in rouges, etc. With dedicated RF design and managing operations everything can be done. Even with vendor that, gasp, doesn’t even support Airtime fairness.
To end this comment:
Ruckus Wireless and Aerohive Networks are two of my favourite vendors, and I do business with the most of them out there. Both bring distinct and innovative features and there is nothing more I would like to see as a Ruckohive product. That would be the “one to rule them all”.
But I do not think GT would like my answer if somebody would press me to pick and choose just one technology I, personally, would be comfortable working with.
My 5 cents,
Gregor