Important Guidelines Before You Upgrade
Check for upgrade guidelines and limitations, and configuration migrations for each operating system.
ASA Upgrade Guidelines
Before you upgrade, check for migrations and any other guidelines.
Version-Specific Guidelines and Migrations
Depending on your current version, you might experience one or more configuration migrations, and have to consider configuration guidelines for all versions between the starting version and the ending version when you upgrade.
9.23 Guidelines
-
The ASA SSH stack was deprecated in 9.23—You can no longer use the ASA SSH stack. The Cisco SSH stack is now the only stack. Because the Cisco SSH stack does not support EDDSA, before you upgrade you must change your configuration for a supported key pair:
-
Generate the default key pair.
crypto key generate {ecdsa elliptic-curve size | rsa modulus size}
Do not add the label keyword; SSH only uses the default key pair (named Default-type-Key).
-
If you configured the ssh key-exchange hostkey eddsa command, you need to remove it with the no form. If you use this command, you may get unexpected results.
-
9.22 Guidelines
-
Smart licensing default transport changed in 9.22—In 9.22, the smart licensing default transport changed from Smart Call Home to Smart Transport. You can configure the ASA to use Smart Call Home if necessary using the transport type callhome command. When you upgrade to 9.22, the transport is automatically changed Smart Transport. If you downgrade, the transport is set back to Smart Call Home, and if you want to use Smart Transport, you need to specify transport type smart . Note also that the licensing URL for Smart Transport is https://smartreceiver.cisco.com (compared to tools.cisco.com), so be sure to allow that URL on upstream routers.
9.20 Guidelines
-
OSPFv3 redistribute commands that specify a route-map that matches a prefix-list will be removed in 9.20(2)—When you upgrade to 9.20(2), OSPFv3 redistribute commands where the specified route-map uses a match ip address prefix-list will be removed from the configuration. Although prefix lists have never been supported, the parser still accepted the command. Before upgrading, you should reconfigure OSPFv3 to use route maps that specify an ACL in the match ip address command.
Remember
Redistribution of route maps with IPv4 prefix list on OSPFv2 is supported.
9.19 Guidelines
-
ASDM 7.19(1) requires Oracle Java version 8u261 or later—Before you upgrade to ASDM 7.19, be sure to update Oracle Java (if used) to version 8u261 or later. This version supports TLSv1.3, which is required to upgrade the ASDM Launcher. OpenJRE is not affected.
9.18 Guidelines
-
ASDM signed-image support in 9.18(2)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)
-
9.18(1) upgrade issue if you enabled HTTPS/ASDM (with HTTPS authentication) and SSL on the same interface with the same port—If you enable both SSL (webvpn > enable interface) and HTTPS/ASDM (http ) access on the same interface, you can access AnyConnect from https://ip_address and ASDM from https://ip_address/admin, both on port 443. However, if you also enable HTTPS authentication (aaa authentication http console), then you must specify a different port for ASDM access starting in 9.18(1). Make sure you change the port before you upgrade using the http command. (CSCvz92016)
-
ASDM Upgrade Wizard—Due to ASD API migration, you must use ASDM 7.18 or later to upgrade to ASA 9.18 or later. Because ASDM is backwards compatible with earlier ASA versions, you can upgrade ASDM to 7.18 or later for any ASA version.
9.17 Guidelines
-
ASDM signed-image support in 9.17(1.13)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)
-
No support for Clientless SSL VPN in 9.17(1) and later—Clientless SSL VPN is no longer supported.
-
webvpn—The following subcommands are removed:
-
apcf
-
java-trustpoint
-
onscreen-keyboard
-
port-forward
-
portal-access-rule
-
rewrite
-
smart-tunnel
-
-
group-policy webvpn—The following subcommands are removed:
-
port-forward
-
smart-tunnel
-
ssl-clientless
-
-
-
ASDM Upgrade Wizard—Due to an internal change, starting in March 2022 the upgrade wizard will no longer work with pre-ASDM 7.17(1.152) versions. You must manually upgrade to 7.17(1.152) to use the wizard.
9.16 Guidelines
-
ASDM signed-image support in 9.16(3.19)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)
-
SNMPv3 users using MD5 hashing and DES encryption are no longer supported, and the users will be removed when you upgrade to 9.16(1)—Be sure to change any user configuration to higher security algorithms using the snmp-server user command before you upgrade.
-
SSH host key action required in 9.16(1)—In addition to RSA, we added support for the EDDSA and ECDSA host keys for SSH. The ASA tries to use keys in the following order if they exist: EDDSA, ECDSA, and then RSA. When you upgrade to 9.16(1), the ASA will fall back to using the existing RSA key. However, we recommend that you generate higher-security keys as soon as possible using the crypto key generate {eddsa | ecdsa} command. Moreover, if you explicitly configure the ASA to use the RSA key with the ssh key-exchange hostkey rsa command, you must generate a key that is 2048 bits or higher. For upgrade compatibility, the ASA will use smaller RSA host keys only when the default host key setting is used. RSA support will be removed in a later release.
-
In 9.16 and later, certificates with RSA keys are not compatible with ECDSA ciphers—When you use the ECDHE_ECDSA cipher group, configure the trustpoint with a certificate that contains an ECDSA-capable key.
-
ssh version command removed in 9.16(1)—This command has been removed. Only SSH version 2 is supported.
-
When you upgrade to 9.16 or later, you might see a different certificate serial number—In 9.16, the ASA started using OpenSSL, which causes negative values in certificates to be computed differently, so you may see a different serial number after upgrading. This change does not affect operation. (CSCvv30338)
-
SAMLv1 feature removed in 9.16(1)—Support for SAMLv1 was removed.
-
No support for DH groups 2, 5, and 24 in 9.16(1)—Support has been removed for the DH groups 2, 5, and 24 in SSL DH group configuration. The ssl dh-group command has been updated to remove the command options group2, group5, and group24.
9.12 Guidelines
-
ASDM signed-image support in 9.12(4.50)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)
-
ASDM Upgrade Wizard—Due to an internal change, the wizard is only supported using ASDM 7.10(1) and later; also, due to an image naming change, you must use ASDM 7.12(1) or later to upgrade to ASA 9.10(1) and later. Because ASDM is backwards compatible with earlier ASA releases, you can upgrade ASDM no matter which ASA version you are running.
-
SSH security improvements and new defaults in 9.12(1)—See the following SSH security improvements:
-
SSH version 1 is no longer supported; only version 2 is supported. The ssh version 1 command will be migrated to ssh version 2 .
-
Diffie-Hellman Group 14 SHA256 key exchange support. This setting is now the default (ssh key-exchange group dh-group14-sha256 ). The former default was Group 1 SHA1. Make sure that your SSH client supports Diffie-Hellman Group 14 SHA256. If it does not, you may see an error such as "Couldn't agree on a key exchange algorithm." For example, OpenSSH supports Diffie-Hellman Group 14 SHA256.
-
HMAC-SHA256 integrity cipher support. The default is now the high security set of ciphers (hmac-sha1 and hmac-sha2-256 as defined by the ssh cipher integrity high command). The former default was the medium set.
-
-
The NULL-SHA TLSv1 cipher is deprecated and removed in 9.12(1)—Because NULL-SHA doesn't offer encryption and is no longer considered secure against modern threats, it will be removed when listing supported ciphers for TLSv1 in the output of tls-proxy mode commands/options and show ssl ciphers all . The ssl cipher tlsv1 all and ssl cipher tlsv1 custom NULL-SHA commands will also be deprecated and removed.
-
The default trustpool is removed in 9.12(1)—In order to comply with PSB requirement, SEC-AUT-DEFROOT, the "default" trusted CA bundle is removed from the ASA image. As a result, crypto ca trustpool import default and crypto ca trustpool import clean default commands are also removed along with other related logic. However, in existing deployments, certificates that were previously imported using these command will remain in place.
-
The ssl encryption command is removed in 9.12(1)—In 9.3(2) the deprecation was announced and replaced by ssl cipher . In 9.12(1), ssl encryption is removed and no longer supported.
Clustering Guidelines
There are no special requirements for Zero Downtime Upgrades for ASA clustering with the following exceptions.
Note |
Zero Downtime Downgrades are not officially supported with clustering. |
-
Firepower 4100/9300 Failover and Clustering hitless upgrade requirements for flow offload—Due to bug fixes in the flow offload feature, some combinations of FXOS and ASA do not support flow offload (see the compatibility table). Flow offload is disabled by default for ASA. To perform a Failover or Clustering hitless upgrade when using flow offload, you need to follow the below upgrade paths to ensure that you are always running a compatible combination when upgrading to FXOS 2.3.1.130 or later:
-
Upgrade ASA to 9.8(3) or later
-
Upgrade FXOS to 2.3.1.130 or later
-
Upgrade ASA to your final version
For example, you are on FXOS 2.2.2.26/ASA 9.8(1), and you want to upgrade to FXOS 2.6.1/ASA 9.12(1), then you can:
-
Upgrade ASA to 9.8(4)
-
Upgrade FXOS to 2.6.1
-
Upgrade ASA to 9.12(1)
-
-
Firepower 4100/9300 Cluster Upgrade to FXOS 2.3/ASA 9.9(2)—Data units on ASA 9.8 and earlier cannot rejoin a cluster where the control unit is on FXOS 2.3/9.9(2) or later; they will join after you upgrade the ASA version to 9.9(2)+ [CSCvi54844].
-
Distributed Site-to-Site VPN—Distributed Site-to-Site VPN sessions on a failed unit require up to 30 minutes to stabilize on other units. During this time, additional unit failures might result in lost sessions. Therefore, during a cluster upgrade, to avoid traffic loss, follow these steps. Refer to the FXOS/ASA cluster upgrade procedure so you can integrate these steps into your upgrade task.
Note
Zero Downtime Upgrade is not supported with Distributed Site-to-Site VPN when upgrading from 9.9(1) to 9.9(2) or later. In 9.9(2), due to Active Session Redistribution enhancements, you cannot run some units on 9.9(2) and other units on 9.9(1).
-
On the chassis without the control unit, disable clustering on one module using the ASA console.
cluster group name
no enable
If you are upgrading FXOS on the chassis as well as ASA, save the configuration so clustering will be disabled after the chassis reboots:
write memory
-
Wait for the cluster to stabilize; verify all backup sessions have been created.
show cluster vpn-sessiondb summary
-
Repeat steps 1 and 2 for each module on this chassis.
-
Upgrade FXOS on the chassis using the FXOS CLI or Firepower Chassis Manager.
-
After the chassis comes online, update the ASA image on each module using the FXOS CLI or Firepower Chassis Manager.
-
After the modules come online, re-enable clustering on each module at the ASA console.
cluster group name
enable
write memory
-
Repeat steps 1 through 6 on the second chassis, being sure to disable clustering on the data units first, and then finally the control unit.
A new control unit will be chosen from the upgraded chassis.
-
After the cluster has stabilized, redistribute active sessions among all modules in the cluster using the ASA console on the control unit.
cluster redistribute vpn-sessiondb
-
-
Upgrade issue for 9.9(1) and later with clustering—9.9(1) and later includes an improvement in the backup distribution. You should perform your upgrade to 9.9(1) or later as follows to take advantage of the new backup distribution method; otherwise upgraded units will continue to use the old method.
-
Remove all secondary units from the cluster (so the cluster consists only of the primary unit).
-
Upgrade 1 secondary unit, and rejoin the cluster.
-
Disable clustering on the primary unit; upgrade it, and rejoin the cluster.
-
Upgrade the remaining secondary units, and join them back to the cluster, one at a time.
-
-
Firepower 4100/9300 Cluster Upgrade to ASA 9.8(1) and earlier—When you disable clustering on a data unit (no enable ), which is part of the upgrade process, traffic directed to that unit can drop for up to three seconds before traffic is redirected to a new owner [CSCvc85008].
-
Zero Downtime Upgrade may not be supported when upgrading to the following releases with the fix for CSCvb24585. This fix moved 3DES from the default (medium) SSL ciphers to the low cipher set. If you set a custom cipher that only includes 3DES, then you may have a mismatch if the other side of the connection uses the default (medium) ciphers that no longer include 3DES.
-
9.1(7.12)
-
9.2(4.18)
-
9.4(3.12)
-
9.4(4)
-
9.5(3.2)
-
9.6(2.4)
-
9.6(3)
-
9.7(1)
-
9.8(1)
-
-
Upgrade issues for fully-qualified domain name (FQDN) ACLs—Due to CSCuv92371, ACLs containing FQDNs might result in incomplete ACL replication to secondary units in a cluster or failover pair. This bug is present in 9.1(7), 9.5(2), 9.6(1), and some interim releases. We suggest that you upgrade to a version that includes the fix for CSCuy34265: 9.1(7.6) or later, 9.5(3) or later, 9.6(2) or later. However, due to the nature of configuration replication, zero downtime upgrade is not available. See CSCuy34265 for more information about different methods of upgrading.
-
Firepower Threat Defense Version 6.1.0 clusters do not support inter-site clustering (you can configure inter-site features using FlexConfig starting in 6.2.0). If you deployed or re-deployed a 6.1.0 cluster in FXOS 2.1.1, and you entered a value for the (unsupported) site ID, then you must remove the site ID (set it to 0) on each unit in FXOS before you upgrade to 6.2.3. Otherwise, the units will not be able to rejoin the cluster after the upgrade. If you already upgraded, change the site ID to 0 on each unit to resolve the issue. See the FXOS configuration guide to view or change the site ID
-
Upgrade to 9.5(2) or later (CSCuv82933)—Before you upgrade the control unit, if you enter show cluster info , the upgraded data units show as “DEPUTY_BULK_SYNC”; other mismatched states are also shown. You can ignore this display; the status will show correctly when you upgrade all units.
-
Upgrade from 9.0(1) or 9.1(1) (CSCue72961)—Zero Downtime Upgrade is not supported.
Failover Guidelines
There are no special requirements for Zero Downtime Upgrades for failover with the following exceptions:
-
For the Firepower 1010, invalid VLAN IDs can cause problems—Before you upgrade to 9.15(1), make sure you are not using a VLAN for switch ports in the range 3968 to 4047. These IDs are for internal use only, and 9.15(1) includes a check to make sure you are not using these IDs. For example, if these IDs are in use after upgrading a failover pair, the failover pair will go into a suspended state. See CSCvw33057 for more information.
-
Firepower 4100/9300 Failover and Clustering hitless upgrade requirements for flow offload—Due to bug fixes in the flow offload feature, some combinations of FXOS and ASA do not support flow offload (see the compatibility table). Flow offload is disabled by default for ASA. To perform a Failover or Clustering hitless upgrade when using flow offload, you need to follow the below upgrade paths to ensure that you are always running a compatible combination when upgrading to FXOS 2.3.1.130 or later:
-
Upgrade ASA to 9.8(3) or later
-
Upgrade FXOS to 2.3.1.130 or later
-
Upgrade ASA to your final version
For example, you are on FXOS 2.2.2.26/ASA 9.8(1), and you want to upgrade to FXOS 2.6.1/ASA 9.12(1), then you can:
-
Upgrade ASA to 9.8(4)
-
Upgrade FXOS to 2.6.1
-
Upgrade ASA to 9.12(1)
-
-
Upgrade issues with 8.4(6), 9.0(2) , and 9.1(2)—Due to CSCug88962, you cannot perform a Zero Downtime Upgrade to 8.4(6), 9.0(2), or 9.1(3). You should instead upgrade to 8.4(5) or 9.0(3). To upgrade 9.1(1), you cannot upgrade directly to the 9.1(3) release due to CSCuh25271, so there is no workaround for a Zero Downtime Upgrade; you must upgrade to 9.1(2) before you upgrade to 9.1(3) or later.
-
Upgrade issues for fully-qualified domain name (FQDN) ACLs—Due to CSCuv92371, ACLs containing FQDNs might result in incomplete ACL replication to secondary units in a cluster or failover pair. This bug is present in 9.1(7), 9.5(2), 9.6(1), and some interim releases. We suggest that you upgrade to a version that includes the fix for CSCuy34265: 9.1(7.6) or later, 9.5(3) or later, 9.6(2) or later. However, due to the nature of configuration replication, zero downtime upgrade is not available. See CSCuy34265 for more information about different methods of upgrading.
-
Upgrade issue with 9.7(1) to 9.7(1.x) and later for VTI and VXLAN VNI—If you configure both Virtual Tunnel Interfaces (VTIs) and VXLAN Virtual Network Identifier (VNI) interfaces, then you cannot perform a zero downtime upgrade for failover; connections on these interface types will not replicate to the standby unit until both units are on the same version. (CSCvc83062)
-
Before upgrading to 9.8(2) or later, FIPS mode requires the failover key to be at least 14 characters—Before you upgrade to to 9.8(2) or later in FIPS mode, you must change the failover key or failover ipsec pre-shared-key to be at least 14 characters long. If your failover key is too short, when you upgrade the first unit, the failover key will be rejected, and both units will become active until you set the failover key to a valid value.
-
Upgrade issue with GTP inspection—There could be some downtime during the upgrade, because the GTP data structures are not replicated to the new node.
Additional Guidelines
-
Cisco ASA Clientless SSL VPN Portal Customization Integrity Vulnerability—Multiple vulnerabilities have been fixed for clientless SSL VPN in ASA software, so you should upgrade your software to a fixed version. See https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141008-asa for details about the vulnerability and a list of fixed ASA versions. Also, if you ever ran an earlier ASA version that had a vulnerable configuration, then regardless of the version you are currently running, you should verify that the portal customization was not compromised. If an attacker compromised a customization object in the past, then the compromised object stays persistent after you upgrade the ASA to a fixed version. Upgrading the ASA prevents this vulnerability from being exploited further, but it will not modify any customization objects that were already compromised and are still present on the system.
FXOS Upgrade Guidelines
Before you upgrade, read the release notes for each FXOS version in your chosen upgrade path. Release notes contain important information about each FXOS release, including new features and changed functionality.
Upgrading may require configuration changes that you must address. For example, new hardware supported in an FXOS release might also require that you update the FXOS firmware.
FXOS release notes are available here: https://www.cisco.com/c/en/us/support/security/firepower-9000-series/products-release-notes-list.html.
Feedback