Check some basic information on your fabric to ensure that you have everything that you need for a smooth upgrade. Specifically, it is critical that you clear all faults. Although some faults are described as specific issues in Check Configurations and Conditions That May Cause An Upgrade or Downgrade Failure, you should always clear any faults before performing an upgrade except for the faults that are expected due to configurations in staging phase.

• Clear all your faults

• Perform a configuration export with AES Encryption

• Verify access to out-of-band IP addresses of all your ACI nodes (all your APIC nodes and switch nodes)

• Verify CIMC access for all your APICs

• Verify console access for all your switches

• Understand Changes in Behavior in Release Notes of both APIC and ACI switches for versions between the target and current version

• Understand Open Issues and Known Issues in Release Notes of both APIC and ACI switches for the target version

There are three different tools to perform pre-upgrade validation for Cisco Application Centric Infrastructure (ACI):

• Pre-Upgrade Validator (APIC): A validator embedded in the Cisco Application Policy Infrastructure Controller (APIC) Upgrade Configuration. This is automatically performed when configuring an update group for the Cisco APIC or switches.

• Pre-Upgrade Validator (App Center app): A validator that can be installed on the Cisco APICs as an app that can be downloaded through dcappcenter.cisco.com. Due to the deprecation of App Center (dcappcenter.cisco.com) in ACI Release 6.1.2, this option is considered obsolete. Use other options for all ACI versions.

• Script: For any feature not currently implemented in the Pre-Upgrade Validator, you can run a standalone script directly on the Cisco APIC to validate any existing issues prior to upgrading. The script supports all versions of software.

  To ensure you have ample time to address any issues, please run the validation at least 2 weeks before your maintenance window.

  See https://github.com/datacenter/ACI-Pre-Upgrade-Validation-Script for more details about the script.

See https://datacenter.github.io/ACI-Pre-Upgrade-Validation-Script/validations/ for the list of validations supported by the script.

In the Cisco APIC release 6.0(2) and later, download both the 32-bit and 64-bit Cisco ACI-mode switch images to the Cisco APIC. Downloading only one of the images may result in errors during the upgrade process. For more information, see Guidelines and limitations for upgrading or downgrading.

The following list includes some items for reference. For information about other check rules, see the ACI Pre-Upgrade Validation Script.

• If you are upgrading to Cisco APIC release 4.2(6o), 4.2(7l), 5.2(1g), or later, ensure that any VLAN encapsulation blocks that you are explicitly using for leaf switch front panel VLAN programming are set as "external (on the wire)." If these VLAN encapsulation blocks are instead set to "internal," the upgrade causes the front panel port VLAN to be removed, which can result in a datapath outage.

• When Cisco APIC is upgraded from Cisco APIC 4.0 or earlier to 5.1(1) or later, the Service Graph is re-rendered. This will result in traffic disruption until the re-rendering is completed, if vzAny-to-vzAny contract with service graph and another contract with service graph use the same service EPG.

• Prior to APIC version 5.0, when you have the following configuration, traffic in the provider-to-consumer direction was allowed incorrectly. This was fixed starting from APIC 5.0. As a result, the incorrectly allowed traffic will stop working after the upgrade from a pre-5.0 version to a post-5.0 version. If the provider-to-consumer direction should not be dropped, configure a contract filter in that direction accordingly.

  • Unidirectional contract (only consumer to provider filter without “Apply Both Direction” flag)

  • Shared Service (contract provider and consumer are in different VRFs)

  • L3Out EPG is the provider

  • L3Out EPG has 0.0.0.0/0 with “Shared Security Import Subnet”

  • The provider IP of the traffic is classified to the L3Out subnet 0.0.0.0/0

  • The consumer VRF has Preferred Group (PG) enabled

  • The consumer EPG is included in PG

  • The provider VRF is on the consumer leaf

• Prior to APIC version 5.0, when you have the following configuration, traffic in the provider-to-consumer direction was allowed incorrectly even though the configuration is invalid. The "Shared Security Import Subnet” scope is a mandatory configuration. This was fixed starting from APIC 5.0. As a result, the incorrectly allowed traffic will stop working after the upgrade from a pre-5.0 version to a post-5.0 version.

  • Shared Service (contract provider and consumer are in different VRFs)

  • L3Out EPG is the provider

  • The "Shared Security Import Subnet” scope is missing on all non-0.0.0.0/0 subnets in the L3Out EPG

  • Those non-0.0.0.0/0 subnets have the “External Subnet for the External EPG” scope

  • The provider IP of the traffic is classified to one of those non-0.0.0.0/0 subnets in the L3Out EPG

• Global AES Encryption must be enabled to upgrade to APIC release 6.1(2) or newer.

In general, apply the same checklists used for upgrades when you downgrade to an older version. Also, check whether new hardware or software features are supported on older versions. If you use such features, disable or change the configurations before downgrading. Otherwise, some features may stop working after you downgrade to an older version. This applies to all releases.

Here are some example features to review before downgrading. This list is not comprehensive; check the Release Notes or Configuration Guides to confirm that your features are supported on older releases.

• The ability to use the DUO application as an authentication method when logging in to Cisco Application Policy Infrastructure Controller (APIC) was introduced as part of the Cisco APIC release 5.0(1). If you are running release 5.0(1) and you have DUO set up as your default authentication method, but then you decide to downgrade from release 5.0(1) to a previous release where DUO was not supported as an authentication method, we recommend that you change the default authentication method from DUO to an option that was available prior to release 5.0(1), such as Local, LDAP, RADIUS, and so on. If you do not change the default authentication method before downgrading in this situation, you will have to log in using the fallback option after the downgrade, then you will have to change the authentication method to an option that was available prior to release 5.0(1) at that point.

  Navigate to Admin > AAA > Authentication, then change the setting in the Realm field in the Default Authentication area of the page to change the default authentication method before downgrading your system. You will also have to manually delete the DUO login domain after the downgrade.

• Starting with release 4.2(6) release, SNMPv3 supports the Secure Hash Algorithm-2 (SHA-2) authentication type. If you are running on Cisco APIC release 4.2(6) or later and you are using the SHA-2 authentication type, and then downgrade from Cisco APIC release 4.2(6) to a previous release, the downgrade will be blocked with the following error message:

  SHA-2authentication type is not supported.

  You can choose to either change the authentication type to MD5 or delete the corresponding SNMPv3 users to continue.

• Changing the container bridge IP address on Cisco APIC is supported only on Cisco APIC release 4.2(1) or later. If the container bridge IP address on Cisco APIC for AppCenter is configured with a non-default IP address, change it back the default 172.17.0.1/16 prior to downgrading to the older versions than 4.2(1).

• A static route (MO:mgmtStaticRoute) for Inband and/or Out-of-band EPG under Tenants > mgmt > Node Management EPGs is supported only on Cisco APIC release 5.1 or later. Delete this configuration and ensure the required service is still reachable via other means prior to the downgrade.

• Newly added microsegment EPG configurations must be removed before downgrading to a software release that does not support it.

• Downgrading the fabric starting with the leaf switch will cause faults such as policy-deployment-failed with fault code F1371.

• If you must downgrade the firmware from a release that supports FIPS to a release that does not support FIPS, you must first disable FIPS on the Cisco ACI fabric and reload all the switches in the fabric for the FIPS configuration change.

• If you have Anycast services configured in your Cisco ACI fabric, you must disable the Anycast gateway feature and stop Anycast services on external devices before downgrading from Cisco APIC 3.2(x) to an earlier release.

• CiscoN9K-C9508-FM-E2 fabric modules must be physically removed before downgrading to releases earlier than Cisco APIC 3.0(1). The same applies to any new modules for their respective supported version.

• If you are downgrading from Cisco APIC release 4.0(1) or later to release 3.2(x) or earlier, you may encounter a minor traffic drop in the fabric due to a difference in QoS classes supported between the releases. For more information, see CSCwa32037.

• If you have remote leaf switches deployed, and you downgrade the Cisco APIC software from release 3.1(1) or later to an earlier release that does not support the remote leaf switches feature, you must decommission the nodes before downgrading. For information about prerequisites to downgrading Remote Leaf switches, see the Remote Leaf Switches chapter in the Cisco APIC Layer 3 Networking Configuration Guide.

• If the following conditions are met:

  • You are running the 5.2(4) release and the Cisco APIC created one or more system-generated policies.

  • You downgrade the Cisco APIC from the 5.2(4) release, then later upgrade back to the 5.2(4) release.

  Then, one of the following behaviors will occur:

  • If the Cisco APIC finds a policy with the same name and parameters as a system-generated policy that it is trying to create, then the Cisco APIC will take ownership of the policy and you cannot modify the policy. This occurs if you did not modify the policy after downgrading from the 5.2(4) release.

  • If the Cisco APIC finds a policy with the same name as a system-generated policy that the Cisco APIC is trying to create, but the parameters are different, then the Cisco APIC will consider the policy to be a custom policy and you can modify the policy. This occurs if you modified the policy after downgrading from the 5.2(4) release.

  Because of this behavior, you should not modify the system-generated policies after you downgrade from the 5.2(4) release.

• If you are downgrading from a Cisco APIC release that supports the Transport Layer Security (TLS) version 1.3, you enabled TLS 1.3 in a management access policy, and the target Cisco APIC release does not support TLS 1.3, then you must disable TLS 1.3 and instead enable TLS 1.2.

• You must decommission an unsupported leaf switch that is connected to the Cisco APIC and move the cables to the other leaf switch that is part of the fabric before you downgrade the image.

• In the Cisco APIC 6.0(2) release or later, if the cluster's discovery mode is set to "strict" and you want to downgrade to any 4.2 release or earlier, you must first change the discovery mode "permissive."

• The APIC-M4/L4 server is supported in the Cisco APIC 6.0(2) release and later and 5.3(1) release and later. However, if you downgrade from the 6.0(2) or 6.0(3) release to a 5.3 release, you see a pre-upgrade validation warning that the APIC-M4/L4 server is not supported. In this case, you can ignore the warning.

  The following screenshot shows an example of this pre-upgrade validation warning: