Cisco Nexus Dashboard User Guide, Release 2.3.x

Open your browser, navigate to the CIMC IP address, and log in using the CIMC credentials.

Note that the CIMC credentials may be different from the Nexus Dashboard GUI credentials.

Determine the model of UCS platform for your Nexus Dashboard by locating the first part of the BIOS version under Server > Summary .

Nexus Dashboard supports the UCS-C220-M5 and UCS-C225-M6 servers.

If necessary, clear the existing logs.

Download the appropriate HUU ISO image.

Launch the KVM console from CIMC GUI.

Note If you are unable to open the KVM console, you may need to update Java version.

Mount the HUU ISO image you downloaded in Step 3.

From KVM console’s Power menu, choose Power Cycle System to reboot the server.

As the server is starting up, press F6 to enter the boot menu and choose the Cisco vKVM-Mapped vDVD.

When prompted to accept Cisco Software License Agreement, choose Accept.

In the Update & Activate All dialog, choose Update & Activate.

You can verify that the upgrade was completed successfully through the GUI or by booting up the CIMC HUU and selecting the Last Update Verify option to ensure that all of the components were upgraded successfully.

After upgrade is completed, ensure that Trusted Platform Module State (TPM) is enabled.

You can check and enable it in the BIOS > Configure BIOS > Security menu.

Log in to the nodes you want to upgrade as rescue-user.

Copy the upgrade ISO image file into the /tmp directory on each node.

Start the upgrade on all nodes.

You can upgrade all nodes in parallel.

# acs installer update -f /tmp/nd-dk9.2.1.1a.iso
Warning: This command will initiate node update to new version.
Proceed? (y/n): y
Update in Progress ... Do not press Ctrl^C

Wait for the upgrade to complete.

Note You must wait for all nodes to finish upgrading before proceeding to the next step.

Update succeeded, reboot your host

Reboot one of the nodes.

Ensure that the upgrade is completed on all nodes as mentioned in the previous step before restarting any one node.

# acs reboot
This command will restart this device, Proceed? (y/n): y

Verify the node is healthy.

# acs health
All components are healthy

After the first node is successfully upgraded and healthy, reboot the other two nodes one at a time.

Note You must wait for the rebooted node to come up and ensure that the node is healthy using the acs health command before restarting the next node.

Once all nodes are up running the new version and are healthy, run post-upgrade tasks.

You can run the following command on all nodes in parallel.

# acs installer post-update
Warning: This command will run the post-update scripts. Proceed? (y/n): y
Update in Progress ... Do not press Ctrl^C
Post-update succeeded

Wait for the post-upgrade tasks to complete.

During this stage, the UI will show the progress, which looks similar to the initial cluster deplyment. After the post-upgrade processes finish, you will be able to log in to the node as usual.

Back up the Nexus Dashboard cluster configuration as described in Backup and Restore.

Back up the configuration for all services deployed in your cluster.

For NDO, see Operations > Backup and Restore in the Nexus Dashboard Orchestrator Configuration Guide.

For NDI, see Operations > Backup and Restore in the Nexus Dashboard Insights User Guide.

For NDFC, see Operations > Backup and Restore in the NDFC Fabric Controller Configuration Guide.

If your cluster is deployed as a physical appliance…​

If your cluster is deployed in virtual machines (VMs)…​

Restore Nexus Dashboard configuration as described in [Backups and Restore].

Install the service(s) you had deployed previously as described [Service Management].

Restore each service’s configuration from the backups you created in Step 1.

For NDO, see Operations > Backup and Restore in the Nexus Dashboard Orchestrator Configuration Guide.

For NDI, see Operations > Backup and Restore in the Nexus Dashboard Insights User Guide.

For NDFC, see Operations > Backup and Restore in the NDFC Fabric Controller Configuration Guide.

Navigate to your Nexus Dashboard’s Admin Console.

From the main navigation menu, select System Resources > Nodes.

From the (…​) menu next to the node, choose Edit Node.

Note that you can only change the IP address of a node that you are not currently logged in to. To change the IP of the current node, navigate to a different node’s management IP address, log in, and repeat this procedure for the last node.

Update the Management Network Address and Management Network Gateway for the node.

For example, 172.31.140.58/24 and 172.31.140.1 respectively.

Click Save.

The changes will take effect immediately and you can access the nodes using the new IP addresses.

Log in to your RHEL system using the Nexus Dashboard user you provided in the YAML configuration file during installation.

Run the attach-nd command to access the Nexus Dashboard environment.

/usr/bin/attach-nd

After you access the Nexus Dashboard environment, you can use all the common Nexus Dashboard commands described in the Troubleshooting section of this guide.

Log in to your Nexus Dashboard cluster.

Navigate to Admin Console > Sites

From the Actions (…​) menu next to the site, select Edit Site.

In the Site Edit screen, check the Re-register Site checkbox and provide the site details again.

Click Save.

Ensure that the node is reset to factory settings.

If the node is in a bad state, log in to the node as rescue-user and reset the node using the following command:

# acs reboot factory-reset

Log in to the Nexus Dashboard GUI using the management IP address of one of the healthy nodes.

Navigate to System Resoruces > Nodes.

The node you want to replace will be listed as Inactive in the UI.

From the actions (…​) menu for the node, select Register.

Register Node page will open.

In the Register Node page, provide the required information and click Validate.

For physical nodes, you need to provide the CIMC IP address and login information.

For virtual nodes, the management IP address will be retained and you need to provide only the password for the rescue-user.

Ensure the rest of the node information is accurate.

Click Register to re-register the node and re-add it as a master node to the cluster.

It will take up to 20 minutes to bootstrap, configure, and re-add the node. After it’s done, the node will show as an Active master node in the UI.

Ensure that the failed node’s VM is powered down.

Bring up a new Nexus Dashboard node.

Bringing up an additional node in VMware ESX is described in Deploying Additional Virtual Nodes in VMware ESX. Note that you must bring up a node of the same type (OVA-App or OVA-Data) as the node you are replacing.

Bringing up an additional node in Linux KVM is described in Deploying Additional Virtual Nodes in Linux KVM.

Note Ensure that you use the same exact network configuration settings as you used for the failed node.

Power on the new node’s VM and wait for it to boot up.

Log in to the Nexus Dashboard GUI.

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

Replace the node.

Log in to your Nexus Dashboard GUI using the management IP of one of the other master nodes.

From the main navigation menu, select System Resources > Nodes.

In the nodes list, find the Serial number of the node you want to replace and ensure that the node’s Status shows Inactive.

In the Nexus Dashboard’s Nodes screen, select the inactive node by clicking the checkbox next to it.

From the Actions menu, select Replace.

In the New Serial Number field, provide the serial number of the new node and click Replace.

After the process is completed, you will see the serial number of the old node updated to the new node’s serial number and the status will change to Active once the new master has successfully joined the cluster.

Navigate to your Nexus Dashboard’s Admin Console.

From the main navigation menu, select System Resources > Nodes.

In the nodes list, find the Serial number of the node you want to replace and ensure that the node’s Status shows Inactive.

Select the inactive node by clicking the checkbox next to it.

From the Actions menu, select Delete.

This will remove the failed node from the list.

Power on the new node and add it as a new worker or standby node to the cluster as described in Managing Worker Nodes or Managing Standby Nodes.

You can use the same configuration parameters as you used to set up the old node.

Generate private key.

You can generate the private key on any platform that has OpenSSL installed or you can SSH into one of your Nexus Dashboard nodes as the rescue-user and perform these steps there.

[rescue-user@localhost ~]$ openssl genrsa -out nd.key 2048
Generating RSA private key, 2048 bit long modulus
........................
.............
e is 65537 (0x10001)
[rescue-user@localhost ~]$ ls
nd.key

Generate your CSR signed with the private key you generated in the first step.

Obtain a CA-signed certificate.

In production deployments, you will provide the CSR (ca.csr) from the previous step to a public CA, such as IdenTrust or DigiCert, to obtain the CA-signed certificate (ca.crt).

Verify the signed certificate.

The following command assumes you copied the CA-signed certificate (ca.crt) into the same folder as the private key you generated.

[rescue-user@localhost ~]$ openssl verify -verbose -CAfile ca.crt nd.crt
nd.crt: OK

Add the contents of the generated files in your Nexus Dashboard’s GUI.

Following the steps described in Security Configuration, where you will need to provide the contents of the following 3 files generated in the previous steps:

Generate private key.

You can generate the private key on any platform that has OpenSSL installed or you can SSH into one of your Nexus Dashboard nodes as the rescue-user and perform these steps there.

[rescue-user@localhost ~]$ openssl genrsa -out nd.key 2048
Generating RSA private key, 2048 bit long modulus
........................
.............
e is 65537 (0x10001)
[rescue-user@localhost ~]$ ls
nd.key

Generate Certificate Authority (CA) key.

To generate a self-signed CA, for example for lab and testing purposes, run the following command:

[rescue-user@localhost ~]$ openssl genrsa -out ca.key 2048
Generating RSA private key, 2048 bit long modulus
..................
.............
e is 65537 (0x10001)
[rescue-user@localhost ~]$ ls
ca.key  nd.key

Generate CSR for the CA.

[rescue-user@localhost ~]$ openssl req -new -key ca.key -subj "/CN=Self/C=US/O=Private/ST=Texas" -out ca.csr
[rescue-user@localhost ~]$ ls
ca.csr  ca.key  nd.key

You can view the generated CSR using the following command:

[rescue-user@localhost ~]$ openssl req -in ca.csr -text -noout

Create self-signed root certificate.

[rescue-user@localhost ~]$ openssl x509 -req -in ca.csr -signkey ca.key -CAcreateserial -out ca.crt -days 3650
Signature ok
subject=/CN=Self/C=US/O=Private/ST=Texas
Getting Private key
[rescue-user@localhost ~]$ ls
ca.crt  ca.csr  ca.key  nd.key

You can view the generated root certificate using the following command:

[rescue-user@localhost ~]$ openssl x509 -in ca.crt -text -noout

Generate your CSR signed with the private key you generated in the first step.

Self-sign the certificate you generated.

[rescue-user@localhost ~]$ openssl x509 -req -in nd.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out nd.crt -days 3600
Signature ok
subject=/C=US/ST=Texas/L=Plano/O=CSS/OU=DC/CN=nd.dc.css/emailAddress=no-reply@mydomain.com
Getting CA Private Key
[rescue-user@localhost ~]$ ls
ca.crt  ca.csr  ca.key  ca.srl  csr.cfg  nd.crt  nd.csr  nd.key

Verify the signed certificate.

[rescue-user@localhost ~]$ openssl verify -verbose -CAfile ca.crt nd.crt
nd.crt: OK

Add the contents of the generated files in your Nexus Dashboard’s GUI.

Following the steps described in Security Configuration, where you will need to provide the contents of the following 3 files generated in the previous steps: