Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco Firepower Release Notes, Version 6.3.0

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco Firepower Release Notes, Version 6.3.0

Chapter Title

Upgrade to Version 6.3.0

Results

Updated:
September 22, 2019

Chapter: Upgrade to Version 6.3.0

Upgrade to Version 6.3.0

This chapter provides critical and release-specific information for Version 6.3.0.

You should also read Features and Functionality for information on any new features and functionality, deprecated features and platforms, menu and terminology changes, blacklisted FlexConfig commands, and so on.

Guidelines and Warnings for Version 6.3.0

This checklist contains important upgrade guidelines and warnings that are new for Version 6.3.0.

Table 1. Version 6.3.0 New Guidelines
✓ Guideline Platforms Upgrading From Directly To

Reimaging to Version 6.3+ Disables LOM on Most Appliances

FMC (physical)

Firepower 7000/8000 series

Any

6.3.0+

Firepower 4100/9300 Requires FTD Push Before FXOS Upgrade

Firepower 4100/9300

6.1.x

6.3.0 only

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.0+

Renamed Upgrade and Installation Packages

FMC

Firepower 7000/8000 series

NGIPSv

6.1.0 through 6.2.3.x

6.3.0+

Updated Security for Appliance Access

Any

6.1.0 through 6.2.3.x

6.3.0+

Security Intelligence Enables Application Identification

FMC deployments

6.1.0 through 6.2.3.x

6.3.0+

Update VDB after Upgrade to Enable CIP Detection

Any

6.1.0 through 6.2.3.x

6.3.0+

Invalid Intrusion Variable Sets Can Cause Deploy Failure

Any

6.1.0 through 6.2.3.x

6.3.0+

Syslog Behavior Changes for Connection and Intrusion Events

FMC

6.1.0 through 6.2.3.x

6.3.0+

Version 6.3.0-83 Upgrades to FMC and ASA FirePOWER May Fail

FMC

ASA FirePOWER with ASDM

6.1.0 through 6.2.3.x

6.3.0 only

TLS/SSL Hardware Acceleration Enabled on Upgrade

Firepower 2100 series

Firepower 4100/9300

6.1.0 through 6.2.3.x

6.3.0 only

Timeouts for the URL Filtering Cache Can Change

Any

6.2.3.x

6.3.0+

MC1000/2500/4500 FMCs May Require Pre-Upgrade Hotfix

MC1000, 2500, and 4500

6.2.0 through 6.2.3.7

6.3.0+

RA VPN Default Setting Change Can Block VPN Traffic

FTD with FMC

6.2.x

6.3.0+

Reporting Data Removed During FTD/FDM Upgrade

FTD with FDM

6.2.x

6.3.0 only

MC1000/2500/4500 FMCs May Require Pre-Upgrade Hotfix

Deployments: Firepower Management Center models MC1000, 2500, and 4500

Upgrading from: Version 6.2.0 through 6.2.3.7

Directly to: Version 6.3.0+

You may need to apply a preinstallation hotfix before you upgrade an MC1000, MC2500, or MC4500 to Version 6.3.0+ from Version 6.2.0 through 6.2.3.7. Alternately, you can upgrade to Version 6.2.3.8+. Do not apply the hotfix to other FMC models or versions.

The hotfix (or patch) updates the firmware for the RAID controller to Version 24.12.1-0411. Without the firmware update, upgraded FMCs running Version 6.3.0+ can experience performance issues.


Note

In some cases, even if you are running an affected version, your firmware may already be up to date. In that situation, the hotfix fails with an error of: The image file has older version than or same as that on the controller. The controller is not flashed. If you see this message, you can safely upgrade without the hotfix.

The hotfix is available on the Cisco Support & Download site, in the same location as the upgrade and installation packages for your current major version. Use the regular upgrade page (System > Updates) to apply the hotfix.

Table 2. Preinstallation Hotfix Packages
Current Version Hotfix Package

6.3.0+

—

Contact Cisco TAC if you upgraded to 6.3.0+ without hotfixing or patching.

6.2.3.8 or later patch

—

Upgrade normally. No hotfix needed.

6.2.3 through 6.2.3.7

Hotfix AJ

Sourcefire_3D_Defense_Center_S3_Hotfix_AJ-6.2.3.999-5.sh.REL.tar

6.2.2.x

Hotfix BY

Sourcefire_3D_Defense_Center_S3_Hotfix_BY-6.2.2.999-1.sh.REL.tar

6.2.1

—

Upgrade to Version 6.2.3 and either apply Hotfix AJ or patch to 6.2.3.8+.

6.2.0.x

—

Upgrade to Version 6.2.3 and either apply Hotfix AJ or patch to 6.2.3.8+.

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 3. 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

Updated Security for Appliance Access

Deployments: Any

Upgrading from: Version 6.1 through 6.2.3.x

Directly to: Version 6.3+

To enhance security, in Version 6.3 we updated the list of supported ciphers and cryptographic algorithms for secure SSH access. If your SSH client fails to connect with a Firepower appliance due to a cipher error, update your client to the latest version.

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 through 6.2.x, with VDB 299+

Directly to: Version 6.3+

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.

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.

Timeouts for the URL Filtering Cache Can Change

Deployments: Any

Upgrading from: Version 6.2.3.x

Directly to: Version 6.3.0+

New for Version 6.3.0, the GUI allows you configure a timeout value for the URL filtering cache. To minimize instances of URLs matching on stale data, you can set URLs in the cache to expire. If you worked with Cisco TAC to specify a timeout value for the URL filtering cache, the upgrade may change that value.

After the upgrade completes:

  • FMC: Choose System > Integration, click the Cisco CSI tab, and evaluate the Cached URLs Expire setting.

  • FDM: Choose System Settings > Traffic Settings > URL Filtering Preferences and evaluate the URL Time to Live setting.

Syslog Behavior Changes for Connection and Intrusion Events

Deployments: Firepower Management Center

Upgrading from: Version 6.1.0 through 6.2.3.x

Directly to: Version 6.3.0+

Version 6.3.0 changes and centralizes the way the system logs connection and intrusion events via syslog. You can access these settings on the new Logging tab in the access control policy.

The upgrade does not change your existing settings for connection event logging. However, you may suddenly start receiving intrusion events you did not "expect" via syslog. This is because after you upgrade to Version 6.3.0+, the intrusion policy sends syslog events to the destination on the new Logging tab. (Before Version 6.3.0, you could configure syslog alerting in an intrusion policy to send events to the syslog on the managed device itself rather than to an external host.)

Also, messages sent from NGIPS devices (7000/8000 series, ASA FirePOWER, NGIPSv) now use the ISO 8601 timestamp format as specified in RFC 5425.

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 4. 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 5. 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

Firepower 4100/9300 Requires FTD Push Before FXOS Upgrade

Deployments: Firepower 4100/9300 with FTD

Upgrading from: Version 6.1.x on FXOS 2.0.1, 2.1.1, or 2.3.1

Directly to: Version 6.3.0 on FXOS 2.4.1

If your Firepower Management Center is running Version 6.2.3+, we strongly recommend you push (copy) Firepower upgrade packages to managed devices before you upgrade. This helps reduce the length of your upgrade maintenance window.

For Firepower 4100/9300 with FTD, best practice is to push before you begin the required companion FXOS upgrade. And, if you are upgrading from Version 6.1 directly to Version 6.3, this push is required. You must push before you upgrade FXOS.

This is because upgrading FXOS to Version 2.4.1 while still running Firepower 6.1 causes the device management port to flap, which in turn causes intermittent communication problems between the device and the FMC. You may see 'sftunnel daemon exited' alarms, and any task that involves sustained communications—such as pushing a large upgrade package—may fail.

To upgrade Firepower 4100/9300 with FTD, always follow this sequence:

  1. Upgrade the FMC to the target version.

  2. Obtain the device upgrade package from the Cisco Support & Download site and upload it to the FMC.

  3. Use the FMC to push the upgrade package to the device.

  4. After the push completes, upgrade FXOS to the target version.

  5. Immediately, use the FMC to upgrade the Firepower software on the device.

    Remember, until you upgrade the Firepower software, you may continue to experience management port flaps.

Reporting Data Removed During FTD/FDM Upgrade

Deployments: Firepower Device Manager

Upgrading from: Version 6.2.x

Directly to: Version 6.3 only

Reporting data for short time periods are removed during the Version 6.3 upgrade. After the upgrade, if you try to query short time ranges on days that fall before the upgrade, the system adjusts your query to match the available data. For example, if you query 1-3 PM for a date, and the system only has 24-hour data, the system reports on the entire day.

TLS/SSL Hardware Acceleration Enabled on Upgrade

Deployments: Firepower 2100 series, Firepower 4100/9300 chassis

Upgrading from: Version 6.1.0 through 6.2.3.x

Directly to: Version 6.3.0 only

The upgrade process automatically enables TLS/SSL hardware acceleration (sometimes called TLS crypto acceleration) on eligible devices. When it was introduced in Version 6.2.3, this feature was disabled by default on Firepower 4100/9300 chassis, and was not available on Firepower 2100 series devices.

Using TLS/SSL hardware acceleration on a managed device that is not decrypting traffic can affect performance. In Version 6.3.0.x, we recommend you disable this feature on devices that are not decrypting traffic.

To disable, use this CLI command:

system support ssl-hw-offload disable

Reimaging to Version 6.3+ Disables LOM on Most Appliances

Deployments: Physical FMCs, 7000/8000 series devices

Reimaging from: Version 6.0+

Directly to: Version 6.3+

Freshly installing Version 6.3+ now automatically deletes Lights-Out Management (LOM) settings on most appliances, for security reasons. On a few older FMC models, you have the option of retaining LOM settings along with your management network settings.

If you delete network settings during a Version 6.3+ reimage, you must make sure you have physical access to the appliance to perform the initial configuration. You cannot use LOM. After you perform the initial configuration, you can reenable LOM and LOM users.

Table 6. Reimage Effect on LOM Settings
Platform Reimage to Version 6.2.3 or earlier Reimage to Version 6.3+

MC1600, 2600, 4600

MC1000, 2500, 4500

MC2000, 4000

Never deleted

Always deleted

MC750, 1500, 3500

Deleted if you delete network settings

Deleted if you delete network settings

7000/8000 series

Always deleted

Always deleted

Version 6.3.0-83 Upgrades to FMC and ASA FirePOWER May Fail

Deployments: Firepower Management Center, ASA FirePOWER (locally managed)

Upgrading from: Version 6.1.0 through 6.2.3.x

Directly to: Version 6.3.0-83

Some Firepower Management Centers and locally (ASDM) managed ASA FirePOWER modules experienced upgrade failures with Version 6.3.0, build 83. This issue was limited to a subset of customers who upgraded from Version 5.4.x. For more information, see CSCvn62123 in the Cisco Bug Search Tool.

A new upgrade package is now available. If you downloaded the Version 6.3.0-83 upgrade package, do not use it. If you already experienced an upgrade failure due to this issue, contact Cisco TAC.

Previously Published Guidelines and Warnings

Review this checklist if your upgrade path skips major versions. You can upgrade to Version 6.3.0 from several previous major versions; see Minimum Version to Upgrade.

Table 7. Previously Published Guidelines

✓

Guideline

Platforms

Upgrading From

Directly To

Access Control Can Get Latency-Based Performance Settings from SRUs

FMC

6.1.x

6.2.0+

'Snort Fail Open' Replaces 'Failsafe' on FTD

FTD with FMC

6.1.x

6.2.0+

FDM Upgrades from Version 6.2.0 Can Fail

FTD with FDM

6.2.0 only

6.2.2+

Changes to Result Limits in Reports

FMC

6.1.0 through 6.2.2.x

6.2.3+

Remove Site IDs from Version 6.1.x FTD Clusters Before Upgrade

FTD clusters

6.1.x

6.2.3+

Upgrade Can Unregister FTD/FDM from CSSM

FTD with FDM

6.2.0 through 6.2.2.x

6.2.3+

Remove Site IDs from Version 6.1.x FTD Clusters Before Upgrade

Deployments: Firepower Threat Defense clusters

Upgrading from: Version 6.1.x

Directly to: Version 6.2.3+

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.

Changes to Result Limits in Reports

Deployments: Firepower Management Center

Upgrading from: Version 6.1 through 6.2.2.x

Directly to: Version 6.2.3+

Version 6.2.3 limits the number of results you can use or include in a report section, as follows. For table and detail views, you can include fewer records in a PDF report than in an HTML/CSV report.

Table 8. New Result Limits in Reports
Report Section Type Max Records: HTML/CSV Report Section Max Records: PDF Report Section

Bar chart

Pie chart

100 (top or bottom)

100 (top or bottom)

Table view

400,000

100,000

Detail view

1,000

500

If, before you upgrade a Firepower Management Center, a section in a report template specifies a larger number of results than the HTML/CSV maximum, the upgrade process lowers the setting to the new maximum value.

For report templates that generate PDF reports, if you exceed the PDF limit in any template section, the upgrade process changes the output format to HTML. To continue generating PDFs, lower the results limit to the PDF maximum. If you do this after the upgrade, set the output format back to PDF.

Upgrade Can Unregister FTD/FDM from CSSM

Deployments: FTD with FDM

Upgrading from: Version 6.2 through 6.2.2.x

Directly to: Version 6.2.3+

Upgrading a Firepower Threat Defense device managed by Firepower Device Manager 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.

FDM Upgrades from Version 6.2.0 Can Fail

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+

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+

New access control policies in Version 6.2+ 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+, 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 9. 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.

General Guidelines and Warnings

These important guidelines and warnings apply to every upgrade. However, this list is not comprehensive. For links to additional important information on the upgrade process, which can include planning upgrade paths, OS upgrades, readiness checks, backups, maintenance windows, and so on, see Upgrade Instructions.

Appliance Access

Firepower devices can stop passing traffic during the upgrade (depending on interface configurations), or if the upgrade fails. Before you upgrade a Firepower device, make sure traffic from your location does not have to traverse the device itself to access the device's management interface. In Firepower Management Center deployments, you should also able to access the FMC management interface without traversing the device.

Signed Upgrade Packages

So that Firepower can verify that you are using the correct files, upgrade packages from (and hotfixes to) Version 6.2.1+ are signed tar archives (.tar). Upgrades from earlier versions continue to use unsigned packages.

When you manually download upgrade packages from the Cisco Support & Download site—for example, for a major upgrade or in an air-gapped deployment—make sure you download the correct package. Do not untar signed (.tar) packages.


Note
After you upload a signed upgrade package, the GUI can take several minutes to load as the system verifies the package. To speed up the display, remove signed packages after you no longer need them.

Disable ASA REST API on ASA FirePOWER Devices

Before you upgrade an ASA FirePOWER module, make sure the ASA REST API is disabled. Otherwise, the upgrade could fail. From the ASA CLI: no rest api agent. You can reenable after the uninstall: rest-api agent.

Sharing Data with Cisco During and After Upgrade

Features in Version 6.2.3+ involve sharing data with Cisco.

Cisco Success Network sends usage information and statistics to Cisco, which are essential to provide you with technical support. During upgrades, you may be asked to accept or decline participation. You can also opt in or out at any time.

Web analytics tracking sends non-personally-identifiable usage data to Cisco, including but not limited to page interactions, browser versions, product versions, user location, and management IP addresses or hostnames of your FMCs. If you are upgrading from Version 6.1 through 6.2.2.x, the upgrade enables web analytics tracking. If you do not want Cisco to collect this data, you can opt out after the upgrade. (If you are upgrading from Version 6.2.3.x, the upgrade process respects your current setting.)

Unresponsive Upgrades

Do not deploy changes to or from, manually reboot, or shut down an upgrading appliance. 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, contact Cisco TAC.

Minimum Version to Upgrade

You can upgrade directly to Version 6.3.0 from several previous major version sequences. You do not need to be running the latest patch of any previous version to upgrade.

Table 10. Minimum Version to Upgrade Firepower Software to Version 6.3.0
Platform Minimum Version

Firepower Management Center

All managed devices in FMC deployments except Firepower 4100/9300 series.

6.1.0

Firepower Threat Defense on Firepower 4100/9300 with FMC

6.1.0 with FXOS 2.4.1.214+ (upgrade FXOS first)

If you are upgrading from Version 6.1.x, see Firepower 4100/9300 Requires FTD Push Before FXOS Upgrade.

If you are upgrading a high availability or clustered deployment from Version 6.2.0.x, 6.2.2.0, or 6.2.2.1 and you require a hitless upgrade, see FTD Upgrade Behavior: Firepower 4100/9300 Chassis.

Firepower Threat Defense (all platforms) with FDM

6.2.0

ASA FirePOWER with ASDM

6.2.0

Time Tests and Disk Space Requirements

To upgrade a Firepower appliance, you must have enough free disk space or the upgrade fails. When you use the Firepower Management Center to upgrade a managed device, the FMC requires additional disk space in its /Volume partition, for the device upgrade package. You must also have enough time to perform the upgrade.

We provide reports of in-house time and disk space tests for reference purposes.

About Time Tests

Time values given here are based on in-house tests. Although we report the slowest time of all upgrades tested for a particular platform/series, your upgrade will likely take longer than the provided times for multiple reasons (provided below).

Basic Test Conditions

  • Deployment: Values are from tests in a Firepower Management Center deployment. This is because raw upgrade times for remotely and locally managed devices are similar, given similar conditions.

  • Versions: For major upgrades, we test upgrades from all eligible previous major versions. For patches, we test upgrades from the base version and from the immediately preceding patch.

  • Models: In most cases, we test on the lowest-end models in each series, and sometimes on multiple models in a series.

  • Virtual settings: We test with the default settings for memory and resources.

Push and Reboot Not Included

Values represent only the time it took for the Firepower upgrade script itself to run. Values do not include the time required to upload upgrade packages to a locally managed device or to the FMC, nor the time to copy (push) upgrade packages from the FMC to a managed device.

In FMC deployments, insufficient bandwidth between the FMC and managed devices can extend upgrade time or even cause the upgrade to time out. Make sure you have the bandwidth to perform a large data transfer from the FMC to its devices. For more information, see Guidelines for Downloading Data from the Firepower Management Center to Managed Devices (Troubleshooting TechNote).

Values also do not include reboots, readiness checks, operating system upgrades, or configuration deploys.

Time Is For Single Devices

Values are per device. 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.

Note that stacked 8000 series devices upgrade simultaneously, with the stack operating in limited, mixed-version state until all devices complete the upgrade. This should not take significantly longer than upgrading a standalone device.

Affected Configurations and Data

We test on appliances with minimal configurations and traffic load. Upgrade time can increase with the complexity of your configurations, size of event databases, and whether/how those things 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.

About Disk Space Requirements

Space estimates are the largest reported for all upgrades, and are:

  • Not rounded up (under 1 MB).

  • Rounded up to the next 1 MB (1 MB - 100 MB).

  • Rounded up to the next 10 MB (100 MB - 1GB).

  • Rounded up to the next 100 MB (greater than 1 GB).

Version 6.3.0 Time and Disk Space

Table 11. Version 6.3.0 Time and Disk Space
Platform Space on /Volume Space on / Space on FMC Time

FMC

12.7 GB

29 MB

—

47 min

FMCv on: VMware 6.0

12.7 GB

29 MB

—

29 min

Firepower 2100 series

13 MB

8.8 GB

930 MB

20 min

Firepower 4100/9300 chassis

10 MB

7.6 GB

930 MB

6 min

ASA 5500-X series with FTD

7.9 GB

100 KB

1.1 GB

25 min

FTDv: VMware 6.0

7.3 GB

100 KB

1.1 GB

12 min

Firepower 7000/8000 series

7.0 GB

19 MB

920 MB

32 min

ASA FirePOWER

11.3 GB

22 MB

1.2 GB

63 min

NGIPSv

5.7 GB

19 MB

810 MB

16 min

Traffic Flow, Inspection, and Device Behavior

You must identify potential interruptions in traffic flow and inspection during the upgrade. This can occur:

  • When a device is rebooted.

  • When you upgrade the operating system or virtual hosting environment on a device.

  • When you upgrade the Firepower software on a device, or uninstall a patch.

  • When you deploy configuration changes as part of the upgrade or uninstall process (Snort process restarts).

Device type, deployment type (standalone, high availability, clustered), and interface configurations (passive, IPS, firewall, and so on) determine the nature of the interruptions. We strongly recommend performing any upgrade or uninstall in a maintenance window or at a time when any interruption will have the least impact on your deployment.

FTD Upgrade Behavior: Firepower 4100/9300 Chassis

This section describes device and traffic behavior when you upgrade a Firepower 4100/9300 chassis with FTD.

Firepower 4100/9300 Chassis: FXOS Upgrade

Upgrade FXOS on each chassis independently, even if you have inter-chassis clustering or high availability pairs configured. How you perform the upgrade determines how your devices handle traffic during the FXOS upgrade.

Table 12. Traffic Behavior During FXOS Upgrade
Deployment Method Traffic Behavior

Standalone

—

Dropped

High availability

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

Unaffected

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

Dropped until one peer is online

Inter-chassis cluster (6.2+)

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

Unaffected

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

Dropped until at least one module is online

Intra-chassis cluster (Firepower 9300 only)

Fail-to-wire enabled: Bypass: Standby or Bypass‑Force. (6.1+)

Passed without inspection

Fail-to-wire disabled: Bypass: Disabled. (6.1+)

Dropped until at least one module is online

No fail-to-wire module.

Dropped until at least one module is online

Standalone FTD Device: Firepower Software Upgrade

Interface configurations determine how a standalone device handles traffic during the upgrade.

Table 13. Traffic Behavior During Firepower Software Upgrade: Standalone FTD Device
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, fail-to-wire enabled: Bypass: Standby or Bypass‑Force (6.1+)

Either:

  • Dropped (6.1 through 6.2.2.x)

  • Passed without inspection (6.2.3+)

Inline set, fail-to-wire disabled: Bypass: Disabled (6.1+)

Dropped

Inline set, no fail-to-wire module

Dropped

Inline set, tap mode

Egress packet immediately, copy not inspected

Passive, ERSPAN passive

Uninterrupted, not inspected

High Availability Pairs: Firepower Software Upgrade

You should not experience interruptions in traffic flow or inspection while upgrading the Firepower software on devices in high availability pairs. To ensure continuity of operations, they upgrade one at a time. Devices operate in maintenance mode while they upgrade.

The standby device upgrades first. The devices switch roles, then the new standby upgrades. When the upgrade completes, the devices' roles remain switched. If you want to preserve the active/standby roles, manually switch the roles before you upgrade. That way, the upgrade process switches them back.

Clusters: Firepower Software Upgrade

You should not experience interruptions in traffic flow or inspection while upgrading the Firepower software on devices in Firepower Threat Defense clusters. To ensure continuity of operations, they upgrade one at a time. Devices operate in maintenance mode while they upgrade.

The slave security module or modules upgrade first, then the master. Security modules operate in maintenance mode while they upgrade.

During the master 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. Whether traffic drops during this interruption or passes without further inspection depends on how the device handles traffic.

High Availability and Clustering Hitless Upgrade Requirements

Performing hitless upgrades have the following additional requirements.

Flow Offload: Due to bug fixes in the flow offload feature, some combinations of FXOS and FTD do not support flow offload; see the Cisco Firepower Compatibility Guide. To perform a hitless upgrade in a high availability or clustered deployment, you must make sure you are always running a compatible combination.

If your upgrade path includes upgrading FXOS to 2.2.2.91, 2.3.1.130, or later (including FXOS 2.4.1.x, 2.6.1.x, and so on) use this path:

1. Upgrade FTD to 6.2.2.2 or later.

2. Upgrade FXOS to 2.2.2.91, 2.3.1.130, or later.

3. Upgrade FTD to your final version.

For example, if you are running FXOS 2.2.2.17/FTD 6.2.2.0, and you want to upgrade to FXOS 2.6.1/FTD 6.4.0, then you can:

1. Upgrade FTD to 6.2.2.5.

2. Upgrade FXOS to 2.6.1.

3. Upgrade FTD to 6.4.0.

Version 6.1.0 Upgrades: Performing a hitless upgrade of an FTD high availability pair to Version 6.1.0 requires a preinstallation package. For more information, see Firepower System Release Notes Version 6.1.0 Preinstallation Package.

Traffic Behavior During Deployment

You deploy configurations multiple times during the upgrade process. 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. For more information, see Configurations that Restart the Snort Process when Deployed or Activated in the Firepower Management Center Configuration Guide.

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

Table 14. Traffic Behavior During FTD Deployment
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 (6.0.1 - 6.1.0.x)

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 (6.2+)

Dropped

Inline set, Snort Fail Open: Down: enabled (6.2+)

Passed without inspection

Inline set, tap mode

Egress packet immediately, copy not inspected

Passive, ERSPAN passive

Uninterrupted, not inspected

FTD Upgrade Behavior: Other Devices

This section describes device and traffic behavior when you upgrade Firepower Threat Defense on Firepower 1000/2100 series, ASA 5500-X series, ISA 3000, and FTDv.

Standalone FTD Device: Firepower Software Upgrade

Interface configurations determine how a standalone device handles traffic during the upgrade.

Table 15. Traffic Behavior During Firepower Software Upgrade: Standalone FTD Device
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, fail-to-wire enabled: Bypass: Standby or Bypass‑Force (6.1+)

Either:

  • Dropped (6.1 through 6.2.2.x)

  • Passed without inspection (6.2.3+)

Inline set, fail-to-wire disabled: Bypass: Disabled (6.1+)

Dropped

Inline set, no fail-to-wire module

Dropped

Inline set, tap mode

Egress packet immediately, copy not inspected

Passive, ERSPAN passive

Uninterrupted, not inspected

High Availability Pairs: Firepower Software Upgrade

You should not experience interruptions in traffic flow or inspection while upgrading the Firepower software on devices in high availability pairs. To ensure continuity of operations, they upgrade one at a time. Devices operate in maintenance mode while they upgrade.

The standby device upgrades first. The devices switch roles, then the new standby upgrades. When the upgrade completes, the devices' roles remain switched. If you want to preserve the active/standby roles, manually switch the roles before you upgrade. That way, the upgrade process switches them back.

Traffic Behavior During Deployment

You deploy configurations multiple times during the upgrade process. 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. For more information, see Configurations that Restart the Snort Process when Deployed or Activated in the Firepower Management Center Configuration Guide.

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

Table 16. Traffic Behavior During FTD Deployment
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 (6.0.1 - 6.1.0.x)

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 (6.2+)

Dropped

Inline set, Snort Fail Open: Down: enabled (6.2+)

Passed without inspection

Inline set, tap mode

Egress packet immediately, copy not inspected

Passive, ERSPAN passive

Uninterrupted, not inspected

Firepower 7000/8000 Series Upgrade Behavior

The following sections describe device and traffic behavior when you upgrade Firepower 7000/8000 series devices.

Standalone 7000/8000 Series: Firepower Software Upgrade

Interface configurations determine how a standalone device handles traffic during the upgrade.

Table 17. Traffic Behavior During Upgrade: Standalone 7000/8000 Series
Interface Configuration Traffic Behavior

Inline, hardware bypass enabled (Bypass Mode: Bypass)

Passed without inspection, although traffic is interrupted briefly at two points:

  • At the beginning of the upgrade process as link goes down and up (flaps) and the network card switches into hardware bypass.

  • After the upgrade finishes as link flaps and the network card switches out of bypass. Inspection resumes after the endpoints reconnect and reestablish link with the device interfaces.

Inline, no hardware bypass module,or hardware bypass disabled (Bypass Mode: Non‑Bypass)

Dropped

Inline, tap mode

Egress packet immediately, copy not inspected

Passive

Uninterrupted, not inspected

Routed, switched

Dropped

7000/8000 Series High Availability Pairs: Firepower Software Upgrade

You should not experience interruptions in traffic flow or inspection while upgrading devices (or device stacks) in high availability pairs. To ensure continuity of operations, they upgrade one at a time. Devices operate in maintenance mode while they upgrade.

Which peer upgrades first depends on your deployment:

  • Routed or switched: Standby upgrades first. The devices switch roles, then the new standby upgrades. When the upgrade completes, the devices' roles remain switched. If you want to preserve the active/standby roles, manually switch the roles before you upgrade. That way, the upgrade process switches them back.

  • Access control only: Active upgrades first. When the upgrade completes, the active and standby maintain their old roles.

8000 Series Stacks: Firepower Software Upgrade

In an 8000 series stack, devices upgrade simultaneously. Until the primary device completes its upgrade and the stack resumes operation, traffic is affected as if the stack were a standalone device. Until all devices complete the upgrade, the stack operates in a limited, mixed-version state.

Traffic Behavior During Deployment

You deploy configurations multiple times during the upgrade process. 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. For more information, see Configurations that Restart the Snort Process when Deployed or Activated in the Firepower Management Center Configuration Guide.

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

Table 18. Traffic Behavior During Deployment: 7000/8000 Series
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

Routed, switched

Dropped

ASA FirePOWER Upgrade Behavior

Your ASA service policies for redirecting traffic to the ASA FirePOWER module determine how the module handles traffic during the Firepower software upgrade, including when you deploy certain configurations that restart the Snort process.

Table 19. Traffic Behavior During ASA FirePOWER Upgrade
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

Traffic Behavior During ASA FirePOWER Deployment

Traffic behavior while the Snort process restarts is the same as when you upgrade the ASA FirePOWER module.

You deploy configurations multiple times during the upgrade process. 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. For more information, see Configurations that Restart the Snort Process when Deployed or Activated in the Firepower Management Center Configuration Guide.

When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, restarting the Snort process interrupts traffic inspection. Your service policies determine whether traffic drops or passes without inspection during the interruption.

NGIPSv Upgrade Behavior

This section describes device and traffic behavior when you upgrade NGIPSv.

Firepower Software Upgrade

Interface configurations determine how NGIPSv handles traffic during the upgrade.

Table 20. Traffic Behavior During NGIPSv Upgrade
Interface Configuration Traffic Behavior

Inline

Dropped

Inline, tap mode

Egress packet immediately, copy not inspected

Passive

Uninterrupted, not inspected

Traffic Behavior During Deployment

You deploy configurations multiple times during the upgrade process. 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. For more information, see Configurations that Restart the Snort Process when Deployed or Activated in the Firepower Management Center Configuration Guide.

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

Table 21. Traffic Behavior During NGIPSv Deployment
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

Upgrade Packages

Upgrade packages are available on the Cisco Support & Download site.

Upgrade packages from Version 6.2.1+ are signed tar archives (.tar). Do not untar.

Table 22. Upgrade Packages from Version 6.2.1+
Platform Package

FMC/FMCv

Cisco_Firepower_Mgmt_Center_Upgrade-version-build.sh.REL.tar

Firepower 2100 series

Cisco_FTD_SSP_FP2K_Upgrade-version-build.sh.REL.tar

Firepower 4100/9300 chassis

Cisco_FTD_SSP_Upgrade-version-build.sh.REL.tar

ASA 5500-X series with FTD

ISA 3000 with FTD

Firepower Threat Defense Virtual

Cisco_FTD_Upgrade-version-build.sh.REL.tar

Firepower 7000/8000 series

Cisco_Firepower_NGIPS_Appliance_Upgrade-version-build.sh.REL.tar

ASA FirePOWER

Cisco_Network_Sensor_Upgrade-version-build.sh.REL.tar

NGIPSv

Cisco_Firepower_NGIPS_Virtual_Upgrade-version-build.sh.REL.tar

Table 23. Upgrade Packages from Version 6.1.x or 6.2.0.x
Platform Package

FMC/FMCv

Cisco_Firepower_Mgmt_Center_Upgrade-version-build.sh

Firepower 4100/9300 chassis

Cisco_FTD_SSP_Upgrade-version-build.sh

ASA 5500-X series with FTD

Firepower Threat Defense Virtual

Cisco_FTD_Upgrade-version-build.sh

Firepower 7000/8000 series

Cisco_Firepower_NGIPS_Appliance_Upgrade-version-build.sh

ASA FirePOWER

Cisco_Network_Sensor_Upgrade-version-build.sh

NGIPSv

Cisco_Firepower_NGIPS_Virtual_Upgrade-version-build.sh

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

Related Cisco Community Discussions

About Us
Contact Us
Work with Us