The latest update to the Meraki Cloud Controller and Meraki’s 802.11n access points delivers a hit-and-miss collection of enterprise-class features designed to provide customers with improved visibility into and control over WiFi usage, along with automated reactions to non-WiFi sources of interference.
I tested the Meraki Cloud Controller in conjunction with a pair of Meraki MR14 access points, replacing our corporate WiFi deployment with the Meraki products for just under a month, servicing dozens of users and devices on two different WiFi networks over that time. Each MR-14 costs $799 and offers a pair of dual-band 802.11n radios (2 stream, 2 by 2 MIMO) and a single 802.3af Power-over-Ethernet-compliant gigabit Ethernet port. Licensing for the Cloud Controller costs an additional $150 for one year and includes product support, maintenance, and upgrades, or purchasers may opt for the three-year license for $300 each.
New application visibility provides detailed information about
network usage, identifying not only network ports and protocols used but specific application information as well, in order to help break out how Web traffic is being consumed. Meraki utilizes its global network to help fingerprint Web applications, helping them suss out identifying application characteristics and behaviors and organizing applications into categories. Meraki claims application fingerprints are updated to Cloud Controllers all the time, so the network should be able to respond quickly if an application changes its behavior.
Administrators can view application usage information on global or a personal scale. I found I could look at traffic from the last two hours, or the last day, week or month and access pie charts displaying the traffic mix over that time, highlighting sites or applications used most. For example, in my network, I found that over a month, 63.2 percent of the aggregate WiFI traffic consisted of encrypted SSL traffic to Microsoft.com. Skype, generic Web traffic to non-fingerprinted sites, Exchange traffic to our hosted e-mail provider and Windows File sharing traffic rounded out the top five applications over that time.
Usage totals for the individual WiFi clients are broken out below the pie charts. Meraki leverages the user name (if using user-based network authentication) or the device host name to identify the device, rather than the MAC address, making it easier to attribute a device to a user. Drilling down into an individual client displays more application information, breaking out network port usage, application usage and HTTP content mixes into separate pie charts. I also found I could create my own customized pie charts for the applications, sites or network services I specifically want to track.
Beyond the fun Orwellian aspect of knowing pretty much everything that my wireless users have been up to for the last month, Meraki utilizes this information for something constructive as well, delivering traffic-shaping capability beyond simple port-based QoS. Specifically, with Traffic Shaper, administrators can create rules to limit a user’s
bandwidth usage for a specific type of traffic or, if not yet fingerprinted, for a specific Website. These throughput limits can be aggregated, or set separately for both uplink and downlink traffic. Meraki offers several different categories of traffic that can be shaped: music/video, e-mail, VOIP/Video conferencing or peer-to-peer networking, among others.
As an example, I was able to limit video services to each client attached to one of my wireless networks (I set up Meraki to service two networks) to just 100 kilobits per second. This caused the Netflix application running on an iPhone associated to that network to provide a much choppier experience with lots of pauses for buffering, while a network speed test performed using the same device was not subject to the same throughput limitations.
Following the path well blazed over the last six months by Cisco, Aruba and Meru, with this update Meraki added spectrum analysis functionality to their APs and Cloud Controller with the new Auto RF feature. Auto RF allows the Meraki network to hear non-WiFi sources of interference cluttering up the RF around the network and adjust network settings to compensate automatically. However, I was underwhelmed with the feature compared to similar capabilities of those other products, finding Meraki’s implementation less helpful and less configurable.
To force a manual interference scan, I had to switch the AP's mode, causing the AP to reject client connections to both radios (on the other hand, both Cisco and Aruba allow client connections during RF scanning). This requirement is especially unfortunate because the Cloud Controller only shows RF data for the 2.4 GHz band, meaning one radio is taken offline for no apparent reason.
The RF data presented from a manual scan to the administrator is fairly underwhelming. The Cloud Controller shows an instantaneous sample of the detected interference signal strength and affected part of the spectrum, as well as a cumulative distribution that shows those detections over time. But the scans only display noise levels, so while the feature may quantify interference generated by a microwave oven or wireless camera, Meraki won’t explicitly identify the possible source of the interference. The administrator has to figure out what is causing the noise, then go try to find it. Not that Meraki presents any information to help correlate those findings across APs.
Auto RF, on the other hand, listens for non-WiFi noise as part of the AP's normal course of operation, listening by default on channels being serviced by the AP, and to the other channels as part of either scheduled or opportunistic sweeps of the spectrum. APs package up both WiFi and non-WiFi interferer data and send it all to the Cloud Controller, where current and historical data is analyzed against algorithms derived from thousands of other Meraki networks around the world.
Using that data, Auto RF can change an AP's channel assignment via the Cloud Controller when needed to work around interference, or it can adjust the radio transmit power levels. The network also now bumps capable clients from 5 GHz over the 2.4 GHz band to avoid the more congested airspace altogether. With a stark lack of a front end for Auto RF, however, it doesn’t appear there is a way at this time for an administrator to customize threshold levels for radio change events.
Also, manual interference scans tended to fail after limited use during my tests. One of my APs could conduct an interference scan for 5 to 10 minutes, while the other would fail in under a minute. The AP logs failed to identify a cause of this problem, but I’d hazard a guess it has to do with a lack of available memory on the AP.
Posts
