Upgrade Checklist
This pre-upgrade checklist highlights actions that can prevent common issues. However, we still recommend you refer to the appropriate upgrade or configuration guide for full instructions: Upgrade Instructions.
Important |
At all times during the process, make sure that the appliances in your deployment are successfully communicating and that there are no issues reported. Do not deploy changes to or from, manually reboot, or shut down an upgrading appliance. In most cases, do not restart an upgrade in progress. The upgrade process may appear inactive during prechecks; this is expected. If you encounter issues with the upgrade, including a failed upgrade or unresponsive appliance, there may be something you can do — see the Note on Unresponsive Upgrades. |
Planning and Feasibility
Careful planning and preparation can help you avoid missteps.
✓ |
Action/Check |
||
---|---|---|---|
Assess your deployment. Determine the current state of your deployment. Understanding where you are determines how you get to where you want to go. In addition to current version and model information, determine if your devices are configured for high availability/scalability, and if they are deployed passively, as an IPS, as a firewall, and so on. |
|||
Plan your upgrade path. This is especially important for multi-appliance deployments, multi-hop upgrades, or situations where you need to upgrade operating systems or hosting environments, all while maintaining deployment compatibility. Always know which upgrade you just performed and which you are performing next.
|
|||
Read all upgrade guidelines and plan configuration changes. Especially with major upgrades, upgrading may cause or require significant configuration changes either before or after upgrade. Upgrade guidelines can appear in multiple places. Make sure you read them all. They include:
|
|||
Check appliance access. Devices can stop passing traffic during the upgrade (depending on interface configurations), or if the upgrade fails. Before you upgrade, make sure traffic from your location does not have to traverse the device itself to access the device's management interface. In FMC deployments, you should also able to access the FMC management interface without traversing the device. |
|||
Check bandwidth. Make sure your management network has the bandwidth to perform large data transfers. In FMC deployments, if you transfer an upgrade package to a managed device at the time of upgrade, insufficient bandwidth can extend upgrade time or even cause the upgrade to time out. Whenever possible, copy upgrade packages to managed devices before you initiate the device upgrade. See Guidelines for Downloading Data from the Firepower Management Center to Managed Devices (Troubleshooting TechNote). |
|||
Schedule maintenance windows. Schedule maintenance windows when they will have the least impact, considering any effect on traffic flow and inspection and the time the upgrade is likely to take. Also consider the tasks you must perform in the window, and those you can perform ahead of time. For example, do not wait until the maintenance window to copy upgrade packages to appliances, run readiness checks, perform backups, and so on. |
Upgrade Packages
Upgrade packages are available on the Cisco Support & Download site.
✓ |
Action/Check |
||
---|---|---|---|
Upload upgrade packages. In FMC deployments, upload FMC and all Classic device (ASA FirePOWER, NGIPSv) upgrade packages to the FMC. For FTD, you can either upload upgrade packages to the FMC, or configure your own internal web server as the source for upgrade packages. In FMC high availability deployments, you must upload the FMC upgrade package to both peers, pausing synchronization before you transfer the package to the standby. To limit interruptions to HA synchronization, you can transfer the package to the active peer during the preparation stage of the upgrade, and to the standby peer as part of the actual upgrade process, after you pause synchronization. |
|||
Copy upgrade packages to managed devices. In FMC deployments, we recommend you copy (push) upgrade packages to managed devices before you initiate the device upgrade.
|
Backups
The ability to recover from a disaster is an essential part of any system maintenance plan.
Backup and restore can be a complex process. You do not want to skip any steps or ignore security or licensing concerns. For detailed information on requirements, guidelines, limitations, and best practices for backup and restore, see the configuration guide for your deployment.
Caution |
We strongly recommend you back up to a secure remote location and verify transfer success, both before and after upgrade. |
✓ |
Action/Check |
---|---|
Back up. Back up before and after upgrade, when supported:
|
|
Back up FXOS on the Firepower 4100/9300. Use the Firepower Chassis Manager or the FXOS CLI to export chassis configurations before and after upgrade, including logical device and platform configuration settings. |
|
Back up ASA for ASA with FirePOWER Services. Use ASDM or the ASA CLI to back up configurations and other critical files before and after upgrade, especially if there is an ASA configuration migration. |
Associated Upgrades
Because operating system and hosting environment upgrades can affect traffic flow and inspection, perform them in a maintenance window.
✓ |
Action/Check |
||
---|---|---|---|
Upgrade virtual hosting. If needed, upgrade the hosting environment for any virtual appliances. If this is required, it is usually because you are running an older version of VMware and are performing a major device upgrade. |
|||
Upgrade FXOS on the Firepower 4100/9300. If needed, upgrade FXOS before you upgrade FTD. This is usually a requirement for major upgrades, but very rarely for maintenance releases and patches. To avoid interruptions in traffic flow and inspection, upgrade FXOS in FTD high availability pairs and inter-chassis clusters one chassis at a time.
|
|||
Upgrade ASA on ASA with FirePOWER Services. If desired, upgrade ASA. There is wide compatibility between ASA and ASA FirePOWER versions. However, upgrading allows you to take advantage of new features and resolved issues. For standalone ASA devices, upgrade the ASA FirePOWER module just after you upgrade ASA and reload. For ASA clusters and failover pairs, to avoid interruptions in traffic flow and inspection, fully upgrade these devices one at a time. Upgrade the ASA FirePOWER module just before you reload each unit to upgrade ASA.
|
Final Checks
A set of final checks ensures you are ready to upgrade.
✓ |
Action/Check |
||
---|---|---|---|
Check configurations. Make sure you have made any required pre-upgrade configuration changes, and are prepared to make required post-upgrade configuration changes. |
|||
Check NTP synchronization. Make sure all appliances are synchronized with any NTP server you are using to serve time. Being out of sync can cause upgrade failure. In FMC deployments, the health monitor does alert if clocks are out of sync by more than 10 seconds, but you should still check manually. To check time:
|
|||
Check disk space. Run a disk space check for the software upgrade. Without enough free disk space, the upgrade fails. See the Upgrade the Software chapter in the Cisco Firepower Release Notes for your target version. |
|||
Deploy configurations. Deploying configurations before you upgrade reduces the chance of failure. In some deployments, you may be blocked from upgrade if you have out-of-date configurations. In FMC high availability deployments, you only need to deploy from the active peer. When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts Snort, which interrupts traffic inspection and, depending on how your device handles traffic, may interrupt traffic until the restart completes. See the Upgrade the Software chapter in the Cisco Firepower Release Notes for your target version. |
|||
Check running tasks. Make sure essential tasks are complete before you upgrade, including the final deploy. Tasks running when the upgrade begins are stopped, become failed tasks, and cannot be resumed. We also recommend you check for tasks that are scheduled to run during the upgrade, and cancel or postpone them.
|
|||
Run readiness checks. We recommend compatibility and readiness checks. These checks assess your preparedness for a software upgrade. |
Note on Unresponsive Upgrades
Starting with major and maintenance FTD upgrades from Version 6.7.0, you can manually cancel failed or in-progress upgrades, and retry failed upgrades:
-
FMC deployments: Use the Upgrade Status pop-up, accessible from the Device Management page and the Message Center.
-
FDM deployments: Use the System Upgrade panel.
You can also use the FTD CLI.
Note |
By default, FTD automatically reverts to its pre-upgrade state upon upgrade failure ("auto-cancel"). To be able to manually cancel or retry a failed upgrade, disable the auto-cancel option when you initiate the upgrade. Note that auto-cancel is not supported for patches. In a high availability or clustered deployment, auto-cancel applies to each device individually. That is, if the upgrade fails on one device, only that device is reverted. |
If you have exhausted all options, or if your deployment does not support cancel/retry, contact Cisco TAC.