Recently Apple introduced managed distribution, greatly simplifying the way apps are managed. The Cisco Meraki team has already updated Systems Manager to take advantage of these new enhancements.
In the past, there were some challenges when managing VPP codes. When an app claimed via a VPP code was pushed to a device, the Apple ID used to install the app would take ownership. This caused difficulties when apps needed to be transferred from one device to another; employee leaving an organization, or students moving from 4th to 5th grade. Administrators no longer had control of the app and might have to repurchase it.
Now, apps purchased via VPP codes can be reclaimed and reassigned. This is huge news for schools and enterprises who spend valuable capital on apps for students or employees. Furthermore, Systems Manager allows you to easily manage the whole exchange. Simply enter your VPP credentials in Systems Manager and all of your VPP data will be imported and kept up to date.
Below, we can see how many licenses we have available for the Physics app, how many are currently in use, and from the same page we can grant or revoke access to each user.
If you are new to managing apps with VPP codes Apple has some great resources for schools and businesses to learn more, and for detailed steps on how to set up managed distribution with Systems Manager, check out our knowledge base. As usual, Systems Manager is completely free so test it out by managing your own devices at home or at work.
As we head into the Thanksgiving holiday, we are thankful for the exciting year we’ve had and love being able to give back when possible to various charities and causes.
Earlier this year, a strapping sales team put their muscles to work for Habitat for Humanity by cleaning up a local park, including planting new flowers and trees.
The Cisco Meraki team earns their t-shirts after a day of elbow grease and yardwork.
In September, a fit team of runners participated in the JPMorgan Chase Corporate Run. We had over 15 registered runners on the team who helped raise money for this year’s San Francisco beneficiary, Larkin Street Youth Services. Led by Chris Ashley, who finished his 3.5 miles in under 20 minutes, the Cisco team made a strong showing.
The runners show off their athletic calves.
Always looking for ways to use his athletic ability for good, Jack Wall recently made a splash in his unique way of raising money for charity – by dancing!
Dancing for Foster Children benefited SF Casa, an organization with a mission to train community volunteers to serve as officers of the court to advocate for the best interests of abused and neglected children in the foster care system. As an extra incentive to donate, Jack announced that the person with the highest donation would have the honor of choosing his dancing outfit. See below for the end result:
Jack’s dance outfit, expertly styled by Denise.
Movember is always an exciting time at Meraki, and this year is no different. Emboldened by last year’s success, the hirsute folks at Meraki have once again formed Team Moraki. The enthusiastic participants’ main goal is to raise money for men’s health, but they’re also competing to make it into the infamous Mo’raki Calendar.
Select months from the 2013 calendar shown below:
We’re always coming up with new charities, organizations, and pursuits to put our energies into! Like us on Facebook to see photos and share ideas on how to give back over the holidays.
One of the beauties of cloud-based network management is the ability to easily manage large networks across multiple physical locations. The dashboard acts as a window onto your complete network, as though all the equipment was right in front of you. By way of an example, one of Cisco Meraki’s customers is a hotel chain operating approximately 10,000 access points, providing coverage to 70,000 hotel rooms across the United States.
Cloud management makes this a cinch so that, thanks to the power of tagging and search, managing 10,000 devices is as easy as managing 10. With the help of a few examples, today’s blog post illustrates how search takes the pain out of locating the ports or devices to be configured or monitored.
Search can be used to locate network infrastructure or client devices, in the latter using attributes like device description, manufacturer, MAC or IP address. In this simple example we’ve identified 33 iPads seen amongst 1,424 clients, identified using device fingerprinting techniques. Notice that you can further refine the search by additionally searching by other details, like operating system and VLAN number.
So if the admin wanted to view only the iPads in VLAN 108, they would simply select the VLAN number from the dropdown list and add ‘AND ipad’. Here’s the result:
It’s possible to build refined searches by adding further expressions, so for example a search for (VLAN:”108”) AND ipad OR iphone would display both device types within that VLAN, and adding ‘Michael’ will display that owner’s devices in that VLAN.
Search is even more powerful when used to identify specific network devices, like APs and switches or switch ports. Tags are perhaps the most flexible, enabling the network administrator to logically group devices together, say by wiring closet, floor, or site location. Beyond tags, a number of search terms are available.
Suppose the network admin wanted to search for those APs on the 4th floor of the building using Channel 1 in the 2.4 GHz spectrum.
In the case of LAN switches, there may be many hundreds, or even thousands of ports across an organization, and Cisco Meraki virtual stacking technology makes it possible to configure hundreds of ports at a time, regardless of the switches’ physical locations. Take the case of a new firmware revision to be deployed on all Shoretel VoIP phones in the standard voice VLAN. The search might look like this:
Here the search references an LLDP attribute, the tag ‘voip’ and the VLAN to search for. From here, all 113 ports could have their PoE toggled off and on again to force these phones to reboot and pick up their new firmware from the call server. These 113 phones could be located on sites around the world, thanks to the location agnostic nature of our virtual stacking technology.
These few examples have just scratched the surface of what the search tools can do, but they neatly illustrate the potential for managing huge multi-site networks from wherever the network admin can get an internet connection.
Raj is the product manager of the Cisco Meraki wireless portfolio, managing the day-to-day activities and strategic direction of Cisco’s cloud-managed wireless portfolio. Throughout his career, Raj has constantly been thinking about ways to make a positive impact at scale, and with the cloud found key technology that could be leveraged to improve people’s lives. Today, this theme continues to guide his work.
“Thinking about complex business problems and applying technology to try to solve those problems is pretty cool. What’s also awesome is knowing that if you succeed, you’ll ultimately be making people’s lives better.”
Raj meets with wireless engineering to discuss product specifications
After graduating from high school and prior to his days as an undergrad at UCLA, Raj founded a telecommunications company that focused on making it easier for people to communicate over SMS. Having gained experience in product development and management, he decided to join an organization where he could work on larger-scale systems and explore concepts he had learned along the way: using the power of cloud technology to deliver valuable solutions to customers. He found a perfect fit with the Meraki team.
Raj has been with the Meraki team for two years and has worked on a wide range of wireless hardware and software projects. Recently, he shed some light on one of the most exciting features he’s worked on, Meraki Presence, our built-in location analytics.
Update: Cisco Meraki Presence is now known as CMX (Connected Mobile Experiences), a comprehensive location analytics and engagement platform ideal for both cloud-managed or on-premise solutions. Click here to learn more.
“Presence was exciting because we took an unconventional approach to solve IT, marketing, and operations problems, and we were able to deliver additional value that isn’t typically seen in enterprise networking. We creatively leveraged a technical aspect — that WiFi devices constantly probe for networks to connect to — and paired it with data analytics to deliver valuable insight for marketing teams.”
Raj and the engineering team introduce Presence Analytics in the video below.
As an innovative feature of the Meraki wireless product line, Raj knew it was important to demystify the technology behind the solution. In the Presence Analytics White Paper, Raj exposed how the technology works and how customers can leverage it using the Meraki dashboard or the Presence API.
Looking ahead, Raj is excited about the potential for the widespread use Cisco Meraki technology across the enterprise market.
“Even though we‘ve had a ton of growth and resonance in the market, it’s exciting to know how many more customers we can reach. Adapting the product and platform to scale as we grow is going to be pretty challenging.”
It wasn’t too long ago that Meraki was a 10-person company setting up our first office. Now, using the resources that come with being part of a larger organization, we love to contribute to the thriving startup scene in any way we can. To take advantage of our unique office space and beautiful views, we’re big proponents of hosting tech talks and Meetups to keep up with the latest in the tech startup world.
Earlier this month, we hosted a GoSF event in which over 100 engineers enjoyed Delfina pizza while learning about the programming language Go.
This Wednesday, Yuchung Cheng will be giving a tech talk titled “Let’s Make TCP Fast for the Modern Web.” Yuchung Cheng is a software engineer at Google since 2007. He works on making TCP fast for Web and Google services, and is an active member of the Linux networking community and the IETF transport area. A very yummy dinner will be catered by Rice, Paper, Scissors.
There’s quite a bit of excitement around 802.11ac. It’s not only the latest wireless standard, but recently more devices have added support for it, spreading and accelerating the adoption of gigabit WiFi.
A survey of devices earlier this year showed a handful of them supported 802.11ac, especially higher end smartphones. Recently, more smartphones have added support, and importantly, Apple’s refresh of the Macbook Pro and Macbook Air added 802.11ac to their popular line. Here’s a summary of recently introduced clients that support 802.11ac.
In the summer, Apple refreshed the Macbook Air, including faster WiFi, longer battery life, and a higher-quality display. This was the first Apple product to include 802.11ac, using a 2×2 (dual-stream) implementation with a maximum theoretical data rate of 867 Mbps. In the words of AnandTech, “The move to 802.11ac feels like a game changer once more notebooks get there.”
Apple must have taken heed of that, because just a few months later the Macbook Pro line was refreshed, adding Retina displays and enhanced processing and graphics, as well as 3×3 (triple-stream) 802.11ac support up to a maximum theoretical data rate of 1.3 Gbps. The innards are displayed for all to see in iFixit’s teardown of the 13 inch model.
It’s also worth noting that Apple dropped the price on the Macbook Air and Macbook Pro, setting the entry points at $999 and $1,299 (with Retina display).
Apple’s love for 802.11ac didn’t end with the refreshes of the Macbook lines. Apple also updated the iMac line, introducing performance enhancements such as updated graphics, faster storage, and yes, 3×3 802.11ac at up to a maximum theoretical data rate of 1.3 Gps. The upgraded WiFi is available on the 21.5 inch and 27 inch models and shown in the iFixit teardown of the 21.5 inch model.
Android and the Nexus 5
The spotlight on devices doesn’t shine only on Apple. Google just released their flagship Android phone, the Nexus 5. The hardware is luxuriously high end, with a large 1080p display and plenty of RAM, and the WiFi is no exception as it includes 802.11ac (1×1, single stream). Once again, the iFixit teardown reveals the juicy details.
It’s exciting to see more and more clients support 802.11ac, especially flagship models like the Nexus 5 and Apple Macbook Pro. Want to find out more about 802.11ac? Sign up for our webinar to learn about growing your network with 802.11ac.
Our newly-announced Cisco Meraki MS320 switches come with out-of-the-box “Layer 3 Essentials” functionality, specifically static routing and DHCP relay. These two features are critical for organizations that want a flexible, performance-driven switching fabric to help them isolate client traffic for reasons of security, speed improvement, and cost.
For example, to enhance security you may wish to isolate your HR department’s traffic from that of your guest network. Or, perhaps you want to separate data and voice traffic, so you can apply quality of service (QoS) tags to — and improve the performance of — that voice traffic. Or maybe you’d like to avoid purchasing additional Layer 3 devices to attach to your Layer 2 switches (to allow isolated network segments to communicate with each other).
The examples above are made possible with Virtual LANs (VLANs), support for which is present in every Meraki MS switch. VLANs segment a wired network into separate logical networks, preventing clients in different VLANs from communicating without a Layer 3 device installed to route packets appropriately. Another way to think of this is that VLANs define broadcast domains, ensuring clients are only seeing and processing traffic relevant to their respective VLAN.
The static routing functionality of Cisco Meraki MS320 series switches lets you route traffic between VLANs without needing extra Layer 3 devices attached to your switches; routing is done inside the switch itself. So if your HR and Finance departments were isolated in separate VLANs, but you’d like certain traffic to pass between the two, you can easily enable this with an MS320 switch. To do this, you would specify which IP subnets are assigned to which VLAN, and next hop routes, from within the Meraki dashboard:
Setting up Layer 3 routes in the MS320 series switches.
To enable multiple VLANs within a single physical network, DHCP relay ensures that isolated network segments can receive IP addresses for their respective clients — even if a DHCP server is not installed directly on that segment.
An MS320 switch in VLAN 10 knows to relay DHCP requests to a server in a separate VLAN.
We’re excited to offer our customers the additional flexibility, security, and cost reduction that static routing and DHCP relay facilitate. We’re continuing our Layer 3 development, and expect to release OSPFv2 support for the MS320 family in Q2 CY2014. If you’d like to test drive Meraki switches in your own environment, please check out our free evaluation program.
When users connect to a Cisco Meraki wireless network, they may be presented with a splash page to click through to gain full Internet and resource access. Using splash pages, IT admins can present users with a network usage policy they must agree to or other relevant information about that network. Another splash-dependent feature of Meraki wireless networks is our integrated WiFi with Facebook Login that lets users associate to SSIDs using their Facebook credentials.
The Meraki MX security appliance will support both click-through and Facebook Login splash (this functionality will be released as part of our upcoming feature update, at the end of this calendar year). Depending on your network architecture, the MX can provide splash pages for both wired and wireless users.
How to configure splash pages
Setting up MX splash will be easy, and you’ll be able to tailor different splash pages to different groups of users via VLANs. For example, if you want general users of your network to see one splash page while members of the HR department to see another, you can apply specific splash page settings to the relevant VLANs of each.
Suppose we have VLAN 1 configured on our MX for native, untagged traffic and VLAN 100 for HR-related traffic:
You can configure VLAN IDs on the MX by going to Configure > Addressing & VLANs in the Meraki dashboard.
To configure a wired splash page for general user traffic, navigate to Configure > Access Control in the Meraki dashboard and enable wired splash for VLAN 1 from the “Select VLAN” drop-down menu.
There are several options (including network access control) that can be enabled on a per-VLAN basis for wired splash.
Next, navigate to Configure > Splash page and customize your splash page and its behavior. You can create a unique theme with your own text and image to display to client devices. You can also redirect splash login requests to a custom URL if desired.
MX splash page options let you customize the text, images, and behavior of login splash pages.
MX splash pages can be set to require a click-through from end users at various, preset intervals.
Once you click “Save” you will have configured a wired splash page to display (every day in this example) to general users of your wired network who are hosted by default on VLAN 1. This also means that any downstream APs allowing untagged traffic will present this splash page to wireless clients at association.
Here, a wireless mobile device has been presented with the upstream MX’s wired splash page for untagged traffic when joining the SSID “Desk-Set.”
You can create separate wired splash pages for the different VLANs on your network and, as long as your APs can tag and forward VLAN traffic (as all Meraki MR APs can), you can enable wireless clients to view splash pages that are specific to the VLANs they are a part of.
MX Splash with Facebook Login
In addition to click-through splash pages, you’ll have the option of enabling Facebook Login as well. Facebook Login provides several benefits, and is a great way to simplify guest access by allowing users to login using their Facebook credentials. To successfully deploy Facebook Login, however, your organization must have a Facebook Page to serve as the splash landing page.
In sum, Wired splash will be a great new feature that will allow network admins to offer customized splash pages on a per-VLAN basis — useful for wired environments looking to offer differentiated login experiences, as well as for those who want the flexibility of Facebook Login for their guests. Again, keep an eye out for our next MX feature update — coming soon! — if you’d like to implement wired splash in your organization.
Organizations managing multiple Cisco Meraki MX security appliances across sites often want to push out identical configurations — and subsequent setting changes — to them all. Meraki MXs will support template-based networks, a feature that lets network administrators configure one MX network as a master template whose configuration is pushed to other MX networks “bound” to it. This feature will be rolled out in our upcoming firmware update, scheduled for the end of this calendar year.
This greatly simplifies multi-site management. Not only do templates allow you to make configuration changes for several sites at once, but you can create many templates and bind separate networks to them, enforcing varying levels of security across sites.
For example, suppose you oversee a distributed network and want to ensure that all branch location MXs are configured with certain firewall and traffic shaping rules. Other settings — such as addressing, Active Directory authentication, security and content filtering, alerts, dashboard administrator access, and more — could also be configured, but we’ll keep this example simple.
To create a network template, simply go to Organization > Configuration templates in the Meraki dashboard. Select the Add a new template button, name your new template, and choose a network to copy initial settings from if need be.
Once you’ve created an MX template network, it’s time to make configuration changes that will propagate to all other MXs linked or “bound” to it. In our example, you’d now select the network template you just created, and configure site-wide rules throttling and prioritizing certain applications or traffic categories.
When you’re ready to link other MX networks to your template, navigate back to Organization > Configuration templates and click the name of the template you’ve just modified.
You’ll see more details on which MX networks are already linked to this specific template, along with an option to bind more networks to it.
Simply select the wired networks you’d like to bind to the template, and click Bind.
Now, the configuration that you’ve created for your MX template network will propagate to all other MX networks that are linked to it.
A few considerations
First, MX configuration templates differ from the configuration sync tool in that template-bound networks will inherit all settings from the MX template network, and these inherited settings override any locally configured settings. Also, configuration templates are only available to Cisco Meraki MX networks; MX security settings are propagated down to other MXs. You cannot link other Meraki devices — such as APs or switches — to templates.
If you manage dozens of branch locations with MX security appliances, configuration templates can save you lots of time and troubleshooting, as well as help you quickly ensure baseline security across all sites in just a few dashboard clicks. We’re excited by this new enhancement, and encourage you to try it out in your organization. If you’d like to test drive some MXs, please check out our free eval program!
Earlier this year, we introduced some additions to our Cisco Meraki MS switch portfolio: the eight-port MS220-8/P models, as well as our new Layer 3 aggregation switch, the MS420 (in 24- and 48-port configurations). Today, we’re excited to announce a major expansion of our switching line with 10 additional new models:
So what’s exciting, new, and different about these new families? We’ll look at the main areas of differentiation: Layer 2 vs. Layer 3 support, uplink speed, power supply options, PoE budgeting, and cooling.
Layer 3 Support
All MS320 switch models support static routing and DHCP Helper (aka DHCP relay) functionality. Static routing lets a switch perform inter-VLAN routing internally, without the need for an external Layer 3 device attached via a trunk port.
DHCP Helper lets switch clients request and receive IP addresses from DHCP servers located in VLANs other than their own — useful when a client’s subnet doesn’t host its own DHCP server.
This Layer 3 “Lite” functionality will be extended (via firmware update) in Q2 of calendar year 2014 to include OSPFv2 dynamic routing support.
Both the new MS220 and MS320 switches come configured with either 24 or 48 ports, all running 1 GbE. Additionally, on the MS220 models, 4 SFP uplink ports provide 1 Gbps connectivity to aggregation or core switches. MS320 models sport 4 SFP+ uplink ports for 10 Gbps connectivity.
Power Supply & PoE Budgets
The MS220 line (excluding MS220-8/P models) comes with hardware support for rack-mountable, remote power supplies (RPS). These RPS serve as backup power for MS220 switches in the event of any issues with an internal power unit.
MS320 switches, in contrast, will sport hot-swappable, redundant power supplies.
MS320 power supplies.
All MS220 and MS320 models offer non-PoE or PoE versions supporting both 802.3af (PoE) and 802.3at (PoE+). For PoE-enabled switches, you can now choose between half-powered (LP) or full-powered (FP) models. LP switches sport a total power budget of 370W, while FP models clock in with a budget of 740W — enough to concurrently power 41 of our new MR34 802.11ac access points, which require PoE+ for full functionality.
In the MS320 models, system fans that regulate airflow and temperature are integrated into the replaceable power supplies. Fan replacement, if needed, can be performed on a live switch without incurring any downtime and with no additional cost related to shipping for RMA or reinstallation.
MS220 and MS320 switches are now available to order through Cisco Meraki resellers.
MS220 switches are orderable in 8, 24, and 48 port configurations — with or without PoE/PoE+.