Introduction
Updated 17 Feb 2010: Corrections and clarifications from Meraki feedback.
| At a Glance | |
|---|---|
| Product | Meraki Hybrid Cloud Wireless System |
| Summary | Wireless LAN system for Small to Medium Businesses with Cloud based management and mesh capability |
| Pros | • Broad selection of AP hardware • Simple to set up and administrate |
| Cons | • No inexpensive N APs • Real-time status is difficult to come by; can be frustrating to debug • Can’t manage the network without an Internet connection |
Once upon a time (actually only a few years ago), mesh wireless networking was all the rage. And with the promise of self-configuring wireless LANs that could extend connectivity beyond the range of a single AP, why wouldn’t it be?
So companies like Firetide, Tropos and even Motorola and eventually Cisco jumped on board the wireless mesh train. But their aim was not to help households easily configure reliable, whole-home coverage. Instead, their focus was, and still is today, building campus-wide and outdoor wireless networks for private and public customers.
A relative newcomer to mesh, Meraki had its roots in the Roofnet project developed at the Computer Science and Artificial Intelligence Laboratory of the Massachusetts Institute of Technology. According to this Ars article, MIT grad student Sanjit Biswas co-led the Roofnet team and co-founded its commercial spin-off, Meraki.
Meraki captured a lot of attention by initially developing a cheap ($50) 802.11b/g mesh node powered by free, open source software. But when the company exited Beta mode (and after receiving "less than $1 M" in venture funding from Google), it changed its pricing and service model to include higher hardware prices and a hosted services model for managing the mesh nodes.
In the hubub that ensued (described in these Wi-Fi Net News and DailyWireless pieces), up sprang Open-Mesh with a mission of continuing to produce affordable, "open mesh" hardware and management software for building mesh wireless networks.
I’ve been wanting to try out mesh wireless since I first heard about it. But acquiring compatible hardware and reflashing it with Open-Mesh’s firmware was more work than I was able to set aside time for. So I contacted Open-Mesh at the end of 2008, asking them if they were interested in providing product for review, but never heard back.
So when Meraki contacted me last October and asked if I would be interested in checking out their new 11N APs and Enterprise Cloud Controller, I really couldn’t say no. But the holidays, CES and a few other things got in the way until I was finally able to clear the decks and dive into Meraki-land.
The Meraki Approach
Meraki’s target customers are typically looking for wireless networks serving from 50 to 5000 users, i.e. small to medium businesses / organizations. And many times these folks don’t have wireless gurus on site to build and manage the WLANs.
So Meraki’s focus is on simplicity and ease of setup, instead of the "speeds and feeds" focus of its competition. This approach extends all the way from its marketing material through the end product. But, as I found while working with the Meraki gear, this approach can sometimes be quite frustrating to users who know their way around wireless networks.
In keeping with its approach, Meraki recently revamped its website and marketing material to emphasize a focus on applications vs. features to prospective customers. This emphasis starts from the second you hit its site home page, which directs you to select either a Wireless LAN Solutions path (for "Business, Education, Manufacturing, Health Care") or Public WiFi Systems (for "Hotzones, Hospitality, Residential Developments").
The Public WiFi Systems landing page trumpets "Wireless Networks that Simply Work" and features pictures of its cute and cuddly $150 Indoor and $200 Outdoor 802.11b/g APs. While the Wireless LAN Solutions page features a bold exhortation to "Discover the Power of Cloud-Managed Wireless Access Points" with a photo of its no-nonsense business-grade MR series 802.11n AP.
Figure 1 shows Meraki’s entire hardware product line so that you can get an idea of pricing. Note that the cheapest single-radio 11n AP (the MR11) costs $600—closer to Enterprise AP pricing than you might expect.
Figure 1: Meraki APs
All the 11b/g based hardware includes the ability to use it with Meraki’s "Pro" Cloud Controller, without paying an additional license fee. But if you want 11n gear, then you need to step up to the "Enterprise" Cloud Controller, which costs $150 per AP for a one year license or $300 per AP for three years. The only exception is that you can buy the top-o-the-line, $1,500, three N radio MR58 and use it on a "Pro" Controller. Such a deal!
By the way, don’t let the server racks and descriptions in Figure 2 fool you. The "Pro" and "Enterprise" Controllers have exactly the same feature sets. The only difference is the APs that you can use with them.
Updated 17 Feb 2010
Both the controllers shown in Figure 2 operate "in the cloud" and don’t require any onsite hardware.
Figure 2: Cloud Controllers
The difference between the Enterprise and Pro Controllers is summarized in Figure 2a below.
Figure 2a: Enterprise vs. Pro Controller Features
You also don’t have the option of having a local backup controller to keep your network managed in case your connection to the Cloud goes down. That is, unless you spend $1 M or more on hardware, in which case Meraki will discuss local controller pricing on a case by case basis.
Updated 17 Feb 2010
Note that in the event of an Internet outage that results in loss of contact with the Meraki "mother ship", your network will keep running. You just won’t be able to manage or monitor it until your Internet service is restored.
Hardware
Meraki’s assortment of 802.11B/G and N access points are all based on Atheros wireless chipsets. I’ll show you the innards of a few so you can see what makes them tick. Figure 3 shows the FCC ID photo for the Indoor unit. Note that the current product doesn’t have the RP-SMA connector shown at the left of the photo.
Figure 3: Meraki Indoor AP board
A closeup in the FCC ID docs shows an Atheros AR2315 Single-Chip 2.4 GHz Access Point Solution under the flexible black heat spreader at the center of the photo. The Indoor and Outdoor APs both have separate power connectors. The Outdoor unit comes with a PoE power injector to simplify installation, but the Indoor unit doesn’t.
The popular MR14 dual-radio AP is shown in Figures 4 and 5, where you can see the radios on mini-PCI boards.
Figure 4: Meraki MR14 board top
More detailed photos in the FCC ID file show an Atheros AR7161 600 MHZ Wireless Network Processor, IC+ IP1001 single chip Gigabit Ethernet NIC and two Unex DNMA-92 802.11n a/b/g wifi 2×2 mini-PCI modules, which use the Atheros AR9220 single-chip dual-band 11n 2X2 MIMO device.
Figure 5: Meraki MR14 board bottom
The MR11 uses the same chassis and only one of the same radio modules.
Note that while both of the MR14’s radios are dual-band, one handles the 2.4 GHz band while the other handles 5 GHz. Meraki says that when the MR14 is used in a mesh configuration, both radios can handle client connections, but only one is used for the mesh link. Meraki’s proprietary mesh routing routine figures out the best one to use.
If you go for the three-radio MR58, then a radio can be dedicated to the mesh link, which will operate in the lower 5.1 GHz channels of the 5 GHz band.
Setup
Meraki goes out of its way to make the purchase and setup experience as simple as possible. If you’re making the purchase on your own vs. working with a Meraki reseller, you just go to their online store, where you’ll be first directed to choose a Cloud Controller (as per Figure 2), then select your access points from the options shown in Figure 1.
If you choose the less expensive "Pro" cloud controller, you’ll still be shown the more expensive 802.11n MR series APs, with a note that they require an upgrade to the "Enterprise" Cloud Controller. But if you start out with the "Enterprise" Cloud Controller, you’ll be shown only the 11N APs, along with an "additional Access Points available" note and an 800 number to call for details.
Meraki says that most buyers now opt for the 11N APs, with the dual-radio MR14 the most popular choice. They also told me that most installations choose to use Ethernet to connect up their multiple APs, instead of using the mesh capability that Meraki initially built its business on.
After you receive your APs, you set them up by first creating an account at http://dashboard.meraki.com. This URL auto-forwards you to a secure site, where you enter the info shown in Figure 6.
Figure 6: Account creation
Once your account is set up, you can log in and make your way to the Configure > Add access points section of the Cloud Controller (Figure 7). Entering your order number (included on the order confirmation email) is the easiest way. The order in Figure 4 had two APs, which are shown after I pasted the order number in the left side box.
Figure 7: Add APs
By default, Meraki places your APs on a Google map based on the street address on your order. You can also upload floorplans or other images that can be used to show AP locations. Figure 8 shows a simple map I uploaded that represents the lower level of my home.
Figure 8: Uploaded floorplan for map
Once your APs are recognized, you’ll probably want to vist the other Configure section pages to tweak your setup a bit. But, in keeping with Meraki’s design philosophy, the controls are pretty simple and don’t let (or require) you to futz with individual AP settings.
The Network-side settings page is a good example of this. You’ll need to look at the larger version of the page to see all the settings, which include disabling the lights on APs, how to handle clients directly-connected to AP Ethernet ports, when to scan for Rogue APs, setting a maintenance window for Meraki to make any necessary updates to your APs and enabling public access to nework status information.
Figure 9: Network-wide settings
There is also a Radio Frequency Settings section which provides only controls for setting Country, 2.4 GHz channel, Dual-band selection and Channel spreading. If you leave the 2.4 GHz channel and Channel spreading controls to their "auto" defaults, then Meraki’s algorithms can have free reign on optimally assigning your APs’ channels
Setup – more
Anther Configure page containing many useful settings is the Access Control page (Figure 10). Again, you’ll need to view the larger image to see all the settings, which include encryption, sign-on (direct, click-through and sign-on splash pages and paid access), per-client bandwidth limit, and client IP assignment. The last control assigns wireless client IPs either from the Meraki controller, establishing a NATed WLAN, or from your LAN’s DHCP server, creating a bridged WLAN.
Figure 10: Access control settings
This page also contains numerous options for controlling client access, including MAC address white and black lists and, if you’re using the NAT mode, content filtering (using OpenDNS) and LAN isolation. If you’re in bridge mode, you can enable 802.1Q VLAN tagging.
Finally, the Wireless options section of this page provides three choices for client band selection and an 802.11b legacy enable / disable. Band selection choices are Dual Band, 5 GHz only and Dual band with steering. This last option detects clients capable of 5 GHz operation and steers them to that frequency, while leaving 2.4 GHz available for legacy clients.
The Meraki system can handle up to 15 SSIDs per network, although using the older, less-expensive 802.11B/G APs will knock that down to four. Figure 11 shows the Configure > Overview page, where you set up the SSIDs.
Figure 11: Setting up SSIDs on the Overview page
I’ll just mention two other Configure section options, which you can explore via the simulator. If you’ve enabled it on the Access control page, you can configure the Splash page. And if you’re running in NAT mode, you can enable and configure the Meraki Toolbar, which will be added to users’ browsers. The toolbar can be branded with a logo and configured to contain up to 25 custom messages and selected web feeds.
Note that there are no controls for QoS, WMM, power save, fragmentation, beacon period, transmit power or channel width (for N APs). As I noted earlier, Meraki handles all of that for you.
In Use
So what’s it like running a Meraki network? Well, the good news is that it really is simple to configure, even for mesh APs. All I did was connect an AP into my office LAN’s switch as the gateway AP, take another AP upstairs, select a spot and power it up. Within a few minutes, the AP’s signal strength LEDs changed from a mesh partner search scanning pattern, to a steady signal level display indicating a successful mesh connection.
The bad news is that I had to lower my expectations of responsiveness for the Monitoring section of the Meraki Cloud Controller Dashboard and get accustomed to seeing mismatches in information presented in different pages. These mismatches were especially frustrating when I was trying to determine what was connected to what during my performance testing.
As an example, Figure 12 shows the Access Points Monitor screen, which displays three active APs, MR11, Office Gateway (an MR14) and Upstairs Mesh (another MR14). But I knew that I had disconnected the MR11 and replaced it with the Office Gateway MR14. However, the incorrect status for the MR11 persisted, even when I enabled the Live updates option, which refreshes the screen (and status) every 30 seconds instead of its usual (at least) every few minutes.
Figure 12: Access points monitor screen
Figure 13 shows the detail screen for the MR11 AP, obtained by clicking on its link in the Access points summary page. The correct status presented clearly contradicts the information on the AP summary page. And note the Status message, which correctly states that the AP has been unreachable for 22 minutes.
Figure 13: Individual access point monitor screen
Another data delay can be found in the Event log, another logical place to go when you’re trying to figure out what’s up with your network. The delay here between the information being captured by a Meraki AP and showing up in the log is around 5 minutes, according to Meraki. Not too bad if your network if running fine. But if you’re trying to find out why you’re getting angry phone calls from users who can’t connect, 5 minutes can be a very long time.
The Access Points and Overview pages also have similar data delays and some inconsistencies, which further inhibited my ability to quickly find where clients were connected.
For example, both will eventually show the number of clients attached to each AP, as Figure 14 shows in the Overview screen. And clicking on the AP in the map produced a nice popup with AP details. But the Usage information of 1 device transferred none in the last day isn’t very helpful. I also found that the number of clients shown in the Overview page was often inaccurate, reflecting clients that were no longer on the network.
Figure 14: Overview screen with unhelpful client detail
Clicking over to the AP detail page (Figure 15) doesn’t help either. This page has a lot of information, but connected clients isn’t among it. And although the AP icon in the mini-map in the upper right corner of the page is properly green showing a non-alarming AP, the number of clients shown in the same icon in the Overview page isn’t shown here.
Figure 15: Office Gateway AP detail
Meraki’s explanation for these delays and information mismatches is that their system is currently handling over 14,000 networks scattered around the globe with over 5.9 M clients. So the system has had to compromise on responsiveness to handle such scope.
Depending on the Monitor page viewed and the period of data it’s showing, information can be outdated as little as a few minutes for a day’s worth of data to as much as 24 hours for a month’s data.
My point back to Meraki is that their system design should not penalize individual customers, especially when customers are trying to fix problems with their networks.
Another hindrance to network troubleshooting is the LEDs on each AP. I though it was a cool idea to have signal level LEDs easily visible on each AP to help in siting APs for mesh operation. But it turned out that the level indicated is inconsistent at best.
I sited one mesh-connected AP in a location where it indicated a full four lights. But it turned out that the signal level in that spot was actually marginally low and caused intermittent disconnection of the AP. The correct signal level was shown in the AP’s dashboard page, however.
There is also no indication of network traffic from any of the LEDs, which I find an odd omission and, again, no help in seeing what a given AP is doing during installation and troubleshooting.
Performance
In my little home network, I can’t hope to come close to giving an Enterprise-grade multi-AP system enough of a workout to really stress it. So my performance tests mostly focused on the mesh aspect of Meraki’s system, even though Meraki says that most of their SMB customer networks of 50-5,000 users use Ethernet to connect their APs.
I first ran tests with the 802.11 B/G Indoor and Outdoor AP, sited at locations shown in Figure 16. Since both are single radio APs, a single mesh hop would cut throughput at least in half due to the single radio having to receive, then retransmit each packet. So I expected performance similar to what I would see from a WDS repeating setup.
Figure 16: AP test locations
And that was what I found. Figure 17 shows an IxChariot test with Meraki Indoor and Outdoor APs set up with the Indoor as the Gateway in the lower level Office location and the Outdoor mesh-connected located in the upper level hallway area.
One client was associated with the Indoor AP, sitting about 10 feet away from it, while another client was associated with the Outdoor AP, slightly further away on the other side of a wall.
The plot shows higher throughput averaging around 7.5 Mbps over the one minute test run from the Indoor AP associated client (non-mesh) and a significantly lower 1 Mbps speed from the client running through the Outdoor AP’s mesh connection.
Figure 17: Direct and Mesh performance – 802.11 G APs
Actually, the mesh-connected client managed around 2 Mbps at the start and end of the run. But it dropped to almost negligible throughput during most of the run, pushing down the measured average. I also ran an downlink test using just the mesh-connected client and measured around 3 Mbps for a one minute run.
But 11G technology is soooo yesterday. So I took Meraki’s suggestion and also ran mesh tests using a pair of dual-radio MR14’s. With one radio to talk to a client and the other to use for a "backhaul" mesh link, there should be no 50+% throughput penalty for retransmission. And since 802.11N is capable of providing bandwidths of 30 – 50 Mbps with a decent connection, I expected great things from a dual-radio 11N mesh.
Unfortunately, that’s not what I got. I took down the Indoor and Outdoor APs and set up two MR14’s in the same locations shown in Figure 16. The AP monitor for both APs showed signal levels of 25 – 27 dB and an estimated distance of around 10 m (33 feet) between the two—surprisingly accurate.
Note that since Meraki’s mesh set up is completely hands-off, I had no control over the bands or channels used. I could have controlled the band used by the Intel Wi-Fi Link 5300 dual-band N client in the test notebook. But I left it in dual-band mode and let it do its own thing when it associated.
I started out with the test client in the downstairs office, about 10 feet away from the Office Gateway MR14 that it associated with. The IxChariot test result in Figure 18 shows throughput not unlike I’ve seen with other 11N router / APs—around 87 Mbps down and 62 Mbps up.
Figure 18: Best case throughput – N client associated with N Gateway AP
Performance – more
During a telcon with Meraki, I learned of another tool that can be used to provide a client-eye’s view of what’s happening. If you hit http://my.meraki.com/ from a client associated with a Meraki AP, you can access a handy-dandy set of status information and test tools.
I took the screenshot in Figure 19 right after I ran the test shown in Figure 18 and it provides some interesting information. The Channel assignment of 44 means that the client connected using the 5 GHz band. And a 40 MHz channel width says that a full 300 Mbps maximum link rate is possible, which was confirmed by Windows wireless connection status. Finally, the Access Point Name of Office Gateway confirms that the client is, indeed, connected to the office gateway.
Figure 19: Client tool – Office Gateway AP connect
You can also run a downlink (only) throughput test, the results of which are shown in the speedometer readout (85.46 Mbps) and correlate well with IxChariot.
I then walked the test client notebook upstairs to a spot about 10 feet away from the mesh-connected AP, while refreshing the AP status display. I was surprised to see the client switch over to using the Upstairs Mesh AP as soon as I got to the top of the stairs! I then launched an IxChariot throughput test, whose results are shown in Figure 20.
I have to confess that I was very surprised by 4 and 5 Mbps results, which seem like not much better than obtained with the much less expensive 11G Indoor and Outdoor mesh-connected APs.
Figure 20: Best case throughput – N client associated with N Mesh AP
I was even more surprised when I ran the throughput test in the Client tool and got a 30 Mbps result (Figure 21). Looking closely, however, you can see my error. The test is from Access Point to Client, which doesn’t include the mesh link. While the IxChariot test is all the way from client through the mesh to my local LAN.
By the way, note that the client is still connected in N, but in the 2.4 GHz band with a 20 MHz channel bandwidth. This means that the 31 Mbps throughput is a bit low for what I normally see for such a best-case (strong signal) connection. (I also don’t know why this test tool thinks the Access Point name hasn’t been set, since the Dashboard seems to know it by the name I gave it.)
Figure 21: Client tool – Upstairs Mesh AP connect
It turns out that by switching to the mesh neighbors tab, I could run a throughput test through the mesh link. Figure 22 shows a result of 865.3 KB/s (6.9 Mbps), which correlates reasonably well with the downlink throughput shown in Figure 17—that is, when the link isn’t in one of the periodic throughput dropouts shown in both up and downlink runs.
Figure 22: Client tool – Upstairs Mesh AP connect – throughput test
Another thing that I think I can infer from Figures 21 and 22 is that the mesh link is running through the 5 GHz radio on Channel 44, since the client is associated with the 2.4 GHz radio on Channel 1. I’m not positive of this, however, since both radios are capable of simultaneously handling client traffic and participating in a mesh connections. Only Meraki’s algorithms know for sure!
If the mesh link really is running on the 5 GHz radio, then that could be one reason for the low mesh throughput because signals in the 5 GHz band are knocked down much more quickly than those in 2.4 GHz. So in Figure 22, the mesh link appears to have only a 9 dB connection on the 5 GHz radio instead of the 25 – 27 dB links shown in the Dashboard AP Neighbors sections—another example of oddities in the data provided in the Meraki dashboard.
As I noted at the start of this section, I didn’t run my usual six location throughput measurements on the Meraki AP. This gear is clearly not meant for residential use and is also intended to be deployed in multi-AP installations, preferably Ethernet connected. But this quick check has provided at least me with some valuable insight on the performance (or lack thereof) provided by current-generation dual-radio N mesh APs.
Closing Thoughts
I have to thank Meraki for being brave enough to put its equipment in the hands of a reviewer who is more accustomed to dealing with consumer wireless gear than multi-AP managed wireless systems. This puts me at a disadvantage in not having the experience of working with other managed WLAN systems under my belt. So I don’t really have anything else that I can compare Meraki’s system with.
That said, I think Meraki has a broad enough hardware selection, including outdoor and even solar-powered APS, to enable network designers to build what they need. (A single-radio N AP about half the price of their $600 MR11, would be nice, however.) But its Cloud based controller left me feeling like it (and Meraki) was in control of my system rather than me, which is both a good and bad thing.
The good is that the Cloud Controller is great for folks who don’t want to be bothered with the details and hassle of running a multi-node wireless network. Getting APs up and running really couldn’t be much easier, although figuring out where to place them for best coverage and performance will require the services of an experienced installer. These folks may never even log into the Dashboard, leaving that to a reseller who they’ll call when someone complains that their wireless-connected notebook can’t get onto the Internet.
The bad is that those resellers will probably need to be armed with tools other than those found in the Dashboard, especially if they’re trying to find interference sources or even accurate information on who is connected to what, right now.
Try as I might, I just kept finding too many instances of inaccurate or missing information to make me comfortable with my ability to easily and swiftly tell what was really happening on my little two-AP WLAN. If I had this much hassle with just two APs, I don’t know what I’d do trying to troubleshoot a larger WLAN with the toolset that Meraki currently provides.
Meraki’s roots may be in building community-focused wireless systems using open source software and cheap hardware. But that’s where they’ve been, not where they’re going. Their focus now seems to be on customers who can afford to drop around $5K on hardware, hundreds of dollars (at least) on yearly license fees and who are happy with 1 – 2 Mbps average client speeds.
Think web browsing, email and the occasional web video. Not Torrent downloading, lots of Hulu streaming or moving large files around, at least not with a lot of users. Yes, you can configure systems capable of higher total and per-user bandwidth. Just don’t count on doing it with only a few inexpensive B/G APs, or a lot of mesh nodes.
If you’re looking for a cheap mesh-based wireless system that can operate without a 24/7 Internet connection and provides real-time status and control of every node, then you’d best look elsewhere. But if your usage profile sounds like what I’ve described above and you’ve been thinking of getting rid of your cobbled-together network of DD-WRT-flashed routers and stepping up to an easy-to-set-up-and-use centrally-managed WLAN, you should probably give Meraki a look.