A new approach to Meraki firmware management

Source: Meraki-Cisco

At Cisco Meraki, our fundamental goal is to bring simplicity to IT management. It has always been important to us that we extend that simplicity to the firmware management process, so over the years we’ve tried to strike the right balance of automation and control so that our customers know that their devices are always up to date with the latest bug fixes, security patches, and features. While our approach has worked well for many of our customers and partners, it has also created challenges for some who felt they would benefit from a greater degree of visibility and flexibility when it comes to firmware. Today we are excited to announce some significant advances in the  firmware management capabilities of the Cisco Meraki dashboard. These new tools and processes add deeper visibility and empower administrators to be more self-sufficient when it comes to our firmware without sacrificing our consistent, reliable update model.

These new capabilities come in the form of an update to the Firmware Upgrades page in the Cisco Meraki dashboard. The new page starts users out on the Overview tab, which includes a variety of information: a list of recent upgrades within the dashboard organization, a list of any currently scheduled upgrades that are pending, and a list of the current approved stable versions of code for each hardware product line in our portfolio. This list of stable firmware versions is one of three major changes represented by this new tool, as it includes not only firmware version numbers but also detailed patch notes for each version. The second major change is that any upgrade performed in the last 14 days can be rolled back directly from the recent upgrades list, which will return the network and its devices to the firmware version that was in place before the upgrade. This allows administrators to react faster and more freely to any issues encountered after a new firmware is applied – even if those issues are with other devices in the deployment.

Firmware Manager Overview

Clicking over to the “All networks” tab presents administrators with a searchable list of all dashboard networks in the organization and their firmware status. Based on the current status of each network, certain upgrade options will be available to put networks on the latest stable firmware, a release candidate firmware (which is a version that is currently undergoing final testing before becoming the new stable version), or the latest beta. The statuses a network can have are as follows:

  • Upgrade available – This network is not running the latest stable version, and can be upgraded to stable, beta, or release candidate firmwares assuming that a release candidate version exists.
  • Up to date (stable release candidate available) – This network is running the latest stable version, but can be upgraded either to a release candidate or the current recommended beta firmware.
  • Up to date (beta available) – This network is running the latest stable version, but can be upgraded to the current recommended beta firmware.
  • On Beta (beta available) – This network is running a beta version, but not the most recent one. It can be upgraded to the current recommended beta firmware.
  • Up to date – This network is running the latest beta code and cannot be upgraded.

Firmware Manager Networks

This represents the third and final major change included in this new tool: administrators can now upgrade to beta firmware themselves, without the need to contact Cisco Meraki Support or their Sales representative. This makes it easier for customers to access new features and bug fixes as quickly as possible. In addition, when upgrading a network to a new firmware version administrators will be able to view patch notes not only for the new firmware, but any versions in between the current and upgrade firmwares, to get a clear picture of exactly what is changing in the code. To perform an upgrade, simply select one or more networks from the list and click the “Bulk upgrade” button at the top right of the page.
These new capabilities are a big step forward in firmware visibility and control for our customers, and we hope they will make it easier for all Meraki users worldwide to get access to new features, resolve issues, and keep their networks secure. This new page will be available today for all Cisco Meraki dashboard organizations via the Organization>Firmware upgrades menu option, so take a look for yourself and, as always, let us know what you think!


A new approach to Meraki firmware management

Put your untrusted clients on ISE

Source: Meraki-Cisco

The last decade has seen a drastic increase in the number of network-connected devices.  Because of this, it has become more and more difficult for administrators to manage access, security, and traffic policies for all of the clients in their networks.  As with a lot of other IT challenges, the key to solving this problem lies in automation – removing as much of the manual work as possible by creating ways to dynamically and intelligently assign policies to clients.  One of the most effective ways to accomplish this is through a technology known as Change of Authorization (CoA).

At the most basic level, CoA is just a mechanism for changing the policy of an already-connected client.  While that might sound pretty simple, there are actually a variety of ways that CoA can be used to solve complex problems in a wireless network.  For example, you might want clients to have different levels of network access based on the current security status of the device, often referred to as its “security posture”.  A device’s posture includes things like whether it has up-to-date antivirus and anti-spyware software installed, whether the latest operating system security patches are installed, or even whether a certain application is installed on the device. Using CoA, you can send information from Cisco’s Identity Services Engine (ISE) or similar solutions to a Cisco Meraki AP informing it of any changes to a device’s posture.  The AP can then apply the appropriate policy to that client, even if it is already connected.  You can also leverage ISE to perform Central Web Authentication (CWA) in order to implement automatic authentication and policy application for guest users.

Like all Cisco Meraki features, we took care to ensure that CoA is simple to implement.  For administrators who wish to use Cisco ISE as their RADIUS and CoA server, it’s as easy as navigating to the Wireless>Access Control page and selecting ‘WPA2-Enterprise with my RADIUS server’ in the Association requirements section, and ‘Cisco Identity Services Engine (ISE) Authentication’ in the Splash page section.

Screen Shot 2016-04-26 at 10.21.22 AM

Add your ISE server information under RADIUS servers, and you’re good to go!  Your APs will now redirect users to the ISE web portal for authentication when they connect, and will respond to CoA messages sent by the ISE server.

For other popular solutions like PacketFence, the process is just as easy.  Instead of selecting ISE Authentication from the Splash page options, set RADIUS CoA support to ‘RADIUS CoA enabled’ in the RADIUS server options on the same page.

Screen Shot 2016-04-26 at 10.21.27 AM

The AP will now respond to CoA messages sent by the RADIUS server.

These features are currently in open beta.  If you want to try them out, you can reach out to our Support team or to your Cisco Meraki Systems Engineer to join the beta.  For more information on configuring CoA on Cisco Meraki MR access points or to learn more about this feature, check out our documentation.


Put your untrusted clients on ISE

Power to the People

Source: Meraki-Cisco

Since the inception of the MX product line, one message has come through loud and clear from our customers and partners: they love the MX for branch deployments. From the original MX50 to the MX60 and the more recent (and very well received) addition of the MX64, we’ve continued to invest in new branch MX models and features. This week, we take a huge step forward in the evolution of cloud-managed branch security with the release of the new MX65 and MX65W security appliances.

The first thing anyone will probably notice about the MX65 is the significant increase in port count. The new models host a whopping 12 Gigabit Ethernet ports, more than twice as many as the MX64. This removes the need for an additional switch in locations where there are only a handful of devices requiring network connectivity, helping to keep the cost and complexity of the deployment to a minimum. Fitting these ports onto the back of the device has resulted in a couple of minor design changes, such as the reset button and USB port being on the side of the unit rather than the back. Best of all, thanks to some phenomenal design work by our hardware team, we’ve accomplished all of this without significantly increasing the size of the unit – it’s the same height and depth as the MX64, and less than an inch wider.

mx65_rear

Even more important than the number of ports is how we’ve allocated those ports. While eight of them are standard LAN ports like those found on other MX models, the other four have something special to offer. First we have two dedicated WAN ports, so that administrators can connect two Internet or MPLS connections without sacrificing one of the LAN ports. This not only makes the unit simpler to deploy, it also means that the MX65 is a perfect fit for customers who want to make use of our IWAN features to get full use out of their redundant connections.

The last two ports offer the most striking difference in functionality between the MX65 and previous models. As indicated by the lightning bolt icons to the left of the port numbers, these ports provide Power over Ethernet (PoE). Each port operates on the 802.3at standard, also known as PoE+, and provides up to 30 watts of power to any connected PoE-capable device. These can include phones, cameras, wireless access points, or a variety of other devices. As with the increased port count, this change makes it much easier to deploy the MX65 without the need for additional hardware such as switches or PoE injectors, resulting in a cleaner branch architecture and an easier deployment.

Alamo Front (1)

Last but not least, the MX65W boasts not only a new and improved revision of the MX64W’s 802.11ac wireless chipset, but also a custom antenna design that provides both better range and improved wireless performance. For sites that need wireless coverage that goes beyond what a single unit can offer, you can of course still deploy an MX65 with any of our MR Access Points – and with the new PoE capabilities, you can power up to two APs from the MX65 itself.

To learn more about the MX65 and MX65W and how they fit in with the rest of the MX portfolio, check out the Cisco Meraki website.


Power to the People