Roaming helps ensure a seamless end user experience and application mobility within an environment. That being said, it can be extremely complicated and has many dependencies such as varying security requirements, underlying infrastructure, and coordination between clients and access points. This article takes a look at some of the challenges of roaming, and methods used to improve user experience and overall network performance.
But first, why roam?
When a client detects better wireless service at a different access point it will roam from one access point to another. But often, those roams don’t go as smoothly as planned. Clients might have to disconnect, reconnect, and even reauthenticate, proving their identity once again. Going through re-authentication can be slow enough to interrupt latency sensitive applications. In an ideal world, once a client connects to an SSID, they would be able to move around freely, and every access point would already have them on the VIP list. Cisco Meraki implements some features to make this a reality, but first, some background on the evolution of roaming.
What makes roaming slow?
The latency experienced when roaming is dependent on the type of authentication being used. For simple authentication methods (open, WEP, or even WPA2-PSK) roaming is pretty quick, around 50ms. Minimal to zero authentication exchanges are required for a roam to take place. But for enterprise networks, it’s common to use 802.1X and RADIUS in order to meet security requirements. In these environments, clients have to re-authenticate every time they move to a new access point. This means authentication exchange packets have to travel all the way to the authentication server, even if it is across a WAN connection. This type of roam can take 600ms or more depending on the underlying infrastructure.
Why is fast roaming important?
For many networks, low latency roaming isn’t important but there are certain applications that cannot sustain 600ms of latency, such as those for manufacturing, medical devices, warehouses, and most notably VoIP. For an uninterrupted voice call, generally roams need to be in the ballpark of 100ms, give or take 50ms. We will use this as a benchmark as we aim to reduce roaming latency even in environments that require 802.1x authentication.
How can I reduce roaming latency?
Building on existing fast roaming capabilities, Cisco Meraki APs now include new standards support to speed up roaming even in a WPA2-Enterprise environment.
802.11k speeds up roaming by helping clients more quickly determine which AP they should connect to. Usually the client will spend some time scanning various channels and then choose the best candidate. The Cisco Meraki AP will provide the client with valuable data about nearby APs and their channel. Clients then know exactly which channels to scan, and which to skip, before roaming.
As discussed earlier, one of the things that slows down roaming most is re-authenticating at each new AP and sending exchange packets all the way back to the authentication server. 802.11r implements something called fast transition (FT), allowing encryption keys to be stored at all APs in the SSID. Instead of re-authenticating, the new AP already knows about the roaming client and can resume sending secure encrypted traffic right away.
(Left) The client re-authenticates at each AP as it roams. (Right) After initial authentication, the client can easily roam to other APs in the SSID.
Layer 3 roaming
Finally, the Cisco Meraki access points have added support for layer 3 roaming. Layer 3 roaming is required when a client moves from an AP on one VLAN to an AP on an entirely different VLAN, and subnet. Without layer 3 roaming, the client would need to request a new IP address via DHCP. In traditional wireless solutions, an IP change would cause all open sessions to be dropped, forcing the client to initiate new sessions to the newly obtained IP address. Cisco Meraki has implemented a method to create a seamless roam even when changing to an AP on a different VLAN. The wireless network can create a connection from current AP back to the starting AP, allowing for communication to continue with the client’s original IP address. This can be easily configured in the SSID Access Control settings in the dashboard. Just navigate down to Addressing and Traffic and select “Layer 3 roaming.”
Cisco Meraki provides support for layer 2 and layer 3 roaming. Layer 2 provides for speedy seamless handoffs for most scenarios. Layer 3 is often only needed for applications like VoIP over WiFi which are required over an extended area.
Using a combination of faster client association from 802.11r, and 802.11k’s assistance in identifying where to roam, Cisco Meraki APs greatly enhance the wireless experience for end users. Additionally, the ability to support layer 2 and layer 3 roaming opens up doors for network administrators when designing the network architecture. Layer 3 roaming is available in beta today on all Cisco Meraki access points. For more information on Cisco Meraki products and roaming functionality check out the knowledge base.
Meet Elise, the Technical Training Program Manager here at Cisco Meraki. Elise runs all of the activities related to our technical training program, a one-day lab which gives Meraki and Cisco Partner Systems Engineers the chance to learn about Meraki products and earn the title of Certified Meraki Networking Associate (CMNA).
A native of Minnesota, Elise came out to California to attend Stanford University. She earned her degree in American Studies, and lent her talents to the Stanford band on the side (via the trumpet). After graduation, she went on to work in performing arts management with a local string quartet for almost two years. Searching for a new opportunity, she heard about Meraki, interviewed, and was soon hired as a recruiting coordinator for the Support team.
Since then, her role has changed quite a bit. For the past year, she has been managing all of the activities related to CMNA training, including scheduling lab sessions, overseeing partner registration, and planning strategically for the future of this expanding program. Meraki and Cisco reseller partners who have already fulfilled their Cisco Certified Network Associate requirements are welcome to enroll in this training. These individuals spend a day learning about Meraki products in a hands-on, lab-based environment. “We try to take the Cisco Meraki experience and transplant that into a training form,” explained Elise.
Each training program graduate receives a lab stack consisting of an MX60 security appliance, MS220-8P switch, and MR26 wireless access point. There is at least one Cisco Meraki sales engineer and one expert trainer on site to help answer questions, provide product overviews, and lead demonstrations during the lab. “Our trainers are all people who work here at Meraki, and include support team members, product marketing managers, and product specialists,” said Elise.
The trainers dive into each Cisco Meraki product line, and give partner engineers the chance to set up a network from scratch. Attendees are able to explore the cloud-based platform and innovative features for themselves alongside the guided demonstration, making for a very interactive session. The CMNA training program is regarded as a unique and rewarding learning experience because of this focus on hands-on learning.
The Cisco Meraki technical training program is expanding quickly internationally, with sessions in North America, Europe, Australia, and Asia. Elise looks forward to continuing the development of the program, as it consistently generates a huge volume of interest, with hundreds of registrants for each session. She has had the chance to work with many different partners, who have consistently given positive feedback about the training as well as the products. “They always have really good things to say about our trainers,” said Elise.
As many past spotlighted employees have also noted, Elise’s favorite aspects of working at Meraki are the culture and the people. “Everybody is really excited about what they’re doing,” she said. “You can feel that when you’re going to work.” She values the impact of each individual’s work at Meraki, and is excited to see how her future at the company unfolds. “Meraki gives people like me, an American Studies major who likes reading books, the opportunity to work with a tech company, and with such a cool product that’s making a big impact on the market.”
Mobile devices used in enterprise or education settings are a big investment and are likely to have important information or resources stored on them. But the problem inherent in mobile devices is that they are mobile. With enterprises, schools, and even government facilities issuing mobile devices or permitting BYOD, admins using Systems Manager now have the ability to know when devices leave an area and what information is taken.
Using the Configure > Geofencingfeature in Systems Manager, admins can establish physical boundaries that will send alerts when a device leaves or enters the defined area. This is invaluable for knowing when devices leave the premises and permitting admins to take action as needed.
Simply create a new geofence rule and, using tags, select the devices to which the rule is applied. The area can be defined using specific addresses and radiuses or can be placed on the map. Admins can also permit a grace period for users to bring their devices back into the geofence area before receiving an alert.
Whether the devices are company/school-owned or employee/student-owned, the geofence management feature in Systems Manager enables admins to specify acceptable boundaries within which devices can access certain information. Different profiles can be applied to the devices depending on whether they are within the geofence or not. For example, a device within the geofence might have a profile allowing access to all organization content, while a device outside the geofence may only have access to certain, non-confidential data.
Navigate to MDM > Profiles and select an existing profile or create a new profile. Under Scope, type “geofencing” and two options will appear: “Geofencing – compliant devices” and “Geofencing – violating devices”. Select the type of geofencing tag this profile will follow and save changes. Now, any device that is compliant or violating the geofence, depending on the selection, will have the profile applied. Meaning, that when a device with a “Geofencing – compliant devices” profile is no longer compliant, Systems Manager will automatically remove the profile, along with the settings and content associated with the profile.
Depending on how each organization establishes their tags and defines their profile groups and accessibility options, the applications of using geofence management are limitless.
Online threats abound, and securing a single network—let alone multiple networks—is a full-time job. The disclosure of the dangerous (and widespread) Heartbleed vulnerability has propelled public awareness of exploitable threats. However, the challenge of providing a rapid security response across remote sites still looms large.
In this post we’ll explain how intrusion prevention (IPS) works on Cisco Meraki MX security appliances, and how we were able to protect our customers against Heartbleed within 24 hours of its revelation — faster than our competition.
How the MX protects your network
Even before Cisco acquired Sourcefire, the industry leader in intrusion prevention, Meraki MX security appliances integrated with Sourcefire IPS to deliver unparalleled threat detection. Post-acquisition, a close engineering partnership between the Sourcefire and Meraki teams has improved backend performance and integration, providing the MX with the most secure, intuitive, and easily-deployed IPS solution available to organizations managing branch locations.
Preventing malicious activity with the MX is literally a two-click process. First, though, it’s important to understand how Sourcefire IPS gets implemented.
The Meraki MX performs intrusion prevention via rulesets: pre-defined security policies that determine the level of threat protection needed. There are three rulesets: Connectivity, Balanced, and Security, and Sourcefire has defined threat metrics and criteria for each. For details, check Sourcefire’s blog post, but to summarize:
Connectivity ruleset: protects against the highest-priority threats discovered in the current year as well as the prior 2 years.
Balanced ruleset: protects against vulnerabilities identified in the Connectivity ruleset, as well as slightly less critical threats. Additionally, certain categories of threat (e.g. exploit kits and SQL injections) will be caught regardless of age.
Security ruleset: protects against vulnerabilities identified in the Connectivity and Balanced rulesets as well as lower-priority threats, but expands the age limit to vulnerabilities discovered within the last 4 years. Additionally, an expanded list of threat categories will be caught, regardless of age.
Sourcefire refreshes rulesets automatically (adding newly discovered vulnerabilities where appropriate and purging older vulnerabilities that are past age limits), so MX customers don’t need to exert any effort in order to benefit from a well-tended, constantly pruned baseline level of security.
Configure IPS in less than 15 seconds
To ensure that a particular Sourcefire ruleset—Connectivity, Balanced, or Security—is enforced, simply enable IPS in the Configure > Security filtering dashboard page and then select the desired ruleset (you can whitelist signatures to fine-tune threat detection for your environment).
Enabling MX intrusion prevention running the Sourcefire “Connectivity” ruleset in the Meraki dashboard.
That’s it! The Sourcefire rulesets are deployed by the MX, ensuring malicious traffic is contained. Even better, these rulesets are updated daily and pushed within an hour to MX customers from the cloud—no manual staging or patching needed. So, with only a few seconds of effort, IT admins can enjoy up-to-date, best-in-class intrusion prevention while averting the “pilot error” that often plagues complex, manual configuration and patching of IPS.
Cloud managed is better
What about deploying and managing IPS across hundreds or thousands of remote sites? No problem. Configuration templates allow IT admins to make changes once to an MX serving as a master template for numerous networks bound to it. Any change on the master will propagate to bound MX networks. This means you can enable IPS on your master MX, select your Sourcefire ruleset policy, and sit back as IPS is enforced across your branch locations.
What about keeping everything — IPS rulesets and MX firmware — current for security purposes? Again, no problem. Since IPS rulesets are updated daily by Sourcefire and pushed within an hour to your MX, you can rest assured your IPS detects the latest threats. Since the MX receives its own firmware, bug, and feature updates seamlessly from the Meraki cloud, it is also up-to-date (or easily made so by scheduling updates from the Meraki dashboard).
In short: built-in intrusion prevention goes a long way towards locking down your network, simplifying security management, and saving you time. It’s only one of several security features the Meraki MX offers, but it’s one of the most important. If you want to hear about other MX features, check here, here, and here.
Wishes for the Meraki dashboard mobile app have been quite healthy of late, and there has been a significant uptick in users over the past few months. The engineering team has been hard at work enhancing the app and has added some new, exciting features.
Visibility into clients is key to understanding how the network is used and to identifying users consuming extraordinarily high amounts of bandwidth. The mobile app now shows connected and offline clients, with the ability to sort by usage, time last seen online, and other parameters. The famously-fast Meraki search is also in the app, enabling quick troubleshooting. Find devices by name, OS, or even IP subnet, and click to get details such as MAC, IP, SSID, RSSI, and more.
Get to the bottom of things quickly
New network troubleshooting tools help admins test infrastructure connectivity from the app. The ping tool triggers pings sent from the Meraki cloud to a switch, AP, or MX Security Appliance – average latency and ping loss percentage are updated live.
Help on the go
The Meraki mobile app is optimized for network management on-the-go. Sometimes it’s handy to check the status of an open support case or read notes on its resolution. Support cases are now viewable in the app (see the “More” tab) and categorized by status for convenience, making it quick and easy to get the latest support update for a network.
A few customers have wished for the ability to pin-lock the app, making access secure and convenient. Pin locking is offered in addition to two-factor authentication and is enabled by going to the “More” menu and selecting a four digit pin.
Get started by downloading the app onto your device:
From electric-powered longboards to 3D heart imaging, all of the startups we heard from are working on fascinating projects. We were very impressed by the caliber of the companies that applied for Startup Kits and also noticed a few interesting trends for this round:
Increase in cloud-based or cloud-related companies
Startups with a goal to aggregate or consolidate existing resources
Hardware startups building familiar items with a software twist
Healthcare-related startups seeking to revolutionize an existing process in the healthcare system
The Cisco Meraki team is excited to give out the Startup Kits over the next few weeks and hear about how companies put the them to use as they build and scale.
To hear more about our lucky winners, check back in a few weeks for our series of Startup Kit Spotlights – our semi-regular features on Startup Kit recipients and how they use their Meraki network to build up their company.
Over the past year, the Meraki team has worked with other Cisco teams to increase the business relevance of WiFi via Cisco CMX (Connected Mobile Experiences) and Cisco Meraki Presence. After extensive collaboration between product development, sales, and partner teams, Cisco is in an ideal position to offer one value proposition to the market, with two implementations for customers who prefer a cloud-managed or on-premise solution. To better address the market with a single voice, moving forward the Meraki Presence solution will be marketed under the CMX branding.
Today, both Cisco cloud-managed and Cisco on-premise solutions are market leaders for their respective target customers who are looking to WiFi as a platform to detect, connect, and engage with end-users. While both solutions offer exceptional capabilities in this area, they have different feature sets, and will continue to do so. Nothing is changing with respect to product strategy – Cisco will continue investing in both on-premise (optimized for flexibility and control) and cloud-managed (optimized for ease of use) CMX offerings. On-premise solution customers will continue to deploy CMX as a license for the Mobility Services Engine, while Meraki customers will continue to find CMX included by default as part of the Meraki cloud management platform.
To learn more about CMX with Cisco Meraki, see our:
The Cisco Meraki team is aware of a critical vulnerability in OpenSSL, CVE-2014-0160 (also known as the Heartbleed vulnerability). OpenSSL is a security library that is widely used across the Internet.
We determined that Meraki servers, infrastructure, and network devices (i.e., access points, switches, and security appliances) are not affected by this vulnerability.
The Systems Manager dashboard as well as iOS, Android, and Mac devices enrolled in Systems Manager are not affected. Some Windows PCs enrolled in Systems Manager are affected by the vulnerability in the initial startup phase of the Systems Manager agent. During this phase, no sensitive information is available for an attacker to collect, and no private keys are exposed. This vulnerability does not allow an attacker to gain access to a PC managed by Systems Manager and it does not allow an attacker to gain any knowledge of the Systems Manager configuration. Regardless, a new build of the Systems Manager agent for Windows PCs is available for download via the dashboard. It is not affected by the vulnerability and customers are encouraged to download the new agent at their convenience.
Back in the MDM Ice Ages, when admins pushed out a new app to a device, users would have to enter an Apple ID and password right then and there in order to download the app. This caused a number of problems, as some admins didn’t want users to get a hold of the Apple ID and password and set off on a downloading spree. Apple recently added a feature that allows admins to push out new apps to mobile devices without requiring the user to enter an Apple ID and password. Furthermore, Systems Manager has implemented this into the dashboard so you can take advantage of it right away. This blog post will take a look at how to silently push an app from start to finish.
1. Mobile device requirements
First, there are a few device dependencies in order to silently push apps. The device must be supervised by Apple Configurator and the device must be associated with an Apple ID (this means someone has to log into their Apple account on the device at some point, but it is not required at the time the app is pushed). And if you haven’t heard, you can now supervise your devices over-the-air using Apple’s Device Enrollment Program (learn how to configure DEP with Systems Manager here).
2. Purchase Licenses from Apple VPP program
Next, the app needs to be purchased from the Apple VPP program. This goes for free or paid apps. Below we have 1000 licenses of a free calculator app.
3. Dashboard automatically syncs to Apple VPP program
Purchased VPP apps are populated in the dashboard, available to be assigned.
4. Assign apps to mobile devices
Below we will click on the Calculator app and assign one of our licenses to a user. For a refresher on VPP managed distribution and setting up users, take a look at this article.
5. Add to Systems Manager App Management
Now we are ready to silently push out the app just as we would any other. Navigate to MDM > App. Select ‘+ Add new’ and find the app you’d like to push to your devices. Here, we searched for ‘calculator’ and clicked ‘Add’.
6. Silently push app to devices
Select the app to be pushed and define the scope. Below, we chose to push the app to all devices with the tag “vpp_managed.” Once we save, the app will be pushed.
7. App is silently pushed with no Apple ID and password prompt
On the iPad, we were prompted for the app installation but were not asked to enter a password.
This feature helps admins keep a tighter grip on those precious Apple IDs and passwords. It can also save a great deal of time when apps need to be pushed to many devices at once. Apple has made a number of new feature announcements and this is just another one that we have been able to quickly implement in Systems Manager. For more information on some of these new features check out our in depth look at Apple’s Device Enrollment Program as well as updates on content filtering and more from Systems Manager.
Back in the Autumn we introduced our new Combined Network dashboard view, which grouped together management of Access Points, Security Appliances and Switches under a single menu. This new, more efficient design has been welcomed by Meraki customers with wired and wireless networks sharing common user bases, enabling the engineer to work on more than one product type at a time, potentially across multiple sites.
In order to take advantage of grouping products together in this way, it makes sense to also combine the configuration of features common across more than one product type. To address this, our design team migrated common settings to a unified menu label named ‘Network Wide’, which looks like this:
Before we take a look at the new combined policy configuration screen, it’s worth refreshing the distinction between network-side settings and client-side policies. When the intent is to affect user behavior for all users of a network segment, network-side settings are the way to go. These will apply to all wired clients connected through a Security Appliance, or to a specific wireless network (SSID).
For example, it may be desirable to apply traffic shaping rules for video and music streaming services to all clients, network-wide, who connect to a guest SSID.
Policies, on the other hand, are designed to apply client-side to selective groups of users, typically identified either through a user authentication process, or through their devices, by fingerprinting device communications. The emphasis shifts to controlling the user experience for both wired and wireless connections for these select users or devices.
A client-side policy might choose to put all wireless financial data onto a specific VLAN with access to secure servers during normal office hours, and block Social Networking for both wired and wireless at the same time. This can now all be configured using the new combined Group Policies page, which looks like this:
The dashboard is continually evolving and improving, based in–part on the feedback we receive through the Make-a-Wish box on every dashboard page. This is just one example of a small change which helps make managing group policies on a modern unified access layer network more intuitive. There’s always room for improvement, so stay tuned as we announce further tweaks and enhancements.