Mobile devices aren’t just about the latest gadgets — they’ve become a primary tool for IT administrators, who are depending on extending their tools to those devices more and more every day. To address this need, we are thrilled to introduce the Cisco Meraki dashboard mobile app. It extends cloud management of Meraki wireless networks to mobile devices, and it’s available for immediate download from the Apple App Store.
We’ve extended the Meraki dashboard experience and optimized it for mobile devices, giving it a familiar look and feel. While the dashboard website can be used on smartphones and tablets, the mobile app provides a better and faster experience, especially on small devices, making it ideal for network management on the go.
Cloud management in the palm of your hand
Network management using the dashboard app is just as simple as it is on the web. View the status of wireless networks at a glance, quickly identifying healthy or offline access points. See the details of any Meraki access point on the network and verify network connectivity, usage, and settings. Multi-site management is built-in, too.
Faster WiFi deployments
To add a new access point, use the app to scan its barcode and add it to the network. The access point will automatically connect to the cloud, provision itself, and become part of the network, appearing in the list of APs. The app takes advantage of a few mobile-specific features: the camera and GPS. When installing the AP, use the phone’s camera to take a photo of the mounting location — this makes it easy to visually identify an AP when walking through a deployment. There’s no need to hunt around for the AP, since its location can be tagged using built-in GPS.
Network summaries at a glance
The most important data about your network is neatly presented in the summary page. Daily, weekly, and monthly usage graphs show traffic patterns on your network. Top client charts reveal bandwidth-hungry devices and the mix of iOS, Android, and desktop platforms in your environment. To monitor multiple Meraki networks, just select them from the app’s menu.
There’s more coming
This is the first release of the app, designed for the iPhone and iPod Touch. We’ll continue to add more features in the future, such as monitoring MS Switches and MX Security Appliances. Android fans, don’t worry: we’re working on an Android version, too. Want to see something new? Just shake the phone to make a wish right from the app.
It’s that time of year again. School has begun, and we thought it would be a great chance to review some of the wireless fundamentals by creating a secure guest SSID. But first, what are our goals when creating guest wireless on our networks? We want to segment guest traffic from secure traffic, segment guests from each other, and as a bonus, protect the rest of your network from guests getting carried away on YouTube. With the Cisco Meraki solution, we can accomplish each of these requirements with just a few steps:
1. Create a Guest SSID
First go to Wireless > SSIDs to create a new SSID. I’ve named mine, Meraki-Guest. Then toggle to enabled, and click save.
Navigate to Wireless > Access control. Ensure the “Meraki-Guest” SSID is selected from the drop down menu. Under Association requirements, select ‘Open’. Remember, we have users with no credentials connecting. If you prefer to give out a passcode to users, you can select “Pre-shared key with WPA2” here also.
Next, we will select a splash page. I have chosen a click through splash page using a splash page provided by the dashboard (Wireless > Splash page to customize), but there are several other options: Sign on with SMS Authentication, or Sign on with Facebook WiFi are also popular choices.
2. Use NAT mode for assigning client IP addresses
Still on the Wireless >Access control page, we can select our Client IP assignment method. For guest access, we recommend using “NAT mode.” In this mode, the AP acts as the DHCP server and passes out an IP address from the 10.0.0.0/8 range. An added benefit of this method is that by default, the guests cannot see each other. However, guests can still potentially see traffic or internal resources upstream. Let’s take care of that next.
3. Block local LAN traffic
Navigate to Wireless > Firewall & traffic shaping. Under “Layer 3 firewall rules” select “deny” for Local LAN traffic. This will ensure that any traffic destined for a Class A, B, or C private IP address is dropped right here at the AP. With this selected, the guest traffic is completely isolated from the LAN and guest can only access internet resources.
BONUS. Apply layer 7 firewall and traffic shaping rules
But here, we can limit which internet resources guests are allowed to access, and at what speed. We can use Layer 7 firewall rules to completely block a certain type of traffic: here we have blocked all Peer-to-peer traffic such as BitTorrent and Kazzaa.
If we don’t want to completely block an application, we can use traffic shaping rules to limit but not block certain types of traffic. Here, we have limited all Video and Music traffic, prioritized VoIP traffic, an set an overall bandwidth limit of 1Mbps per client.
Choose between a variety of categories of predefined applications. A benefit of the cloud is that the application list is constantly being updated, and if you can’t find what you’re looking for, simply create your own custom traffic shaping rule by specifying a hostname, port, IP address, or subnet.
And that’s it. Stay tuned for more configuration examples and as usual, keep us updated with what you’d like to see using the “make a wish” box at the bottom on every page in dashboard.
Experience matters. Our faith in this idea informs decisions around product design, usability, and support. It’s why we invest so much time and energy in our Certified Meraki Networking Associate (CMNA) training for reseller partners: we believe in learning through experience. But not everyone can commit to an intensive, full-day training course; and not everyone is satisfied with a webinar demo or trade show pitch. So we’re launching a new, hands-on workshop at two upcoming Cisco Networkers’ Events (in Pittsburgh, PA on September 24th, and in Princeton, NJ, on October 1st) that will distill the most salient, killer features of each product line into an accessible exercise for all.
For two hours, attendees will learn about all four Meraki product lines, have access to a unique stack of network gear hosted at our San Francisco office (simulating remote site management), and will work through common, real-life scenarios under the guidance of a Cisco Meraki Systems Engineer. It’s a chance for everyone to experience the Meraki dashboard and to explore the unique features — like Auto-VPN, virtual stacking, and cloud-based application fingerprinting — of our cloud architecture.
Our new Cisco Meraki workshop lab at our San Francisco office.
We’ll be gauging customer interest in these workshops, and expanding them if necessary, so stay tuned for more updates! If you’re particularly keen to get involved you can view our lab from our webcam and let us know what you think.
Customers use Systems Manager to deploy applications from iTunes to managed mobile devices all over the world. Beyond live iOS applications, many Cisco Meraki customers have created their own custom enterprise applications through the iOS developer program for use within their organization. As the requirements of organizations are adapting and growing, Systems Manager is developing features to address new business needs of those organizations. Systems Manager can now be used to push out enterprise applications in addition to applications generally available in iTunes. These applications can be deployed at the creator’s discretion instead of being made available on iTunes. Here’s how:
Just as you would deploy any application in Systems Manager, navigate to Mobile > Apps > Add new, but now select “iOS enterprise app.”
Next we will choose the application location. Here you can either upload the .ipa file directly to Systems Manager(Upload an IPA) or enter the URL of where you are hosting the application externally (Specify a manifest URL). The first option uses Systems Manager to locally host your custom iOS application and Systems Manager will push out the application to selected devices directly. The second option will direct users to where the application is hosted elsewhere. The manifest in the URL distinguishes your enterprise application from a website.
Once complete, choose the devices you would like to deploy the application to, security settings, and you’re off and running. If you’re new to deploying applications from Systems Manager, we have step by step guides for deploying iOS apps and enterprise apps in our knowledge base.
Many Meraki customers are taking advantage of this feature to meet their business needs. Check out how Uber is using Systems Manager to not only push out their critical enterprise apps but also manage the thousands of mobile devices in private cars around the country. To get started using Systems Manager, check out these how to videos to manage your mobile devices right from the Cisco Meraki cloud platform.
Greg, Cisco Meraki Software Engineer, hard at work.
Today, we’re excited to introduce one of our engineers in what will be a series of blog posts on various teams within Cisco Meraki. We’re proud of our people and the amazing work they produce; we want you to meet a few of the faces behind features you know and love.
Greg is a native of the Bay Area, and a recent UC Berkeley graduate who triple majored in Computer Science, Linguistics, and Japanese. Today, he’s a Cisco Meraki software engineer, working on our cloud-managed MS switches.
How did Greg hear about us? “Well,” he says, “I was fresh out of college — I graduated in December of last year (2012) — and was still hanging around the Berkeley Computer Science department, and heard about a hackathon sponsored by Meraki. I decided to participate.”
“When I looked at Meraki, I thought the fundamental product was something cool to work on,” Greg explains, “and I could understand the business case for it. I could imagine myself buying Meraki products.”
Greg’s most recent Meraki project was to write new features for MS switches’ local configuration pages, found by typing switch.meraki.com into any web browser when directly downstream from — or connected to — an MS switch. Specifically, Greg coded per-port configuration options into the switch local status interface:
These options in the MS switch’s local interface are a result of Greg’s work.
Says Greg of the project: “When designing this local status page, we had customers to consider. If you were interacting with this page instead of the Cisco Meraki dashboard, it probably meant there was a misconfiguration or a problem with WAN connectivity. So we wanted to ensure it was easy for customers to navigate this page — there shouldn’t be anything unexpected, or surprises in how the interface works, that would cause frustration. It should let you make immediate choices about port configuration to get you back online as quickly as possible.”
What does Greg think of life at Cisco Meraki? “I love the code I’m writing, I love the people. I just really enjoy my time here.”
What’s he doing now? “Working on some exciting and upcoming enhancements for our switches.”
What does Greg do when he’s not coding for us? “I go bouldering at the nearby Dogpatch gym. And we just got a cat at my apartment — his name is Artemis and he’s only 12 weeks old. Super cute.”
If you want to join Greg and the rest of the Cisco Meraki team, check out our jobs page — we’re hiring!
One of the challenges with any wireless network, especially in enterprise and multi-tenant environments where there are often many APs, is minimizing the performance-sapping effect of interference. With more and more of us choosing WiFi as our primary source of network access, maintaining a clean RF environment becomes a top priority for the network engineer.
The MR34 features an additional radio inside the AP dedicated to ensuring high performance isn’t compromised by rogue APs or interference. We recently covered the third radio’s Air Marhsal WIDS/WIPS features; here we take a closer look at Auto RF.
The MR34’s third radio
The MR34 combines the third radio and the power of cloud management, leveraging sophisticated algorithms to perform spectral scanning and automatically re-balance channel assignments without impacting clients. A channel analysis takes place every couple of minutes and a channel reassignment window every 10 minutes, enabling APs to change channels if no clients are connected. Like other Meraki APs, the MR34 also scans on boot to ensure it doesn’t interfere with existing APs, and can recover in the event of a saturated channel by forcing a channel reassignment. Also like other Meraki APs, the network administrator can also manually initiate an update to optimize channel assignments.
An overview of the RF environment
We’ve introduced an intuitive way to visualize interference with a detailed spectrum analysis view in the dashboard. The third radio enables display of real-time data with no impact to client performance, showing live and recent activity to help identify sources of interference. The screenshot below shows a list of MR34 APs with a simple historical interference bar for both 2.4 GHz and 5 GHz radios which builds over time. The lighter the colors, the greater the utilization of the channel.
View summarized spectrum analysis information of multiple APs at once
To look at the wireless conditions for a specific AP in more detail, simply click it. The example below shows a high utilization in the 2.4 GHz band.
On this screen you can see both real-time and recent historical utilization across the 2.4 GHz band. It’s probable that two-thirds of the users in this environment are having quite a laggy experience. To address this, we’ll want to check we’re using band steering to encourage more clients onto the less noisy 5 GHz band.
Designing high performance WiFi networks is becoming easier with the advent of new, faster standards like 802.11ac. At the same time, this performance is being shared among an ever-growing number of devices. The tradeoff will be with us for some time to come, so the tools Cisco Meraki is providing assist with delivering the best possible client experience, with detailed yet intuitive information for the network administrator.
Cisco Meraki access points, switches, and security appliances are designed to be 100% cloud managed, delivering deep end-to-end visibility and control over networks from any Internet-accessible location. Sometimes, perhaps through misconfiguration or an unrelated Internet outage, it may be necessary to tweak settings locally. At other times, having directly accessible tools and statistics would be beneficial.
Enter Meraki’s local configuration pages. Each AP, switch, and security appliance has one; these local configuration pages are accessible when directly downstream from, or connected to, a Meraki device — no Internet connection required. Local configuration pages are accessible via special URLs which are accessible from any browser:
wired.meraki.com for security appliances
switch.meraki.com for switches
my.meraki.com for access points
These local configuration pages can save you time as you troubleshoot network problems.
1. Quickly identify the scope of connectivity issues
View real time health status of any Meraki device by going to any one of the above URLs. You will see instantly whether the device is registered with the Cisco Meraki cloud, whether your laptop or computer can access the device, and whether the device has connectivity to the Internet, failover links, and more. This is especially useful when it may not be readily apparent whether a loss of connectivity is due to the connection between a client device and Meraki equipment, or to the connection between Meraki equipment and the WAN. If you get a support call from an end user who cannot connect to the Internet, you can direct them to wired.meraki.com and have them identify if any status boxes are red or yellow, indicating an issue.
Here, the connection between my laptop and the MX security appliance is healthy, but the MX’s connection to the Internet is down. Immediately, I know to focus my investigation on WAN link connectivity.
2. Easily pinpoint switch ports
Locating where an Ethernet wall jack terminates — which switch port it connects to — can be grueling. Often, this involves either tracing cables by hand or using a cable tracer/tester; and you may even need to peruse MAC address tables. With a Meraki MS switch, however, this process is as easy as connecting to a wall jack with a laptop, opening a web browser, and navigating to switch.merak.com. This URL directs a connected device to a locally-hosted page on the upstream switch advertising the switch’s name, model, MAC, IP, and on which port the wall jack terminates.
This local switch page informs that the tested wall jack terminates on port 11 of switch “Desk MS22.”
3. Perform ad hoc wireless site surveys
Many factors can affect wireless throughput for client devices: environmental variables such as walls and interference, hardware variables such as the speed of a local wireless LAN adapter, as well as what wireless protocols are being used. If you’ve got a laptop handy, you can visit my.meraki.com to get real time statistics on your client’s wireless connectivity as you roam; see AP channel utilization, client signal strength, and client throughput to the AP. Also, easily confirm that your client supports 802.11n.
Real time tools for wireless client surveys are built into AP local configuration pages.
You can even get real time signal strength information about an AP’s wireless mesh neighbors, assisting with AP placement at multi-AP sites.
Learn how strong mesh neighbor APs signal strength is relative to the AP whose local config page you’re viewing.
4. Make uplink and switch port configuration changes
Each local configuration page — whether for an AP, switch, or MX — allows you to configure uplink ports. This entails setting VLAN tagging where appropriate, as well as setting static (or dynamic) IP addresses for uplink interfaces. In the case of the MX security appliance, you can enable a secondary WAN uplink. In the case of MS switches, you can also configure per-port settings to ensure traffic is being forwarded correctly. This functionality is particularly useful if a misconfigured setting has disconnected your Meraki device from the Internet.
Every Meraki device lets you configure uplinks via local configuration settings.
Configure individual switch ports from the MS local configuration page.
To summarize: Meraki local configuration settings can make it easier to spot connectivity issues, identify and trace wall jack switch ports, perform wireless site surveys, and back out of any configuration mishaps to re-establish WAN connectivity. To access the full functionality of Meraki local configuration settings, all you need is an upstream (or directly connected) Meraki device, along with its serial number and a web browser.
For more information about specific local configuration settings, check out our product documentation for the device in question.
With intellectual property, personnel records, and data retrieval systems now living on mobile devices, it is natural to worry about those devices and their data walking out the front door. We are excited to announce a new feature for Systems Manager to put those worries to rest. Geofencing lets administrators define safe areas for mobile devices, and alerts administrators when a device leaves that area. Systems Manager does this by keeping track of GPS and WiFi location data of the mobile devices you would like or need to monitor.
Simply define one or more safe regions under Mobile > Settings > Geofencing, by adding a new area and dragging the area icon across the map to the desired location. Alternatively, you can enter an address and we will perform the geocode lookup for you like below.
Below, we have defined several areas within San Francisco. Make the circles larger or smaller to set the radius.
Once you have an area defined you can select a violation period. Any device that has been out of the specified region beyond the violation duration will trigger an alert. For example, schools can use geofencing to receive alerts when dedicated classroom iPads accidentally leave the classroom. Further yet, retailers or restaurants can now be alerted if mobile point of sale (PoS) devices used by employees are taken off the premises. Alerts can also be customized as to be trigger when a device re-enters a region.
The new geofencing capabilities are also now integrated into System Manager’s client list view. This view enables IT to get a quick snapshot view across all devices including ones that are at the verge of tripping the geofencing alert.
Better yet, if administrators are alerted of a device out of the safe zone, Systems Manager has many built-in features to help ensure corporate data is secure. For iOS and Android devices, administrators can lock, selectively wipe, or even erase a device once it leaves the geofenced area.
The System Manager geofencing capacities are available today without requiring any software upgrades or changes to your existing Systems Manager deployment. If you haven’t already tried out Systems Manager, check it out here!