Upgrade Guidelines

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

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-66-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.6, including maintenance releases, as follows.

Table 2. Minimum Version to Upgrade to Version 6.6

Platform

Minimum Version

FMC

6.2.3

FTD

6.2.3

FXOS 2.8.1.15 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.8(1).

ASA with FirePOWER Services

6.2.3

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

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

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

✓

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

ADDITIONAL GUIDELINES FOR SPECIFIC DEPLOYMENTS

Upgrade Prohibited: FMC Version 6.6.5+ to Version 6.7.0

FMC

6.6.5 or later 6.6.x release

6.7.0 only

Upgrade Failure: FMC with Email Alerting for Intrusion Events

FMC

6.2.3 through 6.7.0.x

6.7.0

6.6.0, 6.6.1, or 6.6.3

All patches to these releases.

FMCv Requires 28 GB RAM for Upgrade

FMCv

6.2.3 through 6.5.0.x

6.6+

Firepower 1000 Series Devices Require Post-Upgrade Power Cycle

Firepower 1000 series

6.4.0.x

6.5+

New URL Categories and Reputations

Any

6.2.3 through 6.4.0.x

6.5+

TLS Crypto Acceleration Enabled/Cannot Disable

Firepower 2100 series

Firepower 4100/9300

6.2.3 through 6.3.0.x

6.4+

Renamed Upgrade and Installation Packages

FMC

Firepower 7000/8000 series

NGIPSv

Any

6.3+

Readiness Check May Fail on FMC, 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+
Table 4. Upgrade Guidelines for FTD with FDM Version 6.6

✓

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

Version 6.6.0.1 FTD Upgrade with FDM Suspends HA

Any

6.6.0

6.6.0.1

Firepower 1000 Series Devices Require Post-Upgrade Power Cycle

Firepower 1000 series

6.4.0.x

6.5+

Historical Data Removed During FTD Upgrade with FDM

Any

6.2.3 through 6.4.0.x

6.5+

New URL Categories and Reputations

Any

6.2.3 through 6.4.0.x

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

Version 6.6.0.1 FTD Upgrade with FDM Suspends HA

Deployments: FTD with FDM, configured as a high availability pair

Upgrading from: Version 6.6.0

Directly to: Version 6.6.0.1

Related bug: CSCvv45500

After you upgrade an FDM-managed FTD device in high availability (HA) to Version 6.6.0.1, the device enters Suspended mode after the post-upgrade reboot. You must manually resume HA.

FMC deployments are not affected.

To upgrade an FDM-managed FTD HA pair to Version 6.6.0.1:

  1. Upgrade the standby device.

  2. When the upgrade completes and the device reboots, manually resume HA. You can use FDM or the CLI:

    • FDM: Click Device > High Availability, then select Resume HA from the gear menu (Gear/Settings button.).

    • CLI: configure high-availability resume

    The HA status of the freshly upgraded device should return to normal, as the standby unit, after the unit negotiates with the peer.

  3. Switch the active and standby peers (force failover) so the freshly upgraded device is now the active peer.

  4. Repeat this procedure for the new standby peer.

For more information on configuring and managing high availability with FDM, see the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager.

Upgrade Prohibited: FMC Version 6.6.5+ to Version 6.7.0

Deployments: FMC

Upgrading from: Version 6.6.5 or later maintenance release

Directly to: Version 6.7.0 only

You cannot upgrade to Version 6.7.0 from Version 6.6.5 or any later 6.6.x maintenance release. This is because the Version 6.6.5 data store is newer than the Version 6.7.0 data store. If you are running Version 6.6.5+, we recommend you upgrade directly to Version 7.0.0 or later.

Upgrade Failure: FMC with Email Alerting for Intrusion Events

Deployments: Firepower Management Center

Upgrading from: Version 6.2.3 through 6.7.0.x

Directly to: Version 6.6.0, 6.6.1, 6.6.3, or 6.7.0, as well as any patches to these releases

Related bugs: CSCvw38870, CSCvx86231

If you configured email alerting for individual intrusion events, fully disable it before you upgrade a Firepower Management Center to any of the versions listed above. Otherwise, the upgrade will fail.

You can reenable this feature after the upgrade. If you already experienced an upgrade failure due to this issue, contact Cisco TAC.

To fully disable intrusion email alerting:

  1. On the Firepower Management Center, choose Policies > Actions > Alerts, then click Intrusion Email.

  2. Set the State to off.

  3. Next to Rules, click Email Alerting per Rule Configuration and deselect any rules.

    Note which rules you deselected so you can reselect them after the upgrade.


    Tip

    If reselecting rules would be too time consuming, contact Cisco TAC before you upgrade. They can guide you through saving your selections, so you can quickly reimplement them post-upgrade.

  4. Save your configurations.

FMCv Requires 28 GB RAM for Upgrade

Deployments: FMCv

Upgrading from: Version 6.2.3 through 6.5

Directly to: Version 6.6+

All FMCv implementations now have the same RAM requirements: 32 GB recommended, 28 GB required (64 GB for FMCv 300). Upgrades to Version 6.6+ will fail if you allocate less than 28 GB to the virtual appliance. After upgrade, the health monitor will alert if you lower the memory allocation.

These new memory requirements enforce uniform requirements across all virtual environments, improve performance, and allow you to take advantage of new features and functionality. We recommend you do not decrease the default settings. To improve performance, you can increase a virtual appliance’s memory and number of CPUs, depending on your available resources. For details, see the Cisco Secure Firewall Management Center Virtual Getting Started Guide.


Note

As of the Version 6.6.0 release, lower-memory instance types for cloud-based FMCv deployments (AWS, Azure) are fully deprecated. You cannot create new instances using them, even for earlier versions. You can continue running existing instances.

This table summarizes pre-upgrade requirements for lower-memory deployments.

Table 5. FMCv Memory Requirements for Version 6.6+ Upgrades

Platform

Pre-Upgrade Action

Details

VMware

Allocate 28 GB minimum/32 GB recommended.

Power off the virtual machine first.

For instructions, see the VMware documentation.

KVM

Allocate 28 GB minimum/32 GB recommended.

For instructions, see the documentation for your KVM environment.

AWS

Resize instances:

  • From c3.xlarge to c3.4xlarge.

  • From c3.2.xlarge to c3.4xlarge.

  • From c4.xlarge to c4.4xlarge.

  • From c4.2xlarge to c4.4xlarge.

We also offer a c5.4xlarge instance for new deployments.

Stop the instance before you resize. Note that when you do this, data on the instance store volume is lost, so migrate your instance store-backed instance first. Additionally, if your management interface does not have an Elastic IP address, its public IP address is released.

For instructions, see the documentation on changing your instance type in the AWS user guide for Linux instances.

Azure

Resize instances:

  • From Standard_D3_v2 to Standard_D4_v2.

Use the Azure portal or PowerShell. You do not need to stop the instance before you resize, but stopping may reveal additional sizes. Resizing restarts a running virtual machine.

For instructions, see the Azure documentation on resizing a Windows VM.

Firepower 1000 Series Devices Require Post-Upgrade Power Cycle

Deployments: Firepower 1000 series

Upgrading from: Version 6.4.0.x

Directly to: Version 6.5.0+

Version 6.5.0 introduces an FXOS CLI 'secure erase' feature for Firepower 1000/2100 and Firepower 4100/9300 series devices.

For Firepower 1000 series devices, you must power cycle the device after you upgrade to Version 6.5.0+ for this feature to work properly. The automatic reboot is not sufficient. Other supported devices do not require the power cycle.

Historical Data Removed During FTD Upgrade with FDM

Deployments: FTD with FDM

Upgrading from: Version 6.2.3 through 6.4.0.x

Directly to: 6.5.0+

All historical report data is removed during the upgrade due to a database schema change. After the upgrade, you cannot query historical data, nor view historical data in dashboards.

New URL Categories and Reputations

Deployments: Any

Upgrading from: Version 6.2.3 through 6.4.0.x

Directly to: Version 6.5.0+

Talos Intelligence Group has introduced new categories and renamed reputations to classify and filter URLs. For detailed lists of category changes, see the Cisco Firepower Release Notes, Version 6.5.0. For descriptions of the new URL categories, see the Talos Intelligence Categories site.

Also new are the concepts of uncategorized and reputationless URLs, although rule configuration options stay the same:

  • Uncategorized URLs can have a Questionable, Neutral, Favorable, or Trusted reputation.

    You can filter Uncategorized URLs but you cannot further constrain by reputation. These rules will match all uncategorized URLs, regardless of reputation.

    Note that there is no such thing as an Untrusted rule with no category. Otherwise uncategorized URLs with an Untrusted reputation are automatically assigned to the new Malicious Sites threat category.

  • Reputationless URLs can belong to any category.

    You cannot filter reputationless URLs. There is no option in the rule editor for 'no reputation.' However, you can filter URLs with Any reputation, which includes reputationless URLs. These URLs must also be constrained by category. There is no utility to an Any/Any rule.

The following table summarizes the changes on upgrade. Although they are designed for minimal impact and will not prevent post-upgrade deploy for most customers, we strongly recommend you review these release notes and your current URL filtering configuration. Careful planning and preparation can help you avoid missteps, as well as reduce the time you spend troubleshooting post-upgrade.

Table 6. Deployment Changes on Upgrade

Change

Details

Modifies URL rule categories.

The upgrade modifies URL rules to use the nearest equivalents in the new category set, in the following policies:

  • Access control

  • SSL

  • QoS (FMC only)

  • Correlation (FMC only)

These changes may create redundant or preempted rules, which can slow performance. If your configuration includes merged categories, you may experience minor changes to the URLs that are allowed or blocked.

Renames URL rule reputations.

The upgrade modifies URL rules to use the new reputation names:

  1. Untrusted (was High Risk)

  2. Questionable (was Suspicious sites)

  3. Neutral (was Benign sites with security risks)

  4. Favorable (was Benign sites)

  5. Trusted (was Well Known)

Clears the URL cache.

The upgrade clears the URL cache, which contains results that the system previously looked up in the cloud. Your users may temporarily experience slightly longer access times for URLs that are not in the local data set.

Labels 'legacy' events.

For already-logged events, the upgrade labels any associated URL category and reputation information as Legacy. These legacy events will age out of the database over time.

Pre-Upgrade Actions for URL Categories and Reputations

Before upgrade, take the following actions.

Table 7. Pre-Upgrade Actions

Action

Details

Make sure your appliances can reach Talos resources.

The system must be able to communicate with the following Cisco resources after the upgrade:

  • https://regsvc.sco.cisco.com/ — Registration

  • https://est.sco.cisco.com/ — Obtain certificates for secure communications

  • https://updates-talos.sco.cisco.com/ — Obtain client/server manifests

  • http://updates.ironport.com/ — Download database (note: uses port 80)

  • https://v3.sds.cisco.com/ — Cloud queries

The cloud query service also uses the following IP address blocks:

  • IPv4 cloud queries:

    • 146.112.62.0/24

    • 146.112.63.0/24

    • 146.112.255.0/24

    • 146.112.59.0/24

  • IPv6 cloud queries:

    • 2a04:e4c7:ffff::/48

    • 2a04:e4c7:fffe::/48

Identify potential rule issues.

Understand the upcoming changes. Examine your current URL filtering configuration and determine what post-upgrade actions you will need to take (see the next section).

Note

 

You may want to modify URL rules that use deprecated categories now. Otherwise, rules that use them will prevent deploy after the upgrade.

In FMC deployments, we recommend you generate an access control policy report, which provides details on the policy's current saved configuration, including access control rules and rules in subordinate policies (such as SSL). For each URL rule, you can see the current categories, reputations, and associated rule actions. On the FMC, choose Policies > Access Control, then click the report icon () next to the appropriate policy.

Post-Upgrade Actions for URL Categories and Reputations

After upgrade, you should reexamine your URL filtering configuration and take the following actions as soon as possible. Depending on deployment type and the changes made by the upgrade, some — but not all — issues may be marked in the GUI. For example, in access control policies on FMC/FDM, you can click Show Warnings (FMC) or Show Problem Rules (FDM).

Table 8. Post-Upgrade Actions

Action

Details

Remove deprecated categories from rules. Required.

The upgrade does not modify URL rules that use deprecated categories. Rules that use them will prevent deploy.

On the FMC, these rules are marked.

Create or modify rules to include the new categories.

Most of the new categories identify threats. We strongly recommend you use them.

On the FMC, these new categories are not marked after this upgrade, but Talos may add additional categories in the future. When that happens, new categories are marked.

Evaluate rules changed as a result of merged categories.

Each rule that included any of the affected categories now include all of the affected categories. If the original categories were associated with different reputations, the new rule is associated with the broader, more inclusive reputation. To filter URLs as before, you may have to modify or delete some configurations; see Guidelines for Rules with Merged URL Categories.

Depending on what changed and how your platform handles rule warnings, changes may be marked. For example, the FMC marks wholly redundant and wholly preempted rules, but not rules that have partial overlap.

Evaluate rules changed as a result of split categories.

The upgrade replaces each old, single category in URL rules with all the new categories that map to the old one. This will not change the way you filter URLs, but you can modify affected rules to take advantage of the new granularity.

These changes are not marked.

Understand which categories were renamed or are unchanged.

Although no action is required, you should be aware of these changes.

These changes are not marked.

Evaluate how you handle uncategorized and reputationless URLs.

Even though it is now possible to have uncategorized and reputationless URLs, you cannot still cannot filter uncategorized URLs by reputation, nor can you filter reputationless URLs.

Make sure that rules that filter by the Uncategorized category, or by Any reputation, will behave as you expect.

Guidelines for Rules with Merged URL Categories

When you examine your URL filtering configuration before the upgrade, determine which of the following scenarios and guidelines apply to you. This will ensure that your post-upgrade configuration is as you expect, and that you can take quick action to resolve any issues.

Table 9. Guidelines for Rules with Merged URL Categories

Guideline

Details

Rule Order Determines Which Rule Matches Traffic

When considering rules that include the same category, remember that traffic matches the first rule in the list that includes the condition.

Categories in the Same Rule vs Categories in Different Rules

Merging categories in a single rule will merge into a single category in the rule. For example, if Category A and Category B are merging to become Category AB, and you have a rule with both Category A and Category B, then after merge the rule will have a single Category AB.

Merging categories in different rules will result in separate rules with the same category in each rule after the merge. For example, if Category A and Category B are merging to become Category AB, and you have Rule 1 with Category A and Rule 2 with Category B, then after merge Rule 1 and Rule 2 will each include Category AB. How you choose to resolve this situation depends on the rule order, on the actions and reputation levels associated with the rules, on the other URL categories included in the rule, and on the non-URL conditions that are included in the rule.

Associated Action

If merged categories in different rules were associated with different actions, then after merge you may have two or more rules with different actions for the same category.

Associated Reputation Level

If a single rule includes categories that were associated with different reputation levels before merging, the merged category will be associated with the more inclusive reputation level. For example, if Category A was associated in a particular rule with Any reputation and Category B was associated in the same rule with reputation level 3 - Benign sites with security risks, then after merge Category AB in that rule will be associated with Any reputation.

Duplicate and Redundant Categories and Rules

After merge, different rules may have the same category associated with different actions and reputation levels.

Redundant rules may not be exact duplicates, but they may no longer match traffic if another rule earlier in the rule order matches instead. For example, if you have pre-merge Rule 1 with Category A that applies to Any Reputation, and Rule 2 with Category B that applies only to Reputation 1-3, then after merge, both Rule 1 and Rule 2 will have Category AB, but Rule 2 will never match if Rule 1 is higher in the rule order.

On the FMC, rules with an identical category and reputation will show a warning. However, these warnings will not indicate rules that include the same category but a different reputation.

Caution: Consider all conditions in the rule when determining how to resolve duplicate or redundant categories.

Other URL Categories in a Rule

Rules with merged URLs may also include other URL categories. Therefore, if a particular category is duplicated after merge, you may want to modify rather than delete these rules.

Non-URL Conditions in a Rule

Rules with merged URL categories may also include other rule conditions, such as application conditions. Therefore, if a particular category is duplicated after merge, you may want to modify rather than delete these rules.

The examples in the following table use Category A and Category B, now merged into Category AB. In two-rule examples, Rule 1 comes before Rule 2.

Table 10. Examples of Rules with Merged URL Categories

Scenario

Before Upgrade

After Upgrade

Merged categories in the same rule

Rule 1 has Category A and Category B.

Rule 1 has Category AB.

Merged categories in different rules

Rule 1 has Category A.

Rule 2 has Category B.

Rule 1 has Category AB.

Rule 2 has Category AB.

The specific result varies by the rules' order in the list, reputation levels, and associated actions. You should also consider all other conditions in the rule when determining how to resolve any redundancy.

Merged categories in different rules have different actions

(Reputation is the same)

Rule 1 has Category A set to Allow.

Rule 2 has Category B set to Block.

(Reputation is the same)

Rule 1 has Category AB set to Allow.

Rule 2 has Category AB set to Block.

Rule 1 will match all traffic for this category.

Rule 2 will never match traffic, and will display a warning indicator if you show warnings after merge, because both category and reputation are the same.

Merged categories in the same rule have different reputation levels

Rule 1 includes:

Category A with Reputation Any

Category B with Reputation 1-3

Rule 1 includes Category AB with Reputation Any.

Merged categories in different rules have different reputation levels

Rule 1 includes Category A with Reputation Any.

Rule 2 includes Category B with Reputation 1-3.

Rule 1 includes Category AB with Reputation Any.

Rule 2 includes Category AB with Reputation 1-3.

Rule 1 will match all traffic for this category.

Rule 2 will never match traffic, but you will not see a warning indicator because the reputations are not identical.

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.

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. You cannot reimage these appliances to Version 6.5+.
Table 11. Naming Schemes: Upgrade, Patch, and Hotfix Packages
Platform Naming Schemes

FMC

New: Cisco_Firepower_Mgmt_Center

Old: Sourcefire_3D_Defense_Center_S3

NGIPSv

New: Cisco_Firepower_NGIPS_Virtual

Old: Sourcefire_3D_Device_VMware

Old: Sourcefire_3D_Device_Virtual64_VMware

Table 12. 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, NGIPSv

Deployments: FMC, 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 13. 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.

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 14. Upgrade Guidelines for the Firepower 4100/9300 Chassis

Guideline

Details

FXOS upgrades.

FXOS 2.8.1.15+ is required to run threat defense Version 6.6 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 or maintenance 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.

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 15. 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 16. 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 17. 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.

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 18. 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 19. 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 20. 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 21. 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 22. 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 23. 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.