Firmware Management and Lifecycle – Cisco Meraki Cloud Architecture Basics

Meraki strives to provide simple management of firmware for all devices across every product line. As a part of this effort, firmware upgrades to the latest Stable or Stable Release Candidate firmware may be automatically scheduled by Meraki for customer networks to ensure that devices are always running a current, fully supported firmware. These automatic upgrades are scheduled according to the day of the week and time of day that the customer has designated in the Network-wide > General configuration menu, and Meraki sends appropriate notifications 7 to 14 days before the upgrade takes place to allow customers the opportunity to cancel or reschedule the upgrade if required. If after upgrading firmware a customer would like to revert to the previous version for any reason, they can manually schedule firmware rollbacks for any recently upgraded networks.

Every firmware release goes through an extensive testing process, including stability, performance, and regression testing, to ensure that each stable release meets the requirements to be labeled as such. The public firmware rollout process follows three stages that every firmware is required to pass through to receive the stable release designation: Beta, Stable Release Candidate, and Stable. Figure 1-5 shows the Dashboard view for the current Stable firmware versions across products.

Images

Figure 1-5 Latest Stable Firmware Versions as Viewed in the Dashboard

Beta firmware is made available for customers who wish to take advantage of new features or bugfixes as soon as they are available. All beta firmware has already gone through internal stability, performance, and regression testing to help limit unforeseen negative impacts for customers who choose to run this new release on any production networks. The current beta firmware is always fully supported by the Meraki support and engineering teams and can be considered analogous to “early deployment” firmware of other industry products.

Using beta firmware versions requires customers to opt in to participate in the beta program before upgrading, after which they may see additional automatic upgrades scheduled by Meraki, as described previously, to keep their networks up to date with the most recent beta releases.

After a successful formal review of an existing beta firmware version by the Meraki software and product teams, the new firmware may be promoted to a Stable Release Candidate (RC). Once a firmware has been designated as a Stable RC, Meraki will begin scheduling a limited set of customer networks to upgrade to the new Stable RC firmware. As noted previously, these automatic upgrades can be rescheduled, canceled, or reverted via the Dashboard any time after being automatically scheduled.

Once a Stable RC firmware version hits a threshold of deployment across all deployed nodes around the world, it triggers another formal review by the Meraki software and product teams. If the Stable RC version receives a favorable review and meets the full set of requirements for a given product line, it will then be promoted to a full Stable release. After receiving the Stable designation, the firmware will continue to be automatically scheduled for customer networks running now outdated firmware and will also become the default firmware version for all newly created networks of a given device type.

The actual firmware upgrade process is identical across all product lines. Once a firmware upgrade has been scheduled, the cloud controller begins the upgrade process at the scheduled time by pushing to the relevant device(s) a configuration update that includes the new firmware information. The device(s) will then initiate a connection back to the Meraki cloud to download the new firmware from the controller before rebooting to apply the upgrade.

Because of the way Meraki has implemented firmware upgrades, devices continue to serve clients and function normally while downloading and preparing the new firmware. As a result, the only interruption to normal operation is the reboot of the device to reload into the new version. If for any reason the new firmware fails to load or the device is unable to regain connectivity to the cloud controller after the upgrade, the device will simply reboot and revert to the previous running firmware and configuration, which remains stored on the device until the upgrade is marked as successful. We will cover in depth the steps involved in checking firmware statuses and scheduling upgrades in Chapter 3, “The Meraki Admin Experience.”

Meraki MS series switches and MR series access points also offer some additional features when configuring firmware upgrades to help reduce the impact of multiple devices downloading and applying a firmware upgrade at once. When scheduling firmware upgrades for MR access points, the option is available to stagger the upgrade across devices in the network in effort to reduce the interruption to network clients, or to minimize the upgrade time by pushing the upgrade to all devices at once.

Leave a Reply

Your email address will not be published. Required fields are marked *