Important Notes
Important Notes For Release 25.0(3)
Following are important notes for release 25.0(3) regarding the installation, upgrade or downgrade procedures for the Cisco Cloud Network Controller:
-
Because of the move from the Cisco Cloud Services Router 1000v to the Cisco Catalyst 8000V, you must add the necessary policy before upgrading from a release prior to 25.0(3) to release 25.0(3) or later:
-
Go to the infra tenant in the AWS portal.
-
Click
. -
In the Policies window, click the ApicAdminFullAccess policy.
The Summary page for this policy is displayed.
-
Click Edit Policy.
-
Click the JSON tab.
-
Copy the entry below and paste it into the policy:
{ "Effect": "Allow", "Action": "ssm:*", "Resource": "*" }
-
Click Review Policy, then click Save Changes.
-
-
The Cisco Catalyst 8000V supports subscription-based licensing. Before upgrading from a release prior to 25.0(3) to release 25.0(3), you must first subscribe to one of the tier-based Cisco Catalyst 8000V licenses.
-
For instructions on subscribing to one of the tier-based Cisco Catalyst 8000V licenses, see Cisco Catalyst 8000V Edge Software.
-
For more information on different throughputs based on the tiers, see Requirements for the AWS Public Cloud.
Cisco Cloud Network Controller makes use of the “Cisco DNA Advantage” subscription. For features supported by the “Cisco DNA Advantage” subscription, see Cisco DNA SoftwareSD-WAN and Routing Matrices.
-
-
When you upgrade your Cisco Cloud Network Controller to release 25.0(3), you should then upgrade the CCRs as soon after the Cisco Cloud Network Controller upgrade as possible. For those instructions, see:
Following are examples of how you would go through these upgrade processes:
-
Single-Site Upgrade: You normally would not need to have CCRs for a single-site AWS deployment. However, if you do have CCRs deployed in this situation, once the Cisco Cloud Network Controller has completed the upgrade to release 25.0(3) and reached the ready state, you must then start the upgrade of the older CCRs (the Cisco Cloud Services Router 1000v) to the newer CCRs (the Cisco Catalyst 8000V) before making any configuration changes.
-
Multi-Cloud/Hybrid-Cloud Upgrade: As an example of this upgrade process, assume that you have the following setup:
-
Site 1: AWS
-
Site 2: Azure
-
Site 3: On-premises site
You would then upgrade these sites the following way:
-
Upgrade Nexus Dashboard Orchestrator to the 3.7(1) release.
-
Upgrade site 1 (AWS site) to the Cisco Cloud Network Controller release 25.0(3) using the procedures in Upgrading the Software.
Wait until this upgrade has reached the steady state before proceeding to the next step.
-
Upgrade the CCRs on site 1 (AWS site) from the older CCRs (the Cisco Cloud Services Router 1000v) to the newer CCRs (the Cisco Catalyst 8000V) using the procedures in Triggering an Upgrade of the CCRs.
Wait until the CCRs are fully upgraded to the newer Cisco Catalyst 8000Vs before proceeding to the next step.
-
Once the CCRs on site 1 (AWS site) are fully upgraded, repeat these steps for site 2 (Azure site), where you will first upgrade the Cisco Cloud Network Controller software to release 25.0(3). After that upgrade has reached the steady state, then you will upgrade the CCRs on site 2 to the newer Cisco Catalyst 8000Vs.
-
-
-
Prior to Cisco Cloud Network Controller release 25.0(3), the older Cisco Cloud Services Router 1000v routers were configured with number-based throughput, as described in Requirements for the AWS Public Cloud. Since the Cisco Catalyst 8000V routers will only support tier-based throughput options, during upgrades to release 25.0(3), the Cisco Cloud Network Controller will map the throughput values from the number-based throughput used by the older Cisco Cloud Services Router 1000v routers to the tier-based throughput used by the newer Cisco Catalyst 8000V routers.
The following table shows the mapping of throughput from the older Cisco Cloud Services Router 1000v routers to the newer Cisco Catalyst 8000V routers during an upgrade:
Throughput on Cisco Cloud Services Router 1000v
Throughput on Cisco Catalyst 8000V
10M
T0 (up to 15M throughput)
50M
T1 (up to 100M throughput)
100M
T1 (up to 100M throughput)
250M
T2 (up to 1G throughput)
500M
T2 (up to 1G throughput)
1G
T2 (up to 1G throughput)
2.5G
T3 (up to 10G throughput)
5G
T3 (up to 10G throughput)
7.5G
T3 (up to 10G throughput)
10G
T3 (up to 10G throughput)
When migrating from the older Cisco Cloud Services Router 1000v routers to the newer Cisco Catalyst 8000V routers during an upgrade, the Cisco Cloud Network Controller will migrate the comparable bandwidth as described above. When these Cisco Catalyst 8000V routers come up, they will try to register for that bandwidth to the smart licensing account. If the smart licensing server does not have these licenses, then the Cisco Catalyst 8000V will fall back to the default bandwidth and will fail to service the existing workload traffic. So you must procure and provision the required Cisco Catalyst 8000V licenses in your smart account before migrating from the older Cisco Cloud Services Router 1000v routers to the newer Cisco Catalyst 8000V routers during an upgrade.
-
Similarly, when downgrading from release 25.0(3) to an earlier release, the Cisco Cloud Network Controller will map the throughput values from the tier-based throughput used by the newer Cisco Catalyst 8000V routers to the number-based throughput used by the older Cisco Cloud Services Router 1000v routers.
The following table shows the mapping of throughput from the newer Cisco Catalyst 8000V routers to the number-based throughput used by the older Cisco Cloud Services Router 1000v routers during a downgrade:
Throughput on Cisco Catalyst 8000V
Throughput on Cisco Cloud Services Router 1000v
T0 (up to 15M throughput)
10M
T1 (up to 100M throughput)
100M
T2 (up to 1G throughput)
1G
T3 (up to 10G throughput)
10G
Note
Do not make any configuration changes when the Cisco Cloud Network Controller and the CCRs are in incompatible mode. When upgrading to release 25.0(3), verify that both the Cisco Cloud Network Controller and the CCRs are upgraded to that latest release before making any configuration changes.
General Important Notes
Following are general important notes:
-
Cisco Cloud Network Controller supports policy-based upgrades for the following upgrade paths:
-
Release 5.2(1) to 25.0(5)
-
Release 25.0(1) to 25.0(5)
-
Release 25.0(2) to 25.0(5)
-
Release 25.0(3) to 25.0(5)
-
Release 25.0(4) to 25.0(5)
-
-
When you downgrade from release 5.0(x) to a previous release, as the CCRs downgrade to a lower release, you could see some of the tunnels in a “down” state in the CCRs. This could occur due to stale VPN resources in the AWS accounts that did not get cleaned up.
To correct this issue, manually clean up the stale VPN connections.
-
As noted in Requirements for the AWS Public Cloud, the supported instance type for the Cisco Cloud Network Controller deployment has changed for release 5.0(x) or later:
-
For releases prior to release 5.0(x), Cisco Cloud Network Controller is deployed using the m4.2xlarge instance.
-
For release 5.0(x) and later, Cisco Cloud Network Controller is deployed using the m5.2xlarge instance.
When upgrading from a 4.2(x) release to release 5.0(x) or later, policy-based upgrades are not supported because you cannot change the instance type through a policy-based upgrade; instead, for these upgrades, you must upgrade using a migration procedure, as provided in Migration-Based Upgrade.
-
-
There is an issue with the upgrade process where an upgrade from release 5.2(1g) to any later release will fail.
To work around this issue, enable the Ignore Compatibility Check option:
-
Follow the normal upgrade instructions provided in Upgrading the Software Using the Policy-Based Upgrade Process until you get to the Ignore Compatibility Check step in the Schedule Upgrade window.
-
Enter a check mark in the box next to the Ignore Compatibility Check field to enable the Ignore Compatibility Check option.
Enabling the Ignore Compatibility Check option allows this specific upgrade to proceed normally.
-
Complete the upgrade to the post-5.2(1g) release.
-
Once you have completed the upgrade to the post-5.2(1g) release, return to the Schedule Upgrade window and remove the check mark in the box next to the Ignore Compatibility Check field.
This disables the Ignore Compatibility Check option, which is the default setting for this field.
-
-
Due to the issue described in the previous bullet, if you are upgrading from a release prior to release 5.2(1) to a 5.2(1) release, we recommend that you upgrade directly to release 5.2(1h) and not release 5.2(1g).