Upgrade Guidelines

This document provides critical and release-specific upgrade guidelines for Version 6.4.

Planning Your Upgrade

Careful planning and preparation can help you avoid missteps. This table summarizes the upgrade planning process. For detailed checklists and procedures, see the appropriate upgrade or configuration guide: http://www.cisco.com/go/threatdefense-64-docs.

Table 1. Upgrade Planning Phases

Planning Phase

Includes

Planning and Feasibility

Assess your deployment.

Plan your upgrade path.

Read all upgrade guidelines and plan configuration changes.

Check appliance access.

Check bandwidth.

Schedule maintenance windows.

Backups

Back up configurations and events.

Back up FXOS on the Firepower 4100/9300.

Back up ASA for ASA FirePOWER.

Upgrade Packages

Download upgrade packages from Cisco.

Upload upgrade packages to the system.

Associated Upgrades

Upgrade virtual hosting in virtual deployments.

Upgrade firmware on the Firepower 4100/9300.

Upgrade FXOS on the Firepower 4100/9300.

Upgrade ASA for ASA FirePOWER.

Final Checks

Check configurations.

Check NTP synchronization.

Deploy configurations.

Run readiness checks.

Check disk space.

Check running tasks.

Check deployment health and communications.

Minimum Version to Upgrade

Minimum Version to Upgrade

You can upgrade directly to Version 6.4 as follows.

Table 2. Minimum Version to Upgrade to Version 6.4

Platform

Minimum Version

FMC

6.1

FTD

(except Firepower 4100/9300)

6.1 with FMC

6.2 with FDM

FXOS 2.6.1.157 is required for the Firepower 4100/9300. In most cases, we recommend you use the latest FXOS build in each major version. To help you decide, see the Cisco Firepower 4100/9300 FXOS Release Notes, 2.6(1).

FTD for the Firepower 4100/9300

6.2

Firepower 7000/8000 series

6.1

ASA with FirePOWER Services

6.1 with FMC

6.2 with ASDM

See Device Platforms for ASA requirements for your model. Although there is wide compatibility between ASA and ASA FirePOWER versions, upgrading allows you to take advantage of new features and resolved issues. To help you decide, see the Cisco Secure Firewall ASA Release Notes.

NGIPSv

6.1

Minimum Version to Patch

Patches change the fourth digit only. You cannot upgrade directly to a patch from a previous major or maintenance release.

Upgrade Guidelines for Version 6.4

These checklists provide new and/or previously published upgrade guidelines that may apply to you.

Table 3. Upgrade Guidelines for FTD with FMC Version 6.4

✓

Guideline

Platforms

Upgrading From

Directly To

ALWAYS CHECK

Minimum Version to Upgrade

Any

Any

Any

Cisco Secure Firewall Management Center New Features by Release, for new and deprecated features that have upgrade impact. Check all versions between your current and target version.

Any

Any

Any

Bugs, for bugs that have upgrade impact. Check all versions of the release notes between your current and target version.

Any

Any

Any

Upgrade Guidelines for the Firepower 4100/9300 Chassis

Firepower 4100/9300

Any

Any

Patches That Support Uninstall

Any

Any

Any

ADDITIONAL GUIDELINES FOR SPECIFIC DEPLOYMENTS

Upgrade Caution: Firepower 7000/8000 Series to Version 6.4.0.9–6.4.0.11

Firepower 7000/8000 series

6.4.0 through 6.4.0.10

6.4.0.9 through 6.4.0.11

EtherChannels on Firepower 1010 Devices Can Blackhole Egress Traffic

Firepower 1010

6.4.0 only

6.4.0.3 through 6.4.0.5

TLS Crypto Acceleration Enabled/Cannot Disable

Firepower 2100 series

Firepower 4100/9300

6.2.3 through 6.3.0.x

6.4+

Upgrade Failure: NGIPS Devices Previously at Version 6.2.3.12

Firepower 7000/8000 series

ASA FirePOWER

NGIPSv

6.2.3 through 6.3.0.x

6.4.0 only

Upgrade Failure: Insufficient Disk Space on Container Instances

Firepower 4100/9300

6.3.0 through 6.4.0.x

6.3.0.1 through 6.5.0

Renamed Upgrade and Installation Packages

FMC

Firepower 7000/8000 series

NGIPSv

Any

6.3+

Readiness Check May Fail on FMC, 7000/8000 Series, NGIPSv

FMC

Firepower 7000/8000 series

NGIPSv

6.1.0 through 6.1.0.6

6.2.0 through 6.2.0.6

6.2.1

6.2.2 through 6.2.2.4

6.2.3 through 6.2.3.4

6.3+

RA VPN Default Setting Change Can Block VPN Traffic

FTD

6.2.0 through 6.2.3.x

6.3+

Security Intelligence Enables Application Identification

FMC deployments

6.1.0 through 6.2.3.x

6.3+

Update VDB after Upgrade to Enable CIP Detection

Any

6.1.0 through 6.2.3.x

6.3+

Invalid Intrusion Variable Sets Can Cause Deploy Failure

Any

6.1.0 through 6.2.3.x

6.3+

Remove Site IDs from Version 6.1.x Firepower Threat Defense Clusters Before Upgrade

FTD clusters

6.1.0.x

6.2.3+

Access Control Can Get Latency-Based Performance Settings from SRUs

FMC

6.1.0.x

6.2+

'Snort Fail Open' Replaces 'Failsafe' on FTD

FTD

6.1.0.x

6.2+
Table 4. Upgrade Guidelines for FTD with FDM Version 6.4

✓

Guideline

Platforms

Upgrading From

Directly To

ALWAYS CHECK

Minimum Version to Upgrade

Any

Any

Any

Cisco Secure Firewall Device Manager New Features by Release, for new and deprecated features that have upgrade impact. Check all versions between your current and target version.

Any

Any

Any

Bugs, for bugs that have upgrade impact. Check all versions of the release notes between your current and target version.

Any

Any

Any

Upgrade Guidelines for the Firepower 4100/9300 Chassis

Firepower 4100/9300

Any

Any

ADDITIONAL GUIDELINES FOR SPECIFIC DEPLOYMENTS

EtherChannels on Firepower 1010 Devices Can Blackhole Egress Traffic

Firepower 1010

6.4.0 only

6.4.0.3 through 6.4.0.5

TLS Crypto Acceleration Enabled/Cannot Disable

Firepower 2100 series

Firepower 4100/9300

6.2.3 through 6.3.0.x

6.4+

Update VDB after Upgrade to Enable CIP Detection

Any

6.1.0 through 6.2.3.x

6.3+

Invalid Intrusion Variable Sets Can Cause Deploy Failure

Any

6.1.0 through 6.2.3.x

6.3+

Upgrade Can Unregister FDM from CSSM

Any

6.2.0 through 6.2.2.x

6.2.3+

Upgrade Failure: FDM on ASA 5500-X Series from Version 6.2.0

Any

6.2.0 only

6.2.2+

Upgrade Caution: Firepower 7000/8000 Series to Version 6.4.0.9–6.4.0.11

Deployments: Firepower 7000/8000 series

Upgrading From: Version 6.4.0 through 6.4.0.10

Directly To: Version 6.4.0.9 through 6.4.0.11

Related Bug: CSCvw01028

If your Firepower 7000/8000 series device ever ran a version older than Version 6.4.0, do not upgrade to Version 6.4.0.9, 6.4.0.10, or 6.4.0.11. Otherwise, your device may become unresponsive and you will be forced to reimage. Instead, upgrade to Version 6.4.0.12+.

If you are already running one of the affected versions and you are vulnerable to this issue, you should contact Cisco TAC for a hotfix, then upgrade to Version 6.4.0.12 as soon as possible. You can also reimage and upgrade.

EtherChannels on Firepower 1010 Devices Can Blackhole Egress Traffic

Deployments: Firepower 1010 with FTD

Affected Versions: Version 6.4.0 to 6.4.0.5

Related Bug: CSCvq81354

We strongly recommend you do not configure EtherChannels on Firepower 1010 devices running FTD Version 6.4.0 to Version 6.4.0.5. (Note that Versions 6.4.0.1 and 6.4.0.2 are not supported on this model.)

Due to an internal traffic hashing issue, some EtherChannels on Firepower 1010 devices may blackhole some egress traffic. The hashing is based on source/destination IP address so the behavior will be consistent for a given source/destination IP pair. That is, some traffic consistently works and some consistently fails.

This issue is fixed in Version 6.4.0.6 and Version 6.5.0.

TLS Crypto Acceleration Enabled/Cannot Disable

Deployments: Firepower 2100 series, Firepower 4100/9300 chassis

Upgrading from: Version 6.1.0 through 6.3.x

Directly to: Version 6.4.0+

SSL hardware acceleration has been renamed TLS crypto acceleration.

Depending on the device, TLS crypto acceleration might be performed in software or in hardware. The upgrade automatically enables acceleration on all eligible devices, even if you previously disabled the feature manually. In most cases you cannot configure this feature; it is automatically enabled and you cannot disable it.

Upgrading to Version 6.4.0: If you are using the multi-instance capability of the Firepower 4100/9300 chassis, you can use the FXOS CLI to enable TLS crypto acceleration for one container instance per module/security engine. Acceleration is disabled for other container instances, but enabled for native instances.

Upgrading to Version 6.5.0+: If you are using the multi-instance capability of the Firepower 4100/9300 chassis, you can use the FXOS CLI to enable TLS crypto acceleration for multiple container instances (up to 16) on a Firepower 4100/9300 chassis. New instances have this feature enabled by default. However, the upgrade does not enable acceleration on existing instances. Instead, use the config hwCrypto enable CLI command.

Upgrade Failure: NGIPS Devices Previously at Version 6.2.3.12

Deployments: 7000/8000 series, ASA FirePOWER, NGIPSv

Related bug: CSCvp42398

Upgrading from: Version 6.2.3 through 6.3.0.x

Directly to: Version 6.4.0 only

You cannot upgrade an NGIPS device to Version 6.4.0 if:

  • The device previously ran Version 6.2.3.12, and then

  • You uninstalled the Version 6.2.3.12 patch, or upgraded to Version 6.3.0.x.

    This also includes scenarios where you uninstalled the Version 6.2.3.12 patch and then upgraded to Version 6.3.0.x.

If this is your current situation, contact Cisco TAC.

Upgrade Failure: Insufficient Disk Space on Container Instances

Deployments: Firepower 4100/9300 with FTD

Upgrading from: Version 6.3.0 through 6.4.0.x

Directly to: Version 6.3.0.1 through Version 6.5.0

Most often during major upgrades — but possible while patching — FTD devices configured with container instances can fail in the precheck stage with an erroneous insufficient-disk-space warning.

If this happens to you, you can try to free up more disk space. If that does not work, contact Cisco TAC.

Renamed Upgrade and Installation Packages

Deployments: FMC, 7000/8000 series, NGIPSv

Upgrading from: Version 6.1.0 through 6.2.3.x

Directly to: Version 6.3+

The naming scheme (that is, the first part of the name) for upgrade, patch, hotfix, and installation packages changed starting with Version 6.3.0, on select platforms.


Note
This change causes issues with reimaging older physical appliances: DC750, 1500, 2000, 3500, and 4000, as well as 7000/8000 series devices and AMP models. If you are currently running Version 5.x and need to freshly install Version 6.3.0 or 6.4.0 on one of these appliances, rename the installation package to the "old" name after you download it from the Cisco Support & Download site.
Table 5. Naming Schemes: Upgrade, Patch, and Hotfix Packages
Platform Naming Schemes

FMC

New: Cisco_Firepower_Mgmt_Center

Old: Sourcefire_3D_Defense_Center_S3

Firepower 7000/8000 series

New: Cisco_Firepower_NGIPS_Appliance

Old: Sourcefire_3D_Device_S3

NGIPSv

New: Cisco_Firepower_NGIPS_Virtual

Old: Sourcefire_3D_Device_VMware

Old: Sourcefire_3D_Device_Virtual64_VMware

Table 6. Naming Schemes: Installation Packages
Platform Naming Schemes

FMC (physical)

New: Cisco_Firepower_Mgmt_Center

Old: Sourcefire_Defense_Center_M4

Old: Sourcefire_Defense_Center_S3

FMCv: VMware

New: Cisco_Firepower_Mgmt_Center_Virtual_VMware

Old: Cisco_Firepower_Management_Center_Virtual_VMware

FMCv: KVM

New: Cisco_Firepower_Mgmt_Center_Virtual_KVM

Old: Cisco_Firepower_Management_Center_Virtual

Firepower 7000/8000 series

New: Cisco_Firepower_NGIPS_Appliance

Old: Sourcefire_3D_Device_S3

NGIPSv

New: Cisco_Firepower_NGIPSv_VMware

Old: Cisco_Firepower_NGIPS_VMware

Readiness Check May Fail on FMC, 7000/8000 Series, NGIPSv

Deployments: FMC, 7000/8000 series devices, NGIPSv

Upgrading from: Version 6.1.0 through 6.1.0.6, Version 6.2.0 through 6.2.0.6, Version 6.2.1, Version 6.2.2 through 6.2.2.4, and Version 6.2.3 through 6.2.3.4

Directly to: Version 6.3.0+

You cannot run the readiness check on the listed models when upgrading from one of the listed Firepower versions. This occurs because the readiness check process is incompatible with newer upgrade packages.

Table 7. Patches with Readiness Checks for Version 6.3.0+
Readiness Check Not Supported First Patch with Fix

6.1.0 through 6.1.0.6

6.1.0.7

6.2.0 through 6.2.0.6

6.2.0.7

6.2.1

None. Upgrade to Version 6.2.3.5+.

6.2.2 through 6.2.2.4

6.2.2.5

6.2.3 through 6.2.3.4

6.2.3.5

RA VPN Default Setting Change Can Block VPN Traffic

Deployments: Firepower Threat Defense configured for remote access VPN

Upgrading from: Version 6.2.x

Directly to: Version 6.3+

Version 6.3 changes the default setting for a hidden option, sysopt connection permit-vpn . Upgrading can cause your remote access VPN to stop passing traffic. If this happens, use either of these techniques:

  • Create a FlexConfig object that configures the sysopt connection permit-vpn command. The new default for this command is no sysopt connection permit-vpn .

    This is the more secure method to allow traffic in the VPN, because external users cannot spoof IP addresses in the remote access VPN address pool. The downside is that the VPN traffic will not be inspected, which means that intrusion and file protection, URL filtering, or other advanced features will not be applied to the traffic.

  • Create access control rules to allow connections from the remote access VPN address pool.

    This method ensures that VPN traffic is inspected and advanced services can be applied to the connections. The downside is that it opens the possibility for external users to spoof IP addresses and thus gain access to your internal network.

Security Intelligence Enables Application Identification

Deployments: Firepower Management Center

Upgrading from: Version 6.1 through 6.2.3.x

Directly to: Version 6.3+

In Version 6.3, Security Intelligence configurations enable application detection and identification. If you disabled discovery in your current deployment, the upgrade process may enable it again. Disabling discovery if you don't need it (for example, in an IPS-only deployment) can improve performance.

To disable discovery you must:

  • Delete all rules from your network discovery policy.

  • Use only simple network-based conditions to perform access control: zone, IP address, VLAN tag, and port. Do not perform any kind of application, user, URL, or geolocation control.

  • (NEW) Disable network and URL-based Security Intelligence by deleting all whitelists and blacklists from your access control policy's Security Intelligence configuration, including the default Global lists.

  • (NEW) Disable DNS-based Security Intelligence by deleting or disabling all rules in the associated DNS policy, including the default Global Whitelist for DNS and Global Blacklist for DNS rules.

Update VDB after Upgrade to Enable CIP Detection

Deployments: Any

Upgrading from: Version 6.1.0 through 6.2.3.x, with VDB 299+

Directly to: Version 6.3.0+

If you upgrade while using vulnerability database (VDB) 299 or later, an issue with the upgrade process prevents you from using CIP detection post-upgrade. This includes every VDB released from June 2018 to now, even the latest VDB.

Although we always recommend you update the vulnerability database (VDB) to the latest version after you upgrade, it is especially important in this case.

To check if you are affected by this issue, try to configure an access control rule with a CIP-based application condition. If you cannot find any CIP applications in the rule editor, manually update the VDB.

Invalid Intrusion Variable Sets Can Cause Deploy Failure

Deployments: Any

Upgrading from: Version 6.1 through 6.2.3.x

Directly to: Version 6.3.0+

For network variables in an intrusion variable set, any IP addresses you exclude must be a subset of the IP addresses you include. This table shows you examples of valid and invalid configurations.

Valid Invalid

Include: 10.0.0.0/8

Exclude: 10.1.0.0/16

Include: 10.1.0.0/16

Exclude: 172.16.0.0/12

Exclude: 10.0.0.0/8

Before Version 6.3.0, you could successfully save a network variable with this type of invalid configuration. Now, these configurations block deploy with the error: Variable set has invalid excluded values.

If this happens, identify and edit the incorrectly configured variable set, then redeploy. Note that you may have to edit network objects and groups referenced by your variable set.

Remove Site IDs from Version 6.1.x Firepower Threat Defense Clusters Before Upgrade

Deployments: Firepower Threat Defense clusters

Upgrading from: Version 6.1.x

Directly to: Version 6.2.3 through 6.4.0

Firepower Threat Defense Version 6.1.x clusters do not support inter-site clustering (you can configure inter-site features using FlexConfig starting in Version 6.2.0).

If you deployed or redeployed a Version 6.1.x cluster in FXOS 2.1.1, and you entered a value for the (unsupported) site ID, remove the site ID (set to 0) on each unit in FXOS before you upgrade. Otherwise, the units cannot rejoin the cluster after the upgrade.

If you already upgraded, remove the site ID from each unit, then reestablish the cluster. To view or change the site ID, see the Cisco FXOS CLI Configuration Guide.

Upgrade Can Unregister FDM from CSSM

Deployments: FTD with FDM

Upgrading from: Version 6.2 through 6.2.2.x

Directly to: Version 6.2.3 through 6.4.0


Note

Upgrades from 6.2.3 and 6.2.3.1 directly to 6.2.3.2 through 6.2.3.5 are also affected.

Upgrading FTD with FDM may unregister the device from the Cisco Smart Software Manager. After the upgrade completes, check your license status.

Procedure

Step 1

Click Device, then click View Configuration in the Smart License summary.

Step 2

If the device is not registered, click Register Device.

Upgrade Failure: FDM on ASA 5500-X Series from Version 6.2.0

Deployments: FTD with FDM, running on a lower-memory ASA 5500-X series device

Upgrading from: Version 6.2.0

Directly to: Version 6.2.2 through 6.4.0

If you are upgrading from Version 6.2.0, the upgrade may fail with an error of: Uploaded file is not a valid system upgrade file. This can occur even if you are using the correct file.

If this happens, you can try the following workarounds:

  • Try again.

  • Use the CLI to upgrade.

  • Upgrade to 6.2.0.1 first.

Access Control Can Get Latency-Based Performance Settings from SRUs

Deployments: FMC

Upgrading from: 6.1.x

Directly to: 6.2.0+

New access control policies in Version 6.2.0+ by default get their latency-based performance settings from the latest intrusion rule update (SRU). This behavior is controlled by a new Apply Settings From option. To configure this option, edit or create an access control policy, click Advanced, and edit the Latency-Based Performance Settings.

When you upgrade to Version 6.2.0+, the new option is set according to your current (Version 6.1.x) configuration. If your current settings are:

  • Default: The new option is set to Installed Rule Update. When you deploy after the upgrade, the system uses the latency-based performance settings from the latest SRU. It is possible that traffic handling could change, depending on what the latest SRU specifies.

  • Custom: The new option is set to Custom. The system retains its current performance settings. There should be no behavior change due to this option.

We recommend you review your configurations before you upgrade. From the Version 6.1.x FMC web interface, view your policies' Latency-Based Performance Settings as described earlier, and see whether the Revert to Defaults button is dimmed. If the button is dimmed, you are using the default settings. If it is active, you have configured custom settings.

'Snort Fail Open' Replaces 'Failsafe' on FTD

Deployments: FTD with FMC

Upgrading from: Version 6.1.x

Directly to: Version 6.2+

In Version 6.2, the Snort Fail Open configuration replaces the Failsafe option on FMC-managed Firepower Threat Defense devices. While Failsafe allows you to drop traffic when Snort is busy, traffic automatically passes without inspection when Snort is down. Snort Fail Open allows you to drop this traffic.

When you upgrade an FTD device, its new Snort Fail Open setting depends on its old Failsafe setting, as follows. Although the new configuration should not change traffic handling, we still recommend that you consider whether to enable or disable Failsafe before you upgrade.

Table 8. Migrating Failsafe to Snort Fail Open
Version 6.1 Failsafe Version 6.2 Snort Fail Open Behavior

Disabled (default behavior)

Busy: Disabled

Down: Enabled

New and existing connections drop when the Snort process is busy and pass without inspection when the Snort process is down.

Enabled

Busy: Enabled

Down: Enabled

New and existing connections pass without inspection when the Snort process is busy or down.

Note that Snort Fail Open requires Version 6.2 on the device. If you are managing a Version 6.1.x device, the FMC web interface displays the Failsafe option.

Upgrade Guidelines for the Firepower 4100/9300 Chassis

For the Firepower 4100/9300, major FTD upgrades also require a chassis upgrade (FXOS and firmware). Maintenance release and patches rarely require this, but you may still want to upgrade to the latest build to take advantage of resolved issues.

Table 9. Upgrade Guidelines for the Firepower 4100/9300 Chassis

Guideline

Details

FXOS upgrades.

FXOS 2.6.1.157+ is required to run threat defense Version 6.4 on the Firepower 4100/9300.

You can upgrade to any later FXOS version from as far back as FXOS 2.2.2. For critical and release-specific upgrade guidelines, new and deprecated features, and open and resolved bugs, see the Cisco Firepower 4100/9300 FXOS Release Notes.

Firmware upgrades.

FXOS 2.14.1+ upgrades include firmware. If you are upgrading to an earlier FXOS version, see the Cisco Firepower 4100/9300 FXOS Firmware Upgrade Guide.

Time to upgrade.

Chassis upgrade can take up to 45 minutes and can affect traffic flow and inspection. For more information, see Traffic Flow and Inspection for Chassis Upgrades.

Unresponsive Upgrades

Do not make or deploy configuration changes during upgrade. Even if the system appears inactive, do not manually reboot or shut down during upgrade. You could place the system in an unusable state and require a reimage. If you encounter issues with the upgrade, including a failed upgrade or unresponsive appliance, contact Cisco TAC.

Uninstall a Patch

In FMC and ASDM deployments, you can uninstall most patches. If you need to return to an earlier major release, you must reimage. For guidelines, limitations, and procedures, see Uninstall a Patch in the FMC upgrade guide or Uninstall ASA FirePOWER Patches with ASDM in these release notes.

Patches That Support Uninstall

Uninstalling specific patches can cause issues, even when the uninstall itself succeeds. These issues include:

  • Inability to deploy configuration changes after uninstall.

  • Incompatibilities between the operating system and the software.

  • FSIC (file system integrity check) failure when the appliance reboots, if you patched with security certifications compliance enabled (CC/UCAPL mode).


Caution

If security certifications compliance is enabled and the FSIC fails, the software does not start, remote SSH access is disabled, and you can access the appliance only via local console. If this happens, contact Cisco TAC.

Version 6.4 Patches That Support Uninstall

This table lists supported uninstall scenarios for Version 6.4 patches. Uninstalling returns you to the patch level you upgraded from. If uninstall will take you farther back than what is supported, we recommend you reimage and then upgrade to your desired patch level.

Table 10. Version 6.4.0 Patches That Support Uninstall

Current Version

Farthest Back You Should Uninstall

FTD/FTDv

Firepower 7000/8000

ASA FirePOWER

NGIPSv

FMC/FMCv

6.4.0.5+

6.4.0.4

6.4.0.4

6.4.0.4

6.4.0.4

—

—

—

6.4.0.3

6.4.0

—

—

6.4.0.2

6.4.0

—

—

6.4.0.1

6.4.0

6.4.0

6.4.0

Uninstall ASA FirePOWER Patches with ASDM

Use the Linux shell (expert mode) to uninstall device patches. You must have access to the device shell as the admin user for the device, or as another local user with CLI configuration access. If you disabled shell access, contact Cisco TAC to reverse the lockdown.

For ASA failover pairs and clusters, minimize disruption by uninstalling from one appliance at a time. Wait until the patch has fully uninstalled from one unit before you move on to the next.

Table 11. Uninstall Order for ASA with FirePOWER Services in ASA Failover Pairs/Clusters

Configuration

Uninstall Order

ASA active/standby failover pair, with ASA FirePOWER

Always uninstall from the standby.

  1. Uninstall from the ASA FirePOWER module on the standby ASA device.

  2. Fail over.

  3. Uninstall from the ASA FirePOWER module on the new standby ASA device.

ASA active/active failover pair, with ASA FirePOWER

Make both failover groups active on the unit you are not uninstalling.

  1. Make both failover groups active on the primary ASA device.

  2. Uninstall from the ASA FirePOWER module on the secondary ASA device.

  3. Make both failover groups active on the secondary ASA device.

  4. Uninstall from the ASA FirePOWER module on the primary ASA device.

ASA cluster, with ASA FirePOWER

Disable clustering on each unit before you uninstall. Uninstall from one unit at a time, leaving the control unit for last.

  1. On a data unit, disable clustering.

  2. Uninstall from the ASA FirePOWER module on that unit.

  3. Reenable clustering. Wait for the unit to rejoin the cluster.

  4. Repeat for each data unit.

  5. On the control unit, disable clustering. Wait for a new control unit to take over.

  6. Uninstall from the ASA FirePOWER module on the former control unit.

  7. Reenable clustering.

Caution

Do not make or deploy configuration changes during uninstall. Even if the system appears inactive, do not manually reboot, shut down, or restart an uninstall in progress. You could place the system in an unusable state and require a reimage. If you encounter issues with the uninstall, including a failed uninstall or unresponsive appliance, contact Cisco TAC.

Before you begin

  • In ASA failover/cluster deployments, make sure you are uninstalling from the correct device.

  • Make sure your deployment is healthy and successfully communicating.

Procedure

Step 1

If the device's configurations are out of date, deploy now from ASDM.

Deploying before you uninstall reduces the chance of failure. Make sure the deployment and other essential tasks are completed. Tasks running when the uninstall begins are stopped, become failed tasks, and cannot be resumed. You can manually delete failed status messages later.

Step 2

Access the Firepower CLI on the ASA FirePOWER module. Log in as admin or another Firepower CLI user with configuration access.

You can either SSH to the module's management interface (hostname or IP address) or use the console. Note that the console port defaults to the ASA CLI and you must use the session sfr command to access the Firepower CLI.

Step 3

Use the expert command to access the Linux shell.

Step 4

Verify the uninstall package is in the upgrade directory.

ls /var/sf/updates

Patch uninstallers are named like upgrade packages, but have Patch_Uninstaller instead of Patch in the file name. When you patch a device, the uninstaller for that patch is automatically created in the upgrade directory. If the uninstaller is not there, contact Cisco TAC.

Step 5

Run the uninstall command, entering your password when prompted.

sudo install_update.pl --detach /var/sf/updates/uninstaller_name

Caution

 

The system does not ask you to confirm. Entering this command starts the uninstall, which includes a device reboot. Interruptions in traffic flow and inspection during an uninstall are the same as the interruptions that occur during an upgrade. Make sure you are ready. Note that using the --detach option ensures the uninstall process is not killed if your SSH session times out, which can leave the device in an unstable state.

Step 6

Monitor the uninstall until you are logged out.

For a detached uninstall, use tail or tailf to display logs:

tail /ngfw/var/log/sf/update.status

Otherwise, monitor progress in the console or terminal.

Step 7

Verify uninstall success.

After the uninstall completes, confirm that the module has the correct software version. Choose Configuration > ASA FirePOWER Configurations > Device Management > Device.

Step 8

Redeploy configurations.

What to do next

In ASA failover/cluster deployments, repeat this procedure for each unit in your planned sequence.

Traffic Flow and Inspection

Device upgrades (software and operating system) affect traffic flow and inspection. Schedule maintenance windows when this will have the least impact.

Traffic Flow and Inspection for Chassis Upgrades

Upgrading FXOS reboots the chassis. For FXOS upgrades to Version 2.14.1+ that include firmware upgrades, the device reboots twice—once for FXOS and once for the firmware.

Even in high availability/clustered deployments, you upgrade FXOS on each chassis independently. To minimize disruption, upgrade one chassis at a time.

Table 12. Traffic Flow and Inspection: FXOS Upgrades

FTD Deployment

Traffic Behavior

Method

Standalone

Dropped.

—

High availability

Unaffected.

Best Practice: Update FXOS on the standby, switch active peers, upgrade the new standby.

Dropped until one peer is online.

Upgrade FXOS on the active peer before the standby is finished upgrading.

Inter-chassis cluster

Unaffected.

Best Practice: Upgrade one chassis at a time so at least one module is always online.

Dropped until at least one module is online.

Upgrade chassis at the same time, so all modules are down at some point.

Intra-chassis cluster (Firepower 9300 only)

Passed without inspection.

Hardware bypass enabled: Bypass: Standby or Bypass‑Force.

Dropped until at least one module is online.

Hardware bypass disabled: Bypass: Disabled.

Dropped until at least one module is online.

No hardware bypass module.

Traffic Flow and Inspection for FTD Upgrades with FMC

Software Upgrades for Standalone Devices

Devices operate in maintenance mode while they upgrade. Entering maintenance mode at the beginning of the upgrade causes a 2-3 second interruption in traffic inspection. Interface configurations determine how a standalone device handles traffic both then and during the upgrade.

Table 13. Traffic Flow and Inspection: Software Upgrades for Standalone Devices

Interface Configuration

Traffic Behavior

Firewall interfaces

Routed or switched including EtherChannel, redundant, subinterfaces.

Switched interfaces are also known as bridge group or transparent interfaces.

Dropped.

For bridge group interfaces on the ISA 3000 only, you can use a FlexConfig policy to configure hardware bypass for power failure. This causes traffic to drop during software upgrades but pass without inspection while the device completes its post-upgrade reboot.

IPS-only interfaces

Inline set, hardware bypass force-enabled: Bypass: Force

Passed without inspection until you either disable hardware bypass, or set it back to standby mode.

Inline set, hardware bypass standby mode: Bypass: Standby

Dropped during the upgrade, while the device is in maintenance mode. Then, passed without inspection while the device completes its post-upgrade reboot.

Inline set, hardware bypass disabled: Bypass: Disabled

Dropped.

Inline set, no hardware bypass module.

Dropped.

Inline set, tap mode.

Egress packet immediately, copy not inspected.

Passive, ERSPAN passive.

Uninterrupted, not inspected.

Software Upgrades for High Availability/Scalability

You should not experience interruptions in traffic flow or inspection while upgrading high availability or clustered devices. For high availability pairs, the standby device upgrades first. The devices switch roles, then the new standby upgrades.

For clusters, the data security module or modules upgrade first, then the control module. During the control security module upgrade, although traffic inspection and handling continues normally, the system stops logging events. Events for traffic processed during the logging downtime appear with out-of-sync timestamps after the upgrade is completed. However, if the logging downtime is significant, the system may prune the oldest events before they can be logged.


Note

Upgrading an inter-chassis cluster from Version 6.2.0, 6.2.0.1, or 6.2.0.2 causes a 2-3 second traffic interruption in traffic inspection when each module is removed from the cluster. Upgrading high availability or clustered devices from Version 6.0.1 through 6.2.2.x may have additional upgrade path requirements; see the upgrade path information in the planning chapter of the Cisco Firepower Management Center Upgrade Guide, Version 6.0–7.0.

Software Uninstall (Patches)

For standalone devices, interruptions to traffic flow and inspection during patch uninstall are the same as for upgrade. In high availability/scalability deployments, you must explicitly plan an uninstall order that minimizes disruption. This is because you uninstall patches from devices individually, even those that you upgraded as a unit.

Deploying Configuration Changes

Restarting the Snort process briefly interrupts traffic flow and inspection on all devices, including those configured for high availability/scalability. Interface configurations determine whether traffic drops or passes without inspection during the interruption. When you deploy without restarting Snort, resource demands may result in a small number of packets dropping without inspection.

Snort typically restarts during the first deployment immediately after the upgrade. It does not restart during other deployments unless, before deploying, you modify specific policy or device configurations.

Table 14. Traffic Flow and Inspection: Deploying Configuration Changes

Interface Configuration

Traffic Behavior

Firewall interfaces

Routed or switched including EtherChannel, redundant, subinterfaces.

Switched interfaces are also known as bridge group or transparent interfaces.

Dropped.

IPS-only interfaces

Inline set, Failsafe enabled or disabled.

Passed without inspection.

A few packets might drop if Failsafe is disabled and Snort is busy but not down.

Inline set, Snort Fail Open: Down: disabled.

Dropped.

Inline set, Snort Fail Open: Down: enabled.

Passed without inspection.

Inline set, tap mode.

Egress packet immediately, copy not inspected.

Passive, ERSPAN passive.

Uninterrupted, not inspected.

Traffic Flow and Inspection for FTD Upgrades with FDM

Software Upgrades

Traffic is dropped while you upgrade. In a high availability deployment, you can minimize disruption by upgrading devices one at a time.

For the ISA 3000 only, if you configured hardware bypass for power failure, traffic is dropped during the upgrade but is passed without inspection while the device completes its post-upgrade reboot.

Deploying Configuration Changes

Restarting the Snort process briefly interrupts traffic flow and inspection on all devices, including those configured for high availability. When you deploy without restarting Snort, resource demands may result in a small number of packets dropping without inspection.

Snort typically restarts during the first deployment immediately after the upgrade. It does not restart during other deployments unless, before deploying, you modify specific policy or device configurations.

Traffic Flow and Inspection for ASA FirePOWER Upgrades

Software Upgrades

Your ASA service policies for redirecting traffic to the ASA FirePOWER module determine how the module handles traffic during software upgrade.

Table 15. Traffic Flow and Inspection: ASA FirePOWER Upgrades

Traffic Redirection Policy

Traffic Behavior

Fail open (sfr fail-open )

Passed without inspection

Fail closed (sfr fail-close )

Dropped

Monitor only (sfr {fail-close}|{fail-open} monitor-only )

Egress packet immediately, copy not inspected

Software Uninstall (Patches)

Interruptions to traffic flow and inspection during patch uninstall are the same as for upgrade. In ASA failover/cluster deployments, you must explicitly plan an uninstall order that minimizes disruption. This is because you uninstall patches from devices individually, even those that you upgraded as a unit.

Deploying Configuration Changes

Restarting the Snort process briefly interrupts traffic flow and inspection. Traffic behavior while the Snort process restarts is the same as when you upgrade ASA FirePOWER. When you deploy without restarting Snort, resource demands may result in a small number of packets dropping without inspection.

Snort typically restarts during the first deployment immediately after the upgrade. It does not restart during other deployments unless, before deploying, you modify specific policy or device configurations.

Traffic Flow and Inspection for NGIPSv Upgrades with FMC

Software Upgrades

Interface configurations determine how NGIPSv handles traffic during the upgrade.

Table 16. Traffic Flow and Inspection: NGIPSv Upgrades

Interface Configuration

Traffic Behavior

Inline

Dropped.

Inline, tap mode

Egress packet immediately, copy not inspected.

Passive

Uninterrupted, not inspected.

Software Uninstall (Patches)

Interruptions to traffic flow and inspection during patch uninstall are the same as for upgrade.

Deploying Configuration Changes

Restarting the Snort process briefly interrupts traffic flow and inspection. Interface configurations determine whether traffic drops or passes without inspection during the interruption. When you deploy without restarting Snort, resource demands may result in a small number of packets dropping without inspection.

Snort typically restarts during the first deployment immediately after the upgrade. It does not restart during other deployments unless, before deploying, you modify specific policy or device configurations.

Table 17. Traffic Flow and Inspection: Deploying Configuration Changes

Interface Configuration

Traffic Behavior

Inline, Failsafe enabled or disabled

Passed without inspection.

A few packets might drop if Failsafe is disabled and Snort is busy but not down.

Inline, tap mode

Egress packet immediately, copy bypasses Snort

Passive

Uninterrupted, not inspected.

Time and Disk Space

Time to Upgrade

We recommend you track and record your own upgrade times so you can use them as future benchmarks. The following table lists some things that can affect upgrade time.


Caution

Do not make or deploy configuration changes during upgrade. Even if the system appears inactive, do not manually reboot or shut down. In most cases, do not restart an upgrade in progress. You could place the system in an unusable state and require a reimage. If you encounter issues with the upgrade, including a failed upgrade or unresponsive appliance, you can find troubleshooting information in the upgrade guide: https://www.cisco.com/go/ftd-upgrade. If you continue to have issues, contact Cisco TAC.

Table 18. Upgrade Time Considerations

Consideration

Details

Versions

Upgrade time usually increases if your upgrade skips versions.

Models

Upgrade time usually increases with lower-end models.

Virtual appliances

Upgrade time in virtual deployments is highly hardware dependent.

High availability and clustering

In a high availability or clustered configuration, devices upgrade one at a time to preserve continuity of operations, with each device operating in maintenance mode while it upgrades. Upgrading a device pair or entire cluster, therefore, takes longer than upgrading a standalone device.

Configurations

Upgrade time can increase with the complexity of your configurations, size of event databases, and whether/how they are affected by the upgrade. For example, if you use a lot of access control rules and the upgrade needs to make a backend change to how those rules are stored, the upgrade can take longer.

Components

You may need additional time to perform operating system or virtual hosting upgrades, upgrade package transfers, readiness checks, VDB and intrusion rule (SRU/LSP) updates, configuration deployment, and other related tasks.

Disk Space to Upgrade

To upgrade, the upgrade package must be on the appliance. For device upgrades with management center, you must also have enough space on the management center (in either /Volume or /var) for the device upgrade package. Or, you can use an internal server to store them. Readiness checks should indicate whether you have enough disk space to perform the upgrade. Without enough free disk space, the upgrade fails.

Table 19. Checking Disk Space

Platform

Command

Management center

Choose System (system gear icon) > Monitoring > Statistics and select the FMC.

Under Disk Usage, expand the By Partition details.

Threat defense with management center

Choose System (system gear icon) > Monitoring > Statistics and select the device you want to check.

Under Disk Usage, expand the By Partition details.

Threat defense with device manager

Use the show disk CLI command.