Step 1

Download and verify the configuration validation script.

1. Ensure that you have Python installed on your local machine.

   The script requires Python 3 to run. You can check if Python is installed on your machine using the following command:

   $ python3 --version
   Python 3.9.6

2. Download and extract the validation script tarball.

   Navigate to https://software.cisco.com/download/home/285968390/type/286317465, select the target NDO version to which you want to upgrade, download the upgrade validation script (Final_ndo<version>-UpgradeValidationScript.tgz), then extract it, for example:

   $ tar -xzf Final_ndo<version>-UpgradeValidationScript.tgz
   $ ls
   ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM
   Final_ndo4.1.2h-UpgradeValidationScript.tgz
   UpgradeValidationScript.tgz
   UpgradeValidationScript.tgz.signature
   cisco_x509_verify_release.py3

3. Verify the validation script tarball signature.

   You can use the following command to verify the Cisco signature on the configuration validation script.

   $ ./cisco_x509_verify_release.py3 -e ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM \
     -i UpgradeValidationScript.tgz -s UpgradeValidationScript.tgz.signature -v dgst -sha512
   Retrieving CA certificate from https://www.cisco.com/security/pki/certs/crcam2.cer ...
   Successfully retrieved and verified crcam2.cer.
   Retrieving SubCA certificate from https://www.cisco.com/security/pki/certs/innerspace.cer ...
   Successfully retrieved and verified innerspace.cer.
   Successfully verified root, subca and end-entity certificate chain.
   Successfully fetched a public key from ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM.
   Successfully verified the signature of UpgradeValidationScript.tgz using ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM

   Note

   If signature verification fails, you will receive the following error: $ ./cisco_x509_verify_release.py3 -e ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM\ -i UpgradeValidationScript.tgz -s UpgradeValidationScript.tgz.signature.fail -v dgst -sha512 Retrieving CA certificate from https://www.cisco.com/security/pki/certs/crcam2.cer ... Successfully retrieved and verified crcam2.cer. Retrieving SubCA certificate from https://www.cisco.com/security/pki/certs/innerspace.cer ... Successfully retrieved and verified innerspace.cer. Successfully verified root, subca and end-entity certificate chain. Successfully fetched a public key from ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM. Error log: Failed to verify dgst signature of UpgradeValidationScript.tgz. Error log: Verification Failure In this case, we recommend you re-download the <ndo-version>-UpgradeValidationScript.tgz tarball from the Cisco Software Download portal.

4. Once the validation script signature is verified, extract the script itself.

   % tar -xzf UpgradeValidationScript.tgz
   $ ls
   ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM
   Final_ndo4.1.2h-UpgradeValidationScript.tgz
   README.md
   UpgradeValidationScript.tgz
   UpgradeValidationScript.tgz.signature
   cisco_x509_verify_release.py3
   ndo
   ndoCmd.py
   ndoCopy.py
   requirements.txt

Step 2

Validate your existing configuration before you create the backup.

1. Log in to your Nexus Dashboard and open the Nexus Dashboard Orchestrator service.

2. Download the tech support logs from your existing Orchestrator.

   While for the migration you will create and download the configuration backup using the standard procedure, the validation is done on the tech support information. Note that it is normal for the tech support archive to be significantly larger than your typical configuration backup.

   You can generate the tech support logs by navigating to Admin > Tech Support page in the Orchestrator UI. Then click the Download icon in the System Logs tile. This downloads the msc_report_<date>.zip archive to your machine.

3. Extract the tech support archive you downloaded.

   The tech support archive comes in a standard .zip format, so you can use any tool of your choice to extract the contents, for example:

   $ unzip msc_report_<date>.zip

   After you extract the archive, copy the msc-db-json-<date>_temp.tar.gz file inside into the directory where you extracted the validation script.

4. Run the validation script.

   The script requires a number of dependencies, which are all defined in the requirements.txt file that comes with the script, so we recommend creating a Python virtual environment before installing the dependencies and running the script:

   $ python -m venv ndo-upgrade
   $ source ndo-upgrade/bin/activate
   $ pip install -r requirements.txt

   After the virtual environment is set up and the required modules are installed, run the script using the tech support file you downloaded and extracted in a previous step, for example:

   • -f allows you to provide the file on which to run the validation.

   • -N specifies that no configuration will be deployed to any live system.

   • -C generates the JSON-formatted output at the end of the script.

   (ndo-upgrade)ndoCmd $ ./ndoCopy.py -f msc_report_20220617_181529/msc-db-json-20220617181553_temp.tar.gz -N -C
   11:49:56 Loading collection site2...4
   11:49:56 Loading collection tenant...12
   [...]
   11:49:56 Checking template versions
   11:49:56 Checking policy deployment dependencies
   11:49:56 Fixing template policy flow loops
   11:49:56 Fixing template dependency loops
   11:49:56 Fixing policies for upgrade
   11:49:56 Determine template ordering
   11:49:56 Analysis completed
   {
     "summaryStats": {
       "appTemplatePoliciesConverted": 139,
       "appTemplateSiteAssocMods": 7,
       "appTemplatePolicyEvictions": 2,
       "appTemplateSchemasConverted": 11,
       "appTemplatesConverted": 38,
       "appTemplatesCreated": 1,
       "tenantMods": 1
     },
   [...]
   }

   After the output is generated:

   • If there are no errors or warnings blocks at the end of the generated JSON, then your configuration is compliant with the migration requirements and you can proceed to the "Back up existing deployment configuration" step.

   • If there is only a number of warnings but no errors, it means the migration will complete successfully, but there's a number of things that you may want to resolve before or after the upgrade. We recommend reviewing any warnings before continuing with the next step.

       "warnings": [
         "dropped DHCP Relay policy dhcp-tn-epgOnRL-policy: invalid provider ip address: 141.1.141.2/24",
         "dropped Route Map policy sameContract: fromPrefixLen and toPrefixLen must be larger than prefix",
         "dropped Mulicast Route Map policy mCastRt.map: invalid RP ip: 12.13.14.15/23",
         "dropped DHCP Option policy dhcpBdMso-option: duplicate option id: 1; duplicate option id: 1",
         "removed dhcpLabels.0 from bd[tn-epgOnRL::Template 1::bdDhcpClient] for 
     unresolved policy ref key[dhcpRelayPolicies::tn-epgOnRL::dhcp-tn-epgOnRL-policy]",
         "removed dhcpLabels.0 from bd[dhcp-msite-mso::bd::bd-client-l3out] for 
     unresolved policy ref key[dhcpRelayPolicies::dhcp-msite-mso::dhcp-msite-mso-relay-policy-epg-cleint-l3out]"
       ], 

   • If there is 1 or more errors listed in the JSON, the migration would fail if you continue with the current configuration.

     Note	You must resolve any existing errors before creating the backup and proceeding with the upgrade. We recommend re-running the validation script after you resolve any existing errors to ensure that the backup will be ready for the migration.

     For example, the following sample shows 2 possible errors that can come up during validation:

     "errors": [
       "template appTemplate[<template>] version 6 is in state EDIT_CONFIG",
       "deployed policy bd[<bd>] requires vrf[<vrf>] which is not deployed",
     ] 

     • As mentioned in the Prerequisites and Guidelines section, any deployed templates must not have undeployed changes. You must either deploy the latest version of that template or revert to the deployed version (so it is the latest version) and re-deploy the template.

     • Objects must be deployed in order of their dependencies. In other words, you must not have a deployed bridge domain if the required VRF is not deployed.

5. Resolve any shown errors and repeat this step to re-validate the configuration.

Step 1

Download the Nexus Dashboard image.

1. Browse to the Software Download page.

   https://software.cisco.com/download/home/286327743/type/286328258

2. Choose the Nexus Dashboard version you want to download.

3. Download the Cisco Nexus Dashboard image (nd-dk9.<version>.iso).

   Note	You must download the .iso image for all upgrades, even if you used the VMware ESX .ova image or a cloud provider's marketplace for initial cluster deployment.

4. (Optional) Host the image on a web server in your environment.

   When you upload the image to your Nexus Dashboard cluster, you will have an option to provide a direct URL to the image.

Step 2

Log in to your current Nexus Dashboard GUI as an Administrator user.

Step 3

Disable all installed services in the cluster.

Step 4

Upload the new Nexus Dashboard image to the cluster.

Note	Note that the UI may differ slightly across different Nexus Dashboard releases, but the navigation remains the same.

1. Navigate to Operations > Firmware Management.

2. Select the Images tab.

3. From the Actions menu, select Add Image.

Step 5

Select the new image.

1. In the Add Firmware Image window, select Local.

   Alternatively, if you hosted the image on a web server, choose Remote instead.

2. Click Select file and select the ISO image you downloaded in the first step.

   If you chose to upload a remote image, provide the file path for the image on the remote server.

3. Click Upload to add the image.

   The image will be uploaded to the Nexus Dashboard cluster, unpacked, processed, and made available for the upgrade. The whole process may take several minutes and you will be able to see the status of the process in the Images tab.

Step 6

Wait for the image status to change to Downloaded.

Step 7

Set up the update.

1. Navigate to Operations > Firmware Management.

2. Select the Updates tab.

3. Click Setup Update.

   The Firmware Update screen opens.

Step 8

Choose the upgrade image.

1. In the Firmware Update > Version selection screen, select the firmware version you uploaded and click Next.

2. In the Firmware Update > Confirmation screen, verify the details and click Begin Install.

   The installation progress window is displayed. You can navigate away from this screen while the update is in progress. To check on the update status at a later time, navigate to the Firmware Management screen and click View Details in the Last Update Status tile.

   This will set up the required Kubernetes images and services but will not switch the cluster to the new version. The cluster will continue to run the existing version until you activate the new image in the next step. The entire process may take up to 20 minutes.

Step 9

Activate the new image.

1. Navigate back to the Operations > Firmware Management screen

2. In the Last Update Status tile, click View Details.

3. Click Activate.

4. In the Activation Confirmation window, click Continue.

   It may take up to 20 additional minutes for all the cluster services to start and the GUI to become available. The page will automatically reload when the process is completed.

Step 10

If you upgraded a virtual cluster deployed in VMware ESX, convert the nodes to the new profile.

1. Bring down one of the nodes.

   You must replace one node at a time.

2. Deploy a new node in VMware ESX using the App or Data profile OVA.

   When deploying the new node, you must use the same exact network configuration parameters as the node you are replacing.

3. Log in to the existing Nexus Dashboard GUI.

   You can use the management IP address of one of the remaining healthy master nodes.

4. From the left navigation pane, select System Resources > Nodes.

   The node you are replacing will be listed as Inactive.

5. Click the (...) menu next to the inactive master node you want to replace and select Replace.

   The Replace window will open.

6. Provide the Management IP Address and Password for the node, then click Verify.

   The cluster will connect to the new node's management IP address to verify connectivity.

7. Click Replace.

   It may take up to 20 minutes for the node to be configured and join the cluster.

8. Wait for the cluster to become healthy, then repeat this step for the other two nodes.

Step 11

After the upgrade is successful, delete the upgrade image you had uploaded.

Step 12

If you are upgrading across multiple hops, repeat these steps for each upgrade one at a time.

Step 1

Log in to your Nexus Dashboard.

Step 2

From the left navigation menu, select Services.

Step 3

Re-enable the existing version of Nexus Dashboard Orchestrator.

Step 4

Upgrade the application using the App Store.

1. In the Services screen, select the App Store tab.

2. In the Nexus Dashboard Orchestrator tile, click Upgrade.

3. In the License Agreement window that opens, click Agree and Download.

Step 5

Wait for the new image to initialize.

Step 6

Activate the new image.

1. In the Services page, select the Installed Services tab.

2. In the top right corner of the Nexus Dashboard Orchestrator tile, click the menu (...) and choose Available Versions.

3. In the available versions window, click Activate next to the new image.

   Note	Do not Disable the currently running image before activating the new image. The image activation process will recognize the currently running image and perform the upgrade workflows necessary for the currently running version.

   It may take up to 20 additional minutes for all the application services to start and the GUI to become available. The page will automatically reload when the process is completed.

Step 7

Delete the old service image.

1. In the Services page, select the Installed Services tab.

2. In the top right corner of the Nexus Dashboard Orchestrator tile, click the menu (...) and choose Available Versions.

3. In the available versions window, click the delete icon next to the image you want to delete.

Step 1

Download the target NDO release image.

1. Browse to the Nexus Dashboard Orchestrator page on DC App Center:

   https://dcappcenter.cisco.com/nexus-dashboard-orchestrator.html

2. From the Version dropdown, choose the version you want to install and click Download.

3. Click Agree and download to accept the license agreement and download the image.

Step 2

Log in to your Nexus Dashboard.

Step 3

Re-enable the existing version of Nexus Dashboard Orchestrator.

Step 4

Upload the new NDO image to your Nexus Dashboard.

1. From the left navigation menu, select Services.

2. In the Nexus Dashboard's Services screen, select the Installed Services tab.

3. From the Actions menu in the top right of main pane, select Upload App.

4. In the Upload App window, choose the location of the image

   If you downloaded the application image to your system, choose Local.

   If you are hosting the image on a server, choose Remote.

5. Choose the file.

   If you chose Local in the previous substep, click Select File and select the app image you downloaded.

   If you chose Remote, provide the full URL to the image file, for example http://<ip-address>:<port>/<full-path>/cisco-mso-<version>.nap.

6. Click Upload to add the app to the cluster.

   A new tile will appear with the upload progress bar. Once the image upload is completed, the Nexus Dashboard will recognize the new image as an existing application and add it as a new version.

Step 5

Wait for the new image to initialize.

Step 6

Activate the new image.

1. In the OperateServices page, select the Installed Services tab.

2. In the top right corner of the Nexus Dashboard Orchestrator tile, click the menu (...) and choose Available Versions.

3. In the available versions window, click Activate next to the new image.

   Note	Do not Disable the currently running image before activating the new image. The image activation process will recognize the currently running image and perform the upgrade workflows necessary for the currently running version.

   It may take up to 20 additional minutes for all the application services to start and the GUI to become available. The page will automatically reload when the process is completed.

Step 7

Delete the old service image.

1. In the Services page, select the Installed Services tab.

2. In the top right corner of the Nexus Dashboard Orchestrator tile, click the menu (...) and choose Available Versions.

3. In the available versions window, click the delete icon next to the image you want to delete.

Step 1

Open the Orchestrator service UI.

Step 2

Finalize database upgrade.

1. Ensure that there are no failures listed in the report, then click Restore and Continue to proceed.

   Before the configuration database is updated for this release, the upgrade process performs a number of validations. The validation provides a summary of template and policy changes that are performed during this final upgrade stage in the next step and includes the following:

   • Implicit template stretching – if one or more objects are implicitly stretched, the upgrade process will create new explicitly-stretched templates and move the objects into those templates.

     For example, if you have a template (t1) that contains vrf1 and is associated to site1 and another template (t2) that contains a BD that references vrf1 but is associated to two sites (site1 and site2), then vrf1 will be implicitly stretched between the two sites.

     This is no longer allowed starting with release 4.0(1) and the VRF must be explicitly stretched to both sites. In such cases during the upgrade, the VRF will be either moved to a different template which will be explicitly stretched between both sites or the original template will be associated with both sites, depending on whether the other policies in that template require stretching as well.

     Any templates that are created in this case will be named UpgradeTemplate%d, where %d is an incrementing number starting with 1 to ensure that all newly added templates are unique.

   • Global policy migration – all global tenant policies (such as DHCP relay or route maps) and fabric policies (such as QoS) will be moved into the new tenant and fabric policy templates that have been added in release 4.0(1).

   This is the stage of the upgrade where the existing schemas and templates are recreated in your NDO configuration database according to the current best practices. These schemas and templates are then posted to the local NDO database as if it were a greenfield schema/template creation. Then the newly saved templates are deployed in the correct order that conforms to the current deployment requirements and best practices. The template deployment in this step uses a “local deploy” option to calculate the deployment plan and update the database, but does not send any configuration payload to the sites' controllers.

   The upgrade process also checks for any configuration drifts between the local NDO database (configuration that is correct from NDO's point of view) and what is actually deployed in the fabrics. If this release of NDO supports additional objects or properties compared to the release from which you are upgrading, the upgrade will automatically reconcile those drifts by importing the existing configuration from the site's controller.

2. Review the report from the previous substep and click Ok to finish.

   The final stage of the database upgrade presents a full report of the performed actions for you to review. If you close the report but want to review it again, simply click the View Restore Report in the Backups page.

Step 3

Verify that backup was restored successfully and all objects and configurations are present.

1. In the Sites page, verify that all sites are listed as Managed.

2. In the Tenants and Schemas pages, confirm that all tenants and schemas from your previous Nexus Dashboard Orchestrator cluster are present.

3. Navigate to Infrastructure > Site Connectivity and confirm that intersite connectivity is intact.

   In the main pane, click Show Connectivity Status next to each site and verify that the existing tunnels are up and connectivity was not interrupted.

4. In the main pane, click Configure to open Fabric Connectivity Infra screen and verify External Subnet Pool addresses.

   You can view the external subnet pools by selecting General Settings > IPsec Tunnel Subnet Pools tab of the Fabric Connectivity Infra screen and verify that the External Subnet Pools previously configured in Cloud Network Controller have been imported from the cloud sites.

   These subnets are used to address the IPsec tunnel interfaces and loopbacks of the Cloud Routers used for on-premises connectivity and had to be configured directly in the Cloud Network Controller in earlier Nexus Dashboard Orchestrator releases.

Step 4

Check for and resolve any configuration inconsistencies in your templates. The inconsistencies will be displayed as a warning message in a bulleted list.

1. Navigate to your schemas and check for any templates marked with a warning. Click on the ellipsis (…​) at the restored file location to view the error message.

2. Open a template that contains a warning and resolve any configuration inconsistencies.

3. Save and deploy the template.

4. Repeat these steps for all templates that have a warning.

Step 1

In your Nexus Dashboard Orchestrator, navigate to Operate > Tenant Templates.

Step 2

Choose the Applications tab.

Step 3

Select the first schema and check its templates for configuration drifts.

Step 4

If the template contains a configuration drift, resolve the conflicts.

1. Close the template deployment dialog to return to the Schema view.

   Deploying any templates at this point would push the values in the Orchestrator database and overwrite any existing settings in the fabrics.

2. From the template's Actions menu, select Drift Reconciliation.

   The Drift Reconciliation wizard opens.

3. In the Drift Reconciliation screen, compare the template-level configurations for each site and choose the one you want.

   Template-level properties are common across all sites associated to the template. You can compare the template level properties defined on Nexus Dashboard Orchestrator with the configuration rendered in each site and decide what should become the new configuration in the Nexus Dashboard Orchestrator template. Selecting the site configuration will modify those properties in the existing Nexus Dashboard Orchestrator template, whereas selecting the Nexus Dashboard Orchestrator configuration will keep the existing Nexus Dashboard Orchestrator template settings as is

4. Click Go to Site Specific Properties to switch to site-level configuration.

   You can choose a site to compare that specific site's configuration. Unlike template-level configurations, you can choose either the Nexus Dashboard Orchestrator-defined or actual existing configurations for each site individually to be retained as the template's site-local properties for that site.

   Even though in most scenarios you will make the same choice for both template-level and site-level configuration, the drift reconciliation wizard allows you to choose the configuration defined in the site's controller at the "Template Properties" level and the configuration defined in Nexus Dashboard Orchestrator at the "Site Local Properties" level or vice versa.

5. Click Preview Changes to verify your choices.

   The preview will display full template configuration adjusted based on the choices picked in the Drift Reconciliation wizard

6. Save the schema.

7. Click Deploy to sites to deploy the configuration and finish reconciling the drift for that template

Step 5

Repeat the above steps for every schema and template in your Nexus Dashboard Orchestrator.

Step 6

Check audit logs to verify that all templates have been re-deployed.