Relevant mostly to OS X admins
For years, my workplace has been relying on a team of Apple Airport Extremes to provide WiFi. Don’t laugh: for a consumer-grade product, they work very reliably, and were quite easy to do my first RADIUS authentication setup. But they’re aging, and the importance of WiFi is only growing, so it’s time to level up to professional gear. (Plus, I need to move my wireless authentication off of an Xserve. Again, you can stop laughing.)
As I started to consider which vendors to evaluate, my research told me there isn’t any clearly bad choice in the enterprise WiFi market. Aruba, Cisco, Meraki, Aerohive and Ruckus all make quality products. Reading around online, I could find both fans and critics of all offerings, but no clear lemons on the market. That’s a good problem to have, but does make the selection process more daunting. I have tested 2 systems in my workplace so far: a set of 4 Meraki MR16’s, and a Ruckus loan of 2 7892 APs, and 1 7363. Instead of a feature to feature comparison, here are some of the points where I saw significant differences between the products:
There are multiple reasons I prefer working with MacOS, the user interface is one of them. Meraki’s online dashboard feels like it was made by “Mac Guys”. It’s logical. It makes sense with minimal interpretation, I (mostly) find controls and options where I’d predict they would be. Ruckus ZoneFlex leans Windows. It’s functional, but it’s never elegant. I could do what I wanted to in either one, but Ruckus makes me work harder.
Meraki’s help is integrated into the online dashboard, it ties your tickets, knowledgebase and online manuals into one interface. For each submitted ticket, I’d get the assigned from the pool. Ruckus assigned me an engineer who gave me his mobile phone number and email address. I like having “my guy” to go to, vs the support pool.
Meraki AP’s mesh by default. It’s pretty neat to drop the ethernet connection from an AP and have it part of the group, turning from putting data out via the wire to handing it to another AP (presuming it’s within distance of another AP!). It works great. On first configuration of a Ruckus deployment, the wizard asks if you want meshing. I presumed I would, but didn’t realize there’s a tradeoff in Ruckus world: if you enable meshing, band steering is disable- until you go into the CLI and issue a command to enable band-steering. Not the slickest configuration. I don’t foresee needing my APs to mesh, so this isn’t a win for Meraki.
Meraki is the clear winner here. Very easy to set up all sorts of L3 or L7 rules- anything from basic port/destination blocks to social media rules or bittorrent traffic shaping. However, I can’t call this a clear win for my use case, as the rules would only apply to the WiFi network: plug in to Ethernet, and the situation is different. But if you run a deployment of many iPads, you might love this.
Again, Meraki wins with useful graphs and reporting, with much more data to drill into than Ruckus. If you want/need that or not is a separate question.
Ruckus has the ability to grant unique preshared keys for access to your guest network. A group of your users can be given permission to create temporary keys with predetermined expiration date/time settings, created via a web interface on the Ruckus controller. Guest network access via Meraki cannot be unique per client. Ruckus also offers a “Zero-IT” option, where users can authenticate via AD or other credentials via an “onboarding” SSID, and then download an installer that will configure the machine’s wireless networking for the production SSID, and set a unique preshared key. In my testing, this worked great for Windows 7 clients, but OSX clients require administrative privileges to install, which would be a problem for many environments.
Meraki wins for ease of setup of a separate DHCP space for a guest network- it’s “check the box, stupid” easy, with the Meraki gear providing the DHCP server. Ruckus requires VLAN tagging, which gets tweaks to the switches, router and DHCP server all involved- a whole lot more overhead.
One of the most important questions I asked of my test APs is “what happens to a streaming connection when a client changes from range of AP1 to AP2?” To test this, I put APs on 2 sides of a wall I’ve mapped to kill WiFi dead: knowing that a client would roam between the APs. I then started up a FaceTime call with a co-worker, and walked through the doorway in that wall. The Meraki APs would consistently drop the connection, while the Ruckus would let me walk anywhere around my building, maintaining my FaceTime connection. I could then return to the admin console, and see the logs of that mobile client being handed from AP1 to 2 to 3, invisible to the FT call. If we someday move to handheld VoIP phones, this functionality will be important. My 2 week trial of Meraki was over before their engineers and I were able to make those handoffs work as expected.
It would be great fun to spend all my free time evaluating WiFi hardware, and there’s probably a great argument for testing $other_vendor too. But at some point, we have to just move, and I’m pretty sure that move will be to Ruckus. There’s an upgrade to the 7363 due out soon, which will most likely be our choice.