The latest update to Meraki Cloud Controllers and 802.11n access points adds application visibility and throttling capability, along with some limited spectrum visibility for non-WiFi interference.
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.
Released to customers at the end of
September, the update delivers a suite of new features designed to help
optimize and streamline network performance to Meraki's APs and Cloud
Controller. New application and content insight into wireless traffic
grants Meraki the ability to fine-tune network performance by shaping
traffic usage on specific networks, while Auto RF gives the network
some self-healing capabilities with the ability to compensate against
both WiFi and non-WiFi interferers.
For a look at the Meraki wares in action, click here.
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
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,
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
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.