Chapter 1. New and Changed Information

- New and Changed Information

New and Changed Information

The following table provides an overview of the significant changes to the organization and features in this guide from the release the guide was first published to the current release. The table does not provide an exhaustive list of all changes made to the guide.

Latest Updates

Release

New Feature or Update

Where Documented

3.7(1)

First release of this document.

--

Chapter 2. GUI Overview

- Overview

- Dashboard

- Application Management > Tenants Page

- Application Management > Schemas Page

- Infrastructure > Sites Page

Overview

The Nexus Dashboard Orchestrator (NDO) GUI is a browser-based graphical interface for configuring and monitoring your Cisco APIC, Cloud APIC, and DCNM deployments.

The GUI is arranged according to function. For example, the Dashboard page contains an overview of your fabrics and their health, the Sites page provides information on each site and allows you to add sites, the Schemas page allows you to create and configure schemas, and so on. The functionality of each NDO GUI page is described in the following sections.

The top of each page shows the controller status indicating how many controllers are operational, the Get Started menu icon, the Settings icon, and the User icon.

The Get Started menu provides easy access to a number of common tasks you may want to perform, such as adding sites or schemas, configuring specific policies, or performing administrative tasks.

The Settings icon allows you to access overview information about your Nexus Dashboard Orchestrator, such as the currently running version, what's new in the current release, API documentation, and system status:

- The About NDO link displays information about the version of the Nexus Dashboard Orchestrator currently installed.

- The What's New in This Release link displays a short summary of the new features in your release, as well as links to the rest of the Nexus Dashboard Orchestrator documentation.

- The API Docs link gives you access to the set of Swagger API object and method references. Using the Swagger API is described in more detail in the Cisco Multi-Site REST API Configuration Guide.

- The System Status link provides you with the status and health of all running services that are used by the NDO.

The User icon allows you to view information about the currently logged in user, preferences and bookmarks. It also allows you to log out of the Orchestrator GUI.

Note

Starting with Release 3.2(1), user management has moved to the common user and authentication management in the Nexus Dashboard where your NDO service is running.

- The Preferences link allows you to change a few GUI options.

- The Bookmarks link opens the list of all the bookmarked schemas you save while using the Orchestrator. You can bookmark a schema by clicking the bookmark icon in the top right corner of the screen while viewing or editing the schema.

When working with fabric objects, a Display Name field is used throughout the Orchestrator's GUI whenever the objects are shown. You can specify a display name when creating the objects, however due to object naming requirements on the site controllers, any invalid characters are removed and the resulting Internal Name is used when pushing the objects to sites. The Internal Name that will be used when creating the tenant is typically displayed below the Display Name text box.

Dashboard

The Nexus Dashboard Orchestrator dashboard displays the list of all sites in addition to their current functionality and health.

The Dashboard has the following functional areas:

- Site Name: Displays the name, type, and release version for each site.

- Fault Severity: The fault status columns list the number of faults per site according to their severity:

- Critical (red)

- Major (orange)

- Minor (yellow)

- Warning (green)

Application Management > Tenants Page

The Multi-Site Tenants page lists all of the tenants that comprise your implementation.

The table on the Tenants page displays the following:

- Tenant Name

- Assigned to Sites

- Assigned to Users

- Assigned to Schemas

- Actions

The features and functionality on this page include the following:

- Name: click a tenant name to access the Tenant Details settings page. On the Tenant Details page you can edit or update the following sections:

- General Settings: change the Display Name and Description as required.

- Associated Sites: view the sites associated with the subject tenant.

- Associated Users: view the users associated with the subject tenant - you can associate a user with the subject tenant by checking the empty box next to the user name.

- Associated Schemas: click the Associated Schema listing to view the schemas associated with the subject tenant.

- Actions: click the Actions listing to edit the subject tenant's details sites or to create a new network mapping.

Note

You can delete the Tenant object by selecting Delete on the Actions drop down menu.

- Add Tenant: click Add Tenant button to add an existing tenant to your implementation. On the proceeding Tenant Details page, you can add the tenant name, description, security domain, and associated users.

Audit Logs

Click the Audit Log icon next to the Add Schema tab to list the log details for the Schemas page. The Audit Logs: Tenant List page is displayed.

The table on the page displays the following details:

- Date

- Action

- Details

- User

Click the Most Recent tab to select the audit logs during a particular time period. For example, when you select the range from November 10, 2019 to February 14, 2020 and click Apply, the audit log details for this time period are displayed on the Audit Logs page.

Click the Filter icon next to the Most Recent tab to filter the log details using the following criteria:

- User: Select one username or all users and click Apply to filter the log details using the username.

- Action: Select the action, for example, created, updated, or deleted, and click Apply to filter the log details according to the action.

Application Management > Schemas Page

The Schemas page lists all schemas that are associated with your deployment.

Use the magnifying glass and associated field to search for a specific schema. Use schemas to configure or import tenant policies, such as VRFs and networks.

The Schemas table shows the following information:

- Name: click the schema name to view or update the settings for the subject schema.

- Templates: displays the name of the template that is used for the schema. A template is a set of configuration objects and their properties that you deploy all at once to one or more sites

- Tenants: displays the name of the tenant that is used for the subject schema.

- Actions: click the Action field with the associated schema to either edit or delete the subject schema.

You can use the Add Schema button to add a new schema, which is described in more details in later sections of this document.

Audit Logs

Click the Audit Log icon next to the Add Schema tab to list the log details for the Schemas page. The Audit Logs: Schemas List page is displayed.

The table on the page displays the following details:

- Date

- Action

- Details

- User

Click the Most Recent tab to select the audit logs during a particular time period. For example, when you select the range from November 10, 2019 to December 14, 2020 and click Apply, the audit log details for this time period are displayed on the Audit Logs page.

Click the Filter icon next to the Most Recent tab to filter the log details using the following criteria:

- User: Select one username or all users and click Apply to filter the log details using the username.

- Action: Select the action, for example, created, updated, or deleted, and click Apply to filter the log details according to the action.

Infrastructure > Sites Page

The NDO Infrastructure > Sites page displays all of the sites in your implementation, for example:

Multi-Site Sites Page

The Sites page includes the following:

- Site Health indicates the status of the site's overall health according to the following color coded identifiers:

- Critical (red)

- Major (orange)

- Minor (yellow)

- Warning (green)

- Site Name shows the display name of the site as you defined it when adding the site.

- Site Type displays the fabric type, for example ACI or DCNM.

- The Templates column indicates the number of templates associated with the site.

- The State column indicates whether or not this particular fabric is managed by NDO.

You add and manage sites and their properties in the Nexus Dashboard GUI. The NDO Sites page displays all the sites available in the Nexus Dashboard GUI and allows you to define which specific sites you want to be managed by the NDO.

- The Controller URL column displays the in-band IP address of the site's controller.

- The actions menu (...) allows you to import the site's tenants (ACI fabrics only) or open the site's controller UI.

If you click a specific site, a right Properties sidebar opens and you can view additional information about the site.

Chapter 3. Adding and Deleting Sites

- Adding Cisco DCNM Sites

- Removing Sites

- Cross Launch to Fabric Controllers

Adding Cisco DCNM Sites

This section describes how to add a DCNM site using the Nexus Dashboard GUI and then enable that site to be managed by Nexus Dashboard Orchestrator.

Before you begin

- You must ensure that the site(s) you are adding are running Cisco DCNM, Release 11.5(1) or later.

Procedure

Step 1

Log in to the Nexus Dashboard GUI

Step 2

Add a new site.

1. From the left navigation menu, select Sites.

2. In the top right of the main pane, select Actions > Add Site.

Step 3

Provide site information.

1. For Site Type, select DCNM.

2. Provide the DCNM controller information.

You need to provide the Host Name/IP Address of the in-band (eth2) interface, User Name, and Password. for the DCNM controller currently managing your DCNM fabrics.

3. Click Select Sites to select the specific fabrics managed by the DCNM controller.

The fabric selection window will open.

Step 4

Select the fabrics you want to add to the Nexus Dashboard.

1. Check one or more fabrics that you want to be available to the applications running in your Nexus Dashboard.

2. Click Select.

Step 5

In the Add Site window, click Add to finish adding the sites.

At this time, the sites will be available in the Nexus Dashboard, but you still need to enable them for Nexus Dashboard Orchestrator management as described in the folowing steps.

Step 6

Repeat the previous steps for any additional DCNM controllers.

Step 7

From the Nexus Dashboard's Service Catalog, open the Nexus Dashboard Orchestrator service.

You will be automatically logged in using the Nexus Dashboard user's credentials.

Step 8

In the Nexus Dashboard Orchestrator GUI, manage the sites.

1. From the left navigation menu, select Infrastructure > Sites.

2. In the main pane, change the State from Unmanaged to Managed for each fabric that you want the NDO to manage.

If the fabric you are managing is part of a DCNM Multi-Site Domain (MSD), it will have a Site ID already associated with it. In this case, simply changing the State to Managed will manage the fabric.

However, if the fabric is not part of a DCNM MSD, you will also be prompted to provide a Fabric ID for the site when you change its state to Managed.

Note

If you want to manage both kinds of fabrics, those that are part of an existing MSD and those that are not, you must on-board the MSD fabrics first, followed by any standalone fabrics.

Removing Sites

This section describes how to disable site management for one or more sites using the Nexus Dashboard Orchestrator GUI. The sites will remain present in the Nexus Dashboard.

Before you begin

You must ensure that all templates associated with the site you want to remove are not deployed.

Procedure

Step 1

Open the Nexus Dashboard Orchestrator GUI.

You can open the NDO service from the Nexus Dashboard's Service Catalog. You will be automatically logged in using the Nexus Dashboard user's credentials.

Step 2

Remove the site from all templates.

You must remove the site from all templates with which it is associated before you can unmanaged the site and remove it from your Nexus Dashboard.

1. Navigate to Application Management > Schemas.

2. Click a schema that contains one or more templates associated with the site.

3. In the left sidebar's Sites area, select a template associated with the site, click the options menu (...) next to the template, and choose Undeploy Template.

This will remove configurations that were deployed using this template to this site.

Note

For non-stretched templates, you can choose to preserve the configuration by selecting Dissociate Template instead of Undeploy Template, but you must undeploy any stretched templates.

4. Repeat this step for all templates associated with the site that you want to unmanage in this and all other schemas.

Step 3

In the Nexus Dashboard Orchestrator GUI, disable the sites.

1. From the left navigation menu, select Infrastructure > Sites.

2. In the main pane, change the State from Managed to Unmanaged for the site that you want to unmanage.

Note

If the site is associated with one or more deployed templates, you will not be able to change its state to Unmanaged until you undeploy those templates, as described in the previous step.

Step 4

Delete the site from Nexus Dashboard.

If you no longer want to manage this site or use it with any other applications, you can delete the site from the Nexus Dashboard as well.

Note

Note that the site must not be currently in use by any of the services installed in your Nexus Dashboard cluster.

1. In the top navigation bar, click the Home icon to return to the Nexus Dashboard GUI.

2. From the left navigation menu of the Nexus Dashboard GUI, select Sites.

3. Select one or more sites you want to delete.

4. In the top right of the main pane, select Actions > Delete Site.

5. Provide the site's login information and click OK.

The site will be removed from the Nexus Dashboard.

Cross Launch to Fabric Controllers

Nexus Dashboard Orchestrator currently supports a number of configuration options for each type of fabrics. For many additional configuration options, you may need to log in directly into the fabric's controller.

You can cross launch into the specific site controller's GUI from the NDO's Infrastucture > Sites screen by selecting the actions (...) menu next to the site and clicking Open in user interface. Note that cross-launch works with out-of-band (OOB) management IP of the fabric.

If the same user is configured in Nexus Dashboard and the fabric, you will be logged in automatically into the fabric's controller using the same log in information as the Nexus Dashboard user. For consistency, we recommend configuring remote authentication with common users across Nexus Dashboard and the fabrics.

Chapter 4. Configuring Infra for Cisco DCNM Sites

- Prerequisites and Guidelines

- Configuring Infra: General Settings

- Refreshing Site Connectivity Information

- Configuring Infra: DCNM Site Settings

- Deploying Infra Configuration

Prerequisites and Guidelines

The following sections describe the steps necessary to configure the general as well as site-specific fabric Infra settings.

Before you proceed with Infra configuration, you must have added the sites as described in previous sections.

In addition, keep in mind the following:

- Adding or removing border gateway switches requires a Nexus Dashboard Orchestrator fabric connectivity information refresh described in the Refreshing Site Connectivity Information as part of the general Infra configuration procedures.

Configuring Infra: General Settings

This section describes how to configure general Infra settings for all the sites.

Procedure

Step 1

Log in to the Cisco Nexus Dashboard Orchestrator GUI.

Step 2

In the left navigation menu, select Infrastructure > Infra Configuration.

Step 3

In the main pane, click Configure Infra.

Step 4

In the left sidebar, select General Settings.

Step 5

Configure Control Plane Configuration.

1. Select the Control Plane BGP tab.

2. Choose BGP Peering Type.

- full-mesh—All border gateway switches in each site will establish peer connectivity with remote sites' border gateway switches.

- route-server—The route-server option allows you to specify one or more control-plane nodes to which each site establishes MP-BGP EVPN sessions. The route-server nodes perform a function similar to traditional BGP route-reflectors, but for EBGP (and not iBGP) sessions. The use of route-server nodes avoids creating MP-BGP EVPN full mesh adjacencies between all the VXLAN EVPN sites managed by NDO.

3. If you set the BGP Peering Type to route-server, click +Add Route Server to add one or more route servers.

In the Add Route Server window that opens:

- From the Site dropdown, select the site you want to connect to the route server.

- The ASN field will be auto-populated with the site's ASN.

- From the Core Router Device dropdown, select the route server to which you want to connect.

- From the Interface dropdown, select the interface on the core router device.

You can add up to 4 route servers. If you add multiple route servers, every site will establish MP-BGP EVPAN adjacencies to every route server.

4. Leave the Keepalive Interval (Seconds), Hold Interval (Seconds), Stale Interval (Seconds), Graceful Helper, Maximum AS Limit, and BGP TTL Between Peers fields at default values as they are relevant for Cisco ACI fabrics only.

5. Skip the OSPF Area ID and External Subnet Pool fields at default values as they are relevant for Cisco Cloud ACI fabrics only.

Step 6

Skip the IPN Devices tab settings.

The settings under the IPN Devices tab are for Cisco ACI inter-site connectivity between on-premises APIC and Cloud APIC sites. You can skip these settings when managing Cisco DCNM sites only.

Step 7

Configure DCNM Settings.

1. Select the DCNM Settings tab.

2. Provide the L2 VXLAN VNI Range.

3. Provide the L3 VXLAN VNI Range.

4. Provide the Multi-Site Routing Loopback IP Range.

This field is used to auto-populate the Multi-Site TEP field for each fabric, which is described in Configuring Infra: DCNM Site Settings.

For sites that were previously part of a Multi-Site Domain (MSD) in DCNM, this field will be pre-populated with the previously defined value.

5. Provide the Anycast Gateway MAC.

Refreshing Site Connectivity Information

Infrastructure changes, such as adding and removing border gateway switches, require a Nexus Dashboard Orchestrator fabric connectivity refresh. This section describes how to pull up-to-date connectivity information directly from each site's controller.

Procedure

Step 1

Log in to the Cisco Nexus Dashboard Orchestrator GUI.

Step 2

In the left navigation menu, select Infrastructure > Site Connectivity.

Step 3

In the top right of the main pane, click Configure.

Step 4

In the left sidebar, under Sites, select a specific site.

Step 5

In the main window, click the Refresh button to pull fabric information from the controller.

Step 6

(Optional) In the Confirmation dialog, check the box if you want to remove configuration for decommissioned border gateway switches.

If you choose to enable this checkbox, all configuration info for any currently decommissioned border gateway switches will be removed from the database.

Step 7

Finally, click Yes to confirm and load the connectivity information.

This will discover any new or removed spines and all site-related fabric connectivity will be re-imported from the site's controller.

Configuring Infra: DCNM Site Settings

This section describes how to configure site-specific Infra settings for on-premises sites.

Procedure

Step 1

Log in to the Cisco Nexus Dashboard Orchestrator GUI.

Step 2

In the left navigation menu, select Infrastructure > Infra Configuration.

Step 3

In the main pane, click Configure Infra.

Step 4

In the left pane, under Sites, select a specific DCNM.

Step 5

In the right <Site> Settings sidebar, specify the Multi-Site VIP.

This address is used for the inter-site L2 BUM and L3 multicast traffic. This IP address is deployed on all border gateway switches that are part of the same fabric.

Note

If the site you are configuring is part of the DCNM Multi-Site Domain (MDS), this field will be pre-populated with the information imported from DCNM. In this case, changing the value and re-deploying the infra configuration, will impact traffic between the sites that are part of the MDS.

You can choose to Auto Allocate this field, which will allocate the next available address from the Multi-Site Routing Loopback IP Range you defined in previous section.

Step 6

Within the <fabric-name> tile, select the border gateway.

Step 7

In the right <border-gateway> setting sidebar, specify the BGP-EVPN ROUTER-ID and BGW PIP.

For border gateways that are part of a vPC domain, you must also specify a VPC VIP

Step 8

Click Add Port to configure the port that connects to the IPN.

Note

This release does not support importing the port configuration from the DCNM. If the site you are configuring is already part of the DCNM Multi-Site Domain (MDS), you must use the same values that are already configured in DCNM.

Provide the following information specific to your deployment for the port that connects this border gateway to a core switch or another border gateway:

- From the Ethernet Port ID dropdown, select the port that connects to the IPN.

- In the IP Address field, enter the IP address and netmask.

- In the Remote Address field, provide the IP address of the remote device to which the port is connected.

- In the Remote ASN field, provide the remote site's ID.

- In the MTU field, enter the port's MTU.

MTU of the spine port should match MTU on IPN side.

You can specify either inherit or a value between 576 and 9000.

- For BGP Authentication, you can pick either None or Simple (MD5).

If you select Simple, you must also provide the Authentication Key.

Deploying Infra Configuration

This section describes how to deploy the Infra configuration to each DCNM site.

Before you begin

You must have the general and site-specific infra configurations completed as described in previous sections of this chapter.

Procedure

Step 1

Ensure that there are no configuration conflicts or resolve them if necessary.

The Deploy button will be disabled and a warning will be displayed if there are any configuration conflicts from the already configured settings in each site. For example, if a VRF or network with the same name exists in multiple sites but uses different VNI in each site.

In case of configuration conflicts:

1. Click Click to View link in the conflict notification pop-up.

2. Note down the specific configurations that are causing the conflicts.

For example, in the following report, there are ID mismatches between VRFs and networks in fab1 and fab2 sites.

3. Click the X button to close the report, then exit Infra configuration screen.

4. Unmanage the site in NDO, as described in Removing Sites.

You do not need to remove the site from the Nexus Dashboard, simply unmanage it in NDO GUI.

5. Resolve the existing configuration conflicts.

6. Manage the site again, as described in Adding Cisco DCNM Sites.

Since the site is already added in Nexus Dashboard, simply enable it for management in NDO.

7. Verify that all conflicts are resolved and the Deploy button is available.

Step 2

Deploy configuration.

1. In the top right of the Fabric Connectivity Infra screen, choose the appropriate Deploy option to deploy the configuration.

If you are configuring only DCNM sites, simply click Deploy to deploy the Infra configuration.

2. Wait for configuration to be deployed.

When you deploy infra configuration, NDO will signal the DCNM to configure the underlay and the EVPN overlay between the border gateways.

When configuration is successfully deployed, you will see a green checkmark next to the site in the Fabric Connectivity Infra screen:

Chapter 5. Fabric Management

- Tenants Overview

- Schemas and Templates

- Concurrent Configuration Updates

- Creating Schemas and Templates

- Bulk Update of Template Objects

- Template Versioning

- Template Review and Approval

- Deploying Templates

- Disassociating Template from Sites

- Configuration Drifts

- Viewing Currently Deployed Configuration

- Schema Overview and Deployment Visualizer

Tenants Overview

A tenant is a logical container for application policies that enable an administrator to exercise domain-based access control. A tenant represents a unit of isolation from a policy perspective, but it does not represent a private network. Tenants can represent a customer in a service provider setting, an organization or domain in an enterprise setting, or just a convenient grouping of policies.

Note

To manage tenants, you must have either Power User or Site and Tenant Manager read-write role.

Three default tenants are pre-configured for you:

- common—A special tenant with the purpose of providing "common" services to other tenants in ACI fabrics. Global reuse is a core principle in the common tenant. Some examples of common services include shared L3Outs, DNS, DHCP, Active Directory, and shared private networks or bridge domains.

- dcnm-default-tn—A special tenant with the purpose of providing configuration for Cisco NDFC fabrics.

When using Nexus Dashboard Orchestrator to manage Cisco DCNM fabrics, you will use the default dcnm-default-tn that is preconfigured for you and allows you to create and manage the following objects:

- VRFs

- Networks

- infra—The Infrastructure tenant that is used for all internal fabric communications, such as tunnels and policy deployment. This includes switch to switch and switch to APIC communications. The infra tenant does not get exposed to the user space (tenants) and it has its own private network space and bridge domains. Fabric discovery, image management, and DHCP for fabric functions are all handled within this tenant.

When using Nexus Dashboard Orchestrator to manage Cisco NDFC fabrics, you will always use the default dcnm-default-tn tenant.

- Add Users to NDFC Tenant

Add Users to NDFC Tenant

This section describes how to add users to the existing default dcnm-default-tn tenant which you will use when creating schema templates for your NDFC configurations.

Before you begin

You must have a user with either Power User or Site Manager read-write role to manage tenants.

Procedure

Step 1

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

Step 2

Select the dcnm-default-tn tenant.

1. From the left navigation pane, choose Application Management > Tenants.

2. In the main pane, click dcnm-default-tn tenant name.

The Update Tenant screen opens.

Step 3

Provide tenant details.

The tenant's Display Name is used throughout the Orchestrator's GUI whenever the tenant is shown. However, due to object naming requirements on the APIC, any invalid characters are removed and the resulting Internal Name is used when pushing the tenant to sites. The Internal Name that will be used when creating the tenant is displayed below the Display Name textbox.

Note

You can change the Display Name of the tenant at any time, but the Internal Name cannot be changed after the tenant is created.

1. In the Associated Sites section, check all the sites you want to associate with this tenant.

Only the selected sites will be available for any templates using this tenant.

2. In the Associated Users section, select the Nexus Dashboard Orchestrator users that are allowed to access the tenant.

Only the selected users will be able to use this tenant when creating templates.

Step 4

Click Save to finish adding the tenant.

Schemas and Templates

A schema is a collection of templates, which are used for defining networking configuration, with each template assigned to a specific tenant. A template is a set of configuration objects and their properties that you deploy all at once to one or more sites. There are multiple approaches you can take when it comes to creating schema and template configurations specific to your deployment use case. The following sections describe a few simple design directions you can take when deciding how to define the schemas, templates, and policies in your Multi-Site environment.

Keep in mind that when designing schemas, you must consider the supported scalability limits for the number of schemas, templates, and objects per schema. Detailed information on verified scalability limits is available in the Cisco Multi-Site Verified Scalability Guides for your release.

Single Schema Deployment

The simplest schema design approach is a single schema deployment. You can create a single schema with all VRFs and Networks in that schema. You can then create a single application profile or multiple application profiles within the templates and deploy it to one or more sites.

This simplest approach to Multi-Site schema creation is to create all objects within the same schema and template. However, the supported number of schemas or templates per schema scalability limit may make this approach unsuitable for large scale deployments, which could exceed those limits.

Multiple Schemas Based On Object Relationships

When configuring multiple schemas with shared object references, it is important to be careful when making changes to those objects. For instance, making changes to or deleting a shared networking object can impact applications in one or more sites. Because of that, you may choose to create a template around each individual site that contains only the objects used by that site and its applications. And create different templates containing the shared objects.

For example, you can use the following templates for a configuration that you plan to deploy to 3 different sites:

- Site 1 template

- Site 2 template

- Site 3 template

- Site 1 and 2 shared template

- Site 1 and 3 shared template

- Site 2 and 3 shared template

- All shared template

Similarly, rather than separating objects based on which site they are deployed to, you can also choose to create schemas and templates based on individual applications instead. This would allow you to easily identify each application profile and map them to schemas and sites as well as easily configure each application as local or stretched across sites.

However, as this could quickly exceed the templates per schema limit (listed in the Verified Scalability Guide for your release), you would have to create additional schemas to accommodate the multiple combinations. While this creates additional complexity with multiple additional schemas and templates, it provides true separation of objects based on site or application.

Template Design

In this release, we recommend creating separate templates for VRFs and Networks within each schema and then deploying the VRF templates first, followed by the templates that contain Networks. This way any VRFs required by the networks will be already created when you push Network configuration to the sites.

Similarly, when undeploying multiple networks and VRFs, we recommend undeploying the Networks template first, followed by the VRF templates. This will ensure that when VRFs are undeployed, there will be no conflicts with any existing Networks still using them.

Concurrent Configuration Updates

The Nexus Dashboard Orchestrator GUI will ensure that any concurrent updates on the same site or schema object cannot unintentionally overwrite each other. If you attempt to make changes to a site or template that was updated by another user since you opened it, the GUI will reject any subsequent changes you try to make and present a warning requesting you to refresh the object before making additional changes; refreshing the template will lose any edits you made up to that point and you will have to make those changes again:

However, the default REST API functionality was left unchanged in order to preserve backward compatibility with existing applications. In other words, while the UI is always enabled for this protection, you must explicitly enable it for your API calls for NDO to keep track of configuration changes.

Note

When enabling this feature, note the following:

- This release supports detection of conflicting configuration changes for Site and Schema objects only.

- Only PUT and PATCH API calls support the version check feature.

- If you do not explicitly enable the version check parameter in your API calls, NDO will not track any updates internally. And as a result, any configuration updates can be potentially overwritten by both subsequent API calls or GUI users.

To enable the configuration version check, you can pass the enableVersionCheck=true parameter to the API call by appending it to the end of the API endpoint you are using, for example:

https://<mso-ip-address>/mso/api/v1/schemas/<schema-id>?enableVersionCheck=true

Example

We will use a simple example of updating the display name of a template in a schema to show how to use the version check attribute with PUT or PATCH calls.

First, you would GET the schema you want to modify, which will return the current latest version of the schema in the call's response:

{
"id": "601acfed38000070a4ee9ec0",
"displayName": "Schema1",
"description": "",
"templates": [
{
"name": "Template1",
"displayName": "current name",
[...]
}
],
"_updateVersion": 12,
"sites": [...]
}

Then you can modify the schema in one of two ways appending enableVersionCheck=true to the request URL:

Note

You must ensure that the value of the "_updateVersion" field in the payload is the same as the value you got in the original schema.

- Using the PUT API with the entire updated schema as payload:

PUT /v1/schemas/601acfed38000070a4ee9ec0?enableVersionCheck=true

{
"id": "601acfed38000070a4ee9ec0",
"displayName": "Schema1",
"description": "",
"templates": [
{
"name": "Template1",
"displayName": "new name",
[...]
}
],
"_updateVersion": 12,
"sites": [...]
}

- Using any of the PATCH API operations to make a specific change to one of the objects in the schema:

PATCH /v1/schemas/601acfed38000070a4ee9ec0?enableVersionCheck=true

[
{
"op": "replace",
"path": "/templates/Template1/displayName",
"value": "new name",
"_updateVersion": 12
}
]

When the request is made, the API will increment the current schema version by 1 (from 12 to 13) and attempt to create the new version of the schema. If the new version does not yet exist, the operation will succeed and the schema will be updated; if another API call (with enableVersionCheck enabled) or the UI have modified the schema in the meantime, the operation fails and the API call will return the following response:

{
"code": 400,
"message": "Update failed, object version in the DB has changed, refresh your client and retry"
}

Creating Schemas and Templates

Before you begin

- You must have the user accounts which you will use to create and modify schemas already associated with the Tenant that those schemas will use, as described in Add Users to NDFC Tenant

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

Create a new schema.

1. From the left navigation pane, choose Application Management > Schemas.

2. On the Schemas page, click Add Schema.

3. In the schema creation dialog, provide the Name and optional description for the schema.

By default, the new schema is empty, so you need to add one or more templates.

Step 3

Create a template.

1. In the left sidebar under Templates, click the + sign to add a new template.

2. In the Select a Template type window, choose Networking for the template type.

- ACI Multi-Cloud—Templates used for Cisco ACI on-premises and cloud sites, which allow template and object stretching between multiple sites.

This guide described Nexus Dashboard Orchestrator configurations for Cisco NDFC (DCNM) sites. For information on working with Cisco NDFC sites, see the Cisco Nexus Dashboard Orchestrator Configuration Guide for ACI Fabrics instead.

- Networking—Templates designed for Cisco Nexus Dashboard Fabric Controller (formerly Data Center Network Manager) sites.

- SR-MPLS—Template designed for SR-MPLS integration.

This guide described Nexus Dashboard Orchestrator configurations for Cisco NDFC (DCNM) sites. For information on working with Cisco NDFC sites, see the Cisco Nexus Dashboard Orchestrator Configuration Guide for ACI Fabrics instead.

- Cloud Local—Templates designed for specific Cisco Cloud ACI use cases, such as Google Cloud site connectivity, and cannot be stretched between multiple sites.

This guide described Nexus Dashboard Orchestrator configurations for Cisco NDFC (DCNM) sites. For information on working with Cisco NDFC sites, see the Cisco Nexus Dashboard Orchestrator Configuration Guide for ACI Fabrics instead.

3. Click Add to create the template.

Step 4

Provide the name and the tenant for the template.

1. In the right sidebar, specify the Display Name for the template.

2. From the Select a Tenant dropdown, select the dcnm-default-tn tenant.

Keep in mind, the user account you're using to create a new schema must be associated with the tenant you are trying to add to it, otherwise the tenant will not be available in the drop-down menu.

Step 5

Assign the templates to sites.

You deploy one template at a time, so you need to associate the template with at least one site where you want to deploy the configuration.

1. In the left pane, click the + icon next to Sites

2. In the Add Sites window, check the checkbox next to the sites where you want to deploy the template.

3. From the Assign to Template dropdown next to each site, select one or more templates.

While you deploy one template at a time to every site with which it is associated, you can associate multiple templates to a site at once.

4. Click Save.

- Importing Schema Elements From DCNM Sites

- Creating VRFs

- Creating Networks

Importing Schema Elements From DCNM Sites

You can create new objects and push them out to one or more sites or you can import existing site-local objects and manage them using the Nexus Dashboard Orchestrator. This section describes how to import one or more existing objects, while creating new objects is described later on in this document.

Procedure

Step 1

Open the Schema where you want to import objects.

Step 2

In the left sidebar, select the Template where you want to import objects.

Step 3

In the main pane click the Import button and select the Site from which you want to import.

Step 4

In the Import from <site-name> window that opens, select one or more objects.

Note

The names of the objects imported into the Nexus Dashboard Orchestrator must be unique across all sites. Importing different objects with duplicate names will cause a schema validation error and the import to fail. If you want to import objects that have the same name, you must first rename them.

Creating VRFs

This section describes how to create a VRF.

Before you begin

You must have the schema and template created and a tenant assigned to the template, as described in Creating Schemas and Templates.

Procedure

Step 1

Select the schema and template where you want to create VRF.

Step 2

In the schema edit view, choose Create Object > VRF.

Step 3

In the properties pane on the right, provide Display Name for the VRF.

Step 4

Configure the DCNM Properties for the VRF.

1. (Optional) Provide the VRF ID.

You can choose to specify the VNI of the VRF or leave the field empty and the VNI will be automatically allocated by the NDO from the ranges you specified in Configuring Infra: General Settings.

2. From the VRF Profile dropdown, select the VRF profile.

You can assign the Default_VRF_Universal profile or choose any available VRF Profile that had been previously created in DCNM. Any profiles created in DCNM are automatically imported into the NDO and are available for selection here.

3. From the VRF Extension Profile dropdown, select the extension profile.

You can assign the Default_VRF_Extension_Universal profile or choose any available VRF Extension Profile that had been previously created in the DCNM. Any profiles created in DCNM are automatically imported into the NDO and are available for selection here.

4. Provide the Loopback Routing Tag.

If a VLAN is associated with multiple subnets, then this tag is associated with the IP prefix of each subnet. Note that this routing tag is associated with overlay network creation too.

5. Provide the Redistribute Direct Route Map.

Specifies the route map name for redistribution of routes in the VRF.

6. (Optional) Check Disable RT Auto-Generate to disable automatic generation of route targets.

Note

This feature is supported in Nexus Dashboard Orchestrator, Release 3.5(2) and later.

By default when this option is unchecked, the route targets (RTs) are generated by the switches and you can choose to generate custom RTs in addition to the existing auto-generated ones.If you enable this option, the automatic generation of RTs will be disabled and you can use only the custom RTs.

7. (Optional) Provide any custom route targets.

Note

This feature is supported in Nexus Dashboard, Release 3.5(2) and later.

To provide custom RTs, enter one or more values for the following fields:

- Import—for VPN routes import

- Export—for VPN routes export

- Import EVPN—for EVPN routes import

- Export EVPN—for EVPN routes export

You must enter a valid value, for example 12.2.3.4:2200. As you type in a value, the UI will validate it and once the format is correct, you will see a Create "<value>" option in the dropdown.

You can provide up to 10 custom route target values in total.

Step 5

Configure the VRF's site-local properties.

In addition to the network's general properties that apply to every site where the VRF is deployed, you can configure site-specific properties for this VRF individually for each site.

1. In the left sidebar under SITES, select the template where the network is defined.

2. In the main pane, select the network.

3. In the right Properties sidebar, provide the site-specific settings.

You can configure the following site-local properties:

- Enable Tenant Routed Multicast—Tenant Routed Multicast (TRM) enables multicast forwarding on the VXLAN fabric that uses a BGP-based EVPN control plane. TRM provides multi-tenancy aware multicast forwarding between senders and receivers within the same or different subnets local or across VTEPs.

If you enable TRM, you must also provide the RP Address and Overlay Multicast Group.

- Enable RP External if the Rendezvous Point (RP) is external to the fabric.

- Click Add Static Leaf to select one or more leaf switches where the VRF will be configured.

In the Add Static Leaf window that opens, choose the leaf node and provide the VLAN ID for the VRF.

Creating Networks

This section describes how to configure a DCNM network from Nexus Dashboard Orchestrator.

Before you begin

- You must have the schema and template created and a tenant assigned to the template, as described in Creating Schemas and Templates.

- You must have the VRF created as described in Creating VRFs

Procedure

Step 1

Select the schema and template where you want to create the application profile.

Step 2

In the schema edit view, choose Create Object > Network.

Step 3

In the properties pane on the right, provide Display Name for the network.

Step 4

(Optional) Provide the Network ID.

You can choose to specify the network ID or leave the field empty and the ID will be automatically allocated by the NDO when you save the schema.

Step 5

Choose whether or not this is a Layer2 Only network.

Step 6

From the Virtual Routing & Forwarding dropdown, select the VRF you created for this network.

This option will be unavailable if you enabled Layer2 Only.

Step 7

From the Network Profile dropdown, select the network profile.

You can assign the Default_Network_Universal profile or choose any available Network Profile that had been previously created in DCNM. Any profiles created in DCNM are automatically imported into the NDO and are available for selection here.

Step 8

From the Network Extension Profile dropdown, select the network extension profile.

You can assign the Default_Network_Extension_Universal profile or choose any available Network Extension Profile that had been previously created in the DCNM. Any profiles created in DCNM are automatically imported into the NDO and are available for selection here.

Step 9

Provide the VLAN ID for the network.

Step 10

Provide the VLAN Name.

Step 11

Add one or more Subnets.

This option will be unavailable if you enabled Layer2 Only.

1. Click +Add Subnet.

An Add Subnet window opens.

2. Click +Add Gateway IP and enter the subnet's Gateway IP address.

You can configure up to four gateway IPs.

3. Choose Primary for the first gateway you add.

4. Click the checkmark to save the gateway information.

5. Repeat the previous substeps to provide additional gateways.

6. Click Add to finish adding the subnet.

Step 12

Choose whether you want to Suppress ARP.

Step 13

Provide the MTU for this network.

Step 14

Provide the Routing Tag.

Step 15

Configure the network's site-local properties.

In addition to the network's general properties that apply to every site where the network is deployed, you can configure site-specific properties for this network individually for each site.

1. In the left sidebar under SITES, select the template where the VRF is defined.

2. In the main pane, select the VRF.

3. In the right Properties sidebar, provide the site-specific settings.

You can configure the following site-local properties:

- Enable Tenant Routed Multicast—Tenant Routed Multicast (TRM) enables multicast forwarding on the VXLAN fabric that uses a BGP-based EVPN control plane. TRM provides multi-tenancy aware multicast forwarding between senders and receivers within the same or different subnets local or across VTEPs.

- Check Enable L3 Gateway Border to enable Layer 3 SVI on the border gateways to allow connecting dual-attached hosts to it.

- Provide the DHCP Loopback ID.

The value must be in the 0-1023 range.

- Click +Add DHCP Server to add one or more DHCP relay servers.

In the Add DHCP Server window that opens, provide the IP address of the DHCP relay and the VRF to which it belongs.

- Click +Add Static Port to add one or more ports to which the network's VLAN will be attached.

In the Add Static Port window that opens, select the leaf switch that contains the port, provide the VLAN ID, and finally click Add Port to specify one or more ports for the network.

Note that if you want to add multiple static ports from different leaf switches, you will need to repeat the process for each leaf switch separately.

Bulk Update of Template Objects

The bulk update feature allows you to update multiple properties on multiple different objects of the same type within a template at once. When using this workflow, all selected objects must be of the same type otherwise the update feature won't work. For example, in the case of Cisco DCNM you cannot choose to update a VRF and Network simultaneously.

You can use "Select" on a type of object then update the properties of those objects. If the selected objects already have different property values configured on them, the update will overwrite those properties with the values you provide.

Note

This feature is supported for Cisco APIC and Cisco DCNM fabrics only; it is not supported for Cisco Cloud APIC sites.

The following example will walk you through the process.

Procedure

Step 1

Navigate to the schema and template that contains the objects you want to update.

Step 2

The following figure shows all the objects belonging to a single template.

Choose "Select". It will allow you select multiple objects at once.

Step 3

After selecting all the objects that you want to update.

1. Choose “…” right next to the cancel option.

2. From the dropdown Choose "Edit".

If you choose objects of different type, you won't see the Edit option in the dropdown.

Step 4

After choosing “Edit”, a pop-up will show up.

You can update the following properties based on the type of objects you selected.

1. VRF: VRF Profile, VRF Extension Profile, Loopback Routing Tag, Redistribute Direct Route Map, Disable RT Auto-Generate.

2. Network: Layer2 Only, Network Profile, Network Extension Profile.

Step 5

Choose “Save”, it will implement the updates you've made.

Step 6

As you save the updates, you can see the changes you made.

Template Versioning

A new version of the template is created every time it is saved. From within the NDO UI, you can view the history of all configuration changes for any template along with information about who made the changes and when. You can also compare any of the previous versions to the current version.

New versions are created at the template level, not schema level, which allows you to configure, compare, and roll back each template individually.

Template versions are created and maintained according to the following rules:

- All template versions are either Deployed or Intermediate.

Deployed—versions of the template that have been deployed to sites.

Intermediate—versions of the template that have been modified and saved, but not deployed to sites.

- A maximum of 20 Deployed and 20 Intermediate versions per template can be stored at any given time.

- When a new Intermediate version is created that would exceed the 20 version limit, the earliest existing Intermediate version is deleted.

- When a template is deployed and a new Deployed version is created, all Intermediate versions are deleted. If the new Deployed version exceeds the 20 version limit, the earliest existing Deployed version is deleted.

- Tagging a version Golden does not affect the number of stored template versions.

- When initially upgrading from an earlier release that supported unlimited number of versions per template, all existing versions remain intact.

When a template is modified and saved or deployed, any versions that exceed the 20 Deployed and 20 Intermediate scale are removed according to the above rules.

- Tagging Templates

- Viewing History and Comparing Previous Versions

- Reverting Template to Earlier Version

Tagging Templates

At any point you can choose to tag the current version of the template as "golden", for example for future references to indicate a version that was reviewed, approved, and deployed with a fully validated configuration.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Application Management > Schemas.

Step 3

Click the schema that contains the template you want to view.

Step 4

In the Schema view, select the template you want to review.

Step 5

From the template's actions (...) menu, select Set as Golden.

If the template is already tagged, the option will change to Remove Golden and allows you to remove the tag from the current version.

Any version that was tagged will be indicated by a star icon in the template's version history screen.

Viewing History and Comparing Previous Versions

This section describes how to view previous versions for a template and compare them to the current version.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Application Management > Schemas.

Step 3

Click the schema that contains the template you want to view.

Step 4

In the Schema view, select the template you want to review.

Step 5

From the template's actions (...) menu, select View History.

Step 6

In the Version History window, make the appropriate selections.

1. Enable the Golden Versions checkbox to filter the list of previous versions to display only the versions of this template that had been marked as Golden.

Tagging a template as "Golden" is described in Tagging Templates.

2. Enable the Deployed Versions checkbox to filter the list of previous versions to display only the versions of this template that had been deployed to sites.

A new template version is created every time the template is changed and the schema is saved. You can choose to only show the versions of the template that were actually deployed to sites at some point.

3. Click on a specific version to compare it to the current version.

The version you select is always compared to the current version of the template. Even if you filter the list using the Golden Versions or Deployed Versions filters, the current version will always be displayed even if it was never deployed or tagged as golden.

4. Mouse over the Edit icon to see information about who created the version and when.

Step 7

Click OK to close the version history window.

Reverting Template to Earlier Version

This section describes how to restore a previous version of the template. When reverting a template, the following rules apply:

- If the target version references objects that are no longer present, restore operation will not be allowed.

- If the target version references sites that are no longer managed by NDO, restore operation will not be allowed.

- If the current version is deployed to one or more sites to which the target version was not deployed, restore operation will not be allowed.

You must first undeploy the current version from those sites before reverting the template.

- If the target version was deployed to one or more sites to which the current version is not deployed, restore operation is allowed.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Application Management > Schemas.

Step 3

Click the schema that contains the template you want to view.

Step 4

In the Schema view, select the template you want to review.

Step 5

From the Actions (...) menu, select Rollback.

Step 6

In the Rollback window, select one of the earlier versions to which you want to restore.

You can filter the list of versions using the Golden Versions and Deployed Versions checkboxes.

When you select a version, you can compare the template configuration of that version to the current version of the template.

Step 7

Click Restore to restore the selected version.

When you restore a previous version, a new version of the template is created with the same configuration as the version you selected in the previous step.

For example, if the latest template version is 3 and you restore version 2, then version 4 is created that is identical to the version 2 configuration. You can verify the restore by browsing to the template version history and comparing the current latest version to the version you had selected during restore, which should be identical.

If template review and approval (change control) is disabled and your account has the correct privileges to deploy templates, you can deploy the version to which you reverted.

However, if change control is enabled, then:

- If you revert to a version that had been previously deployed and your account has the correct privileges to deploy templates, you can immediately deploy the template.

- If you revert to a version that had not been previously deployed or your account does not have the correct privileges to deploy templates, you will need to request template approval before the reverted version can be deployed.

Additional information about review and approval process is available in the Template Review and Approval sections.

Template Review and Approval

Release 3.4(1) adds support for template review and approval (change control) workflow which allows you to set up designated roles for template designers, reviewers and approvers, and template deployers to ensure that the configuration deployments go through a validation process.

From within the NDO UI, a template designer can request review on the template they create. Then reviewers can view the history of all configuration changes for the template along with information about who made the changes and when, at which point they can approve or deny the current version of the template. If the template configuration is denied, the template designer can make any required changes and re-request review; if the template is approved, it can be deployed to the sites by a user with Deployer role. Finally, the deployer themselves can deny deployment of an approved template and restart the review process from the beginning.

The workflow is done at the template level, not schema level, which allows you to configure, review, and approve each template individually.

Note

Because the review and approval workflow depends on user roles that are defined in Nexus Dashboard, you must be running Nexus Dashboard release 2.1(1) or later to use this feature. If you deployed your Nexus Dashboard Orchestrator in Nexus Dashboard release 2.0.2, the review and approval feature will be disabled until you upgrade your platform.

- Enabling Template Approval Requirement

- Create Users with Required Roles

- Requesting Template Review and Approval

- Reviewing and Approving Templates

Enabling Template Approval Requirement

Before you can use the review and approval workflow for template configuration and deployment, you must enable the feature in the Nexus Dashboard Orchestrator's system settings.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Infrastructure > System Configuration.

Step 3

On the Change Control tile, click the Edit icon.

Step 4

In the Change Control window, check the Change Control Workflow checkbox to enable the feature.

Step 5

In the Approvers field, enter the number of unique approvals required before the templates can be deployed.

Step 6

Click Save to save the changes.

Create Users with Required Roles

Before you can use the review and approval workflow for template configuration and deployment, you must create the users with the necessary privileges in the Nexus Dashboard where the NDO service is deployed.

Procedure

Step 1

Log in to your Nexus Dashboard GUI.

Users cannot be created or edited in the NDO GUI, you must log in directly to the Nexus Dashboard cluster where the service is deployed.

Step 2

From the left navigation menu, select Administrative > Users.

Step 3

Create the required users.

The workflow depends on three distinct user roles: template designer, approver, and deployer. You can assign each role to a different user or combine the roles for the same user; users with admin privileges can perform all 3 actions.

Detailed information about configuring users and their privileges for local or remote Nexus Dashboard users is described in the Nexus Dashboard User Guide.

You must have at least as many unique users with Approver role as the minimum number of approvals required, which you configured in Enabling Template Approval Requirement.

Note

If you disable the Change Control Workflow feature, any Approver and Deployer users will have read-only access to the Nexus Dashboard Orchestrator.

Requesting Template Review and Approval

This section describes how to request template review and approval.

Before you begin

You must have:

- Enabled the global settings for approval requirement, as described in Enabling Template Approval Requirement.

- Created or updated users in Nexus Dashboard with approver and deployer roles, as described in Create Users with Required Roles.

- Created a template with one or more policy configurations and assigned it to one or more sites.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI as a user with Tenant Manager, Site Manager, or admin role.

Step 2

From the left navigation menu, select Application Management > Schemas.

Step 3

Click the schema that contains the template for which you want to request approval.

Step 4

In the schema view, select the template.

Step 5

In the main pane, click Send for Approval.

Note that the Send for Approval button will not be available in the following cases:

- The global change control option is not enabled

- The template has no policy configurations or is not assigned to any sites

- Your user does not have the right permissions to edit templates

- The template has already been sent for approval

- The template was denied by the approver user

Reviewing and Approving Templates

This section describes how to request template review and approval.

Before you begin

You must have:

- Enabled the global settings for approval requirement, as described in Enabling Template Approval Requirement.

- Created or updated users in Nexus Dashboard with approver and deployer roles, as described in Create Users with Required Roles.

- Created a template with one or more policy configurations and assigned it to one or more sites.

- Had the template approval requested by a schema editor, as described in Requesting Template Review and Approval.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI as a user with Approver or admin role.

Step 2

From the left navigation menu, select Application Management > Schemas.

Step 3

Click the schema that contains the template you want to review and approve.

Step 4

In the schema view, select the template.

Step 5

In the main pane, click Approve.

If you have already approved or denied the template, you will not see the option until the template designer makes changes and re-sends the template for review again.

Step 6

In the Approving template window, review the template and click Approve.

The approval screen will display all the changes which the template would deploy to the sites.

You can click View Version History to view the complete version history and incremental changes made between versions. Additional information about version history is available in Viewing History and Comparing Previous Versions.

You can also click Deployment Plan to see a visualization and a JSON of the configuration that would be deployed from this template. The functionality of the "Deployment Plan" view is similar to the "Deployed View" for already-deployed templates, which is described in Viewing Currently Deployed Configuration.

What to do next

After the template is reviewed and approved by the required number of approvers, you can deploy the template as described in Deploying Templates.

Deploying Templates

This section describes how to deploy new or updated configuration to DCNM fabrics.

Before you begin

You must have the schema, template, and any objects you want to deploy to sites already created, as described in previous sections of this document.

Procedure

Step 1

Navigate to the schema that contains one or more templates that you want to deploy.

Step 2

Assign the templates to sites.

If you have already assigned the templates to sites, skip this step.

You deploy one template at a time, so you need to associate the template with at least one site where you want to deploy the configuration.

1. In the left pane, click the + icon next to Sites

2. In the Add Sites window, check the checkbox next to the sites where you want to deploy the template.

3. From the Assign to Template dropdown next to each site, select one or more templates.

While you deploy one template at a time to every site with which it is associated, you can associate multiple templates to a site at once.

4. Click Save.

Step 3

In the left sidebar, select the template you want to deploy.

Step 4

In the top right of the template edit view, click Deploy to sites.

The Deploy to Sites window opens that shows the summary of the objects to be deployed.

Step 5

Click Deploy to deploy the template.

- If this is the first time you are deploying this template or you have made changes to a previously deployed template, the Deploy to Sites summary will show the configuration difference that will be deployed to sites.

Note

You can filter the view using the Created, Modified, and Deleted checkboxes for informational purposes, but keep in mind that all of the changes are still deployed when you click Deploy.

- If you have previously deployed this template but made no changes to it since, the Deploy to Sites summary will allow you to re-deploy the entire template only the Full Template option and you can simply click Deploy to re-deploy the entire template.

Disassociating Template from Sites

You can choose to disassociate a template from a site without undeploying it. This allows you to preserve any configuration deployed to the site from NDO while removing the template-site association in the schema. The managed object and policy ownership is transferred from NDO to the site's controller.

Before you begin

- The template and its configuration must already be deployed to a site.

- The template must be deployed to a single site only and not stretched across sites.

- The objects defined in the template must not be deployed as shadow objects in other sites.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Application Management > Schemas.

Step 3

Click the schema that contains the template you want to disassociate.

Step 4

In the Schema view, select the template under the specific site from which you want to disassociate it.

Step 5

From the Actions menu, select Disassociate Template.

Step 6

In the confirmation window, click Confirm Action.

Configuration Drifts

Occasionally, you may run into a situation where the configuration actually deployed in a NDFC/DCNM domain is different from the configuration defined for that domain in the Nexus Dashboard Orchestrator. These configuration discrepancies are referred to as Configuration Drifts and are indicated by a yellow warning sign next to the template name in the schema view as shown in the following figure:

Configuration drifts can manifest due to a number of different reasons. Specific steps required to resolve a configuration drift depends on its cause. Most common scenarios and their resolutions are outlined below:

- Configuration is modified in NDO—when you modify a template in NDO GUI, it will show as configuration drift until you deploy the changes to the sites.

To resolve this type of configuration drift, either deploy the template to apply the changes to the sites or revert the changes in the schema.

- Configuration is modified directly in the site's controller—while the objects deployed from NDO are indicated by a warning icon and text in the site's NDFC/DCNM, an admin user can still make changes to them causing the configuration drift.

- NDO configuration is restored from backup—restoring configuration from a backup in NDO restores only the objects and their state as they were when the backup was created, it does not automatically re-deploy the restored configuration. As such, if there were changes made to the configuration and deployed on NDFC/DCNM since the backup was created, restoring the backup would create a configuration drift.

- NDO configuration is restored from a backup created on an older release—if the newer release added support for object properties which were not supported by the earlier release, these properties may cause configuration drift warning. Typically, this happens if the new properties were modified directly in the site's NDFC/DCNM GUI and the values are different from the defaults assumed by the Nexus Dashboard Orchestrator

- NDO is upgraded from an earlier release—this scenario is similar to the previous one where if new object properties are added in the new release, existing configuration may indicate a drift.

We recommend running the "Reconcile Drift" workflow for the template, to have more visibility into the causes of the drift and be able to reconcile it. This recommendation applies to all the drift scenarios previously described in this section. For more information on the drift reconciliation workflow, see the "Reconciling Configuration Drifts" section below.

- Reconciling Configuration Drifts

Reconciling Configuration Drifts

NDO release 3.6(1) introduced support for a drift reconciliation workflow that can be run to compare the template configuration defined on Nexus Dashboard Orchestrator and the configuration rendered in the NDFC/DCNM controllers of the sites part of the Multi-Site domain. This allows to provide more visibility into what causes the configuration drift (i.e. changes that have been made on Nexus Dashboard Orchestrator or on NDFC/DCNM directly) and give the user the choice on how to reconcile the drift, as described in the steps below.

Note

If you do not want the configurations you chose, you can close the schema and re-open. This will show the original configurations. You can re-trigger "Reconcile Drift" flow again if needed. The schema will get saved only after you choose Save or Deploy button.

Procedure

Step 1

Navigate to the schema that contains the template you want to check for configuration drifts.

Step 2

From the template's Actions menu, select Reconcile Drift.

The Drift Reconciliation wizard opens.

Step 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

Step 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.

Step 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. You can then click Deploy to sites to deploy the configuration and reconcile the drift for that template.

Viewing Currently Deployed Configuration

You can view all objects currently deployed to sites from a specific template. Even though any given template can be deployed, undeployed, updated, and re-deployed any number of times, this feature will show only the final state that resulted from all of those actions. For example, if Template1 contains only VRF1 object and is deployed to Site1, the API will return only VRF1 for the template; if you then add VRF2 and redeploy, the API will return both objects, VRF1 and VRF2, from this point on.

This information comes from the Orchestrator database, so it does not account for any potential configuration drifts caused by changes done directly in the site's controller.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Application Management > Schemas.

Step 3

Click the schema that contains the template you want to view.

Step 4

In the left sidebar, select the template.

Step 5

Open the Deployed View for the template.

1. Click the Actions menu next to the template's name.

2. Click Deployed View.

Step 6

In the Deployed View screen, select the site for which you want to view the information.

You will see a graphical representation of the template configuration comparison between what's already deployed to the site and what's defined in the template.

1. The color-coded legend indicates which objects would be created, deleted, or modified if you were to deploy the template at this time.

If the latest version of the template is already deployed, the view will not contain any color-coded objects and will simply display the currently deployed configuration.

2. You can click on a site name to show configuration for that specific site.

3. You can click View JSON to see the config of all the objects that are deployed to the selected site.

Schema Overview and Deployment Visualizer

When you open a schema with one or more objects defined and deployed to one or more fabrics, the schema Overview page will provide you with a summary of the deployment.

Schema Overview

The following details are provided on this page:

1. General—Provides general information of the schema, such the name and description.

2. Audit Log—Provides audit log summary of the actions performed on the schema.

3. Sites > Health—Provides the number of sites associated with the templates in this schema sorted by the site's health status.

4. Sites > Type—Provides the number of sites associated with the templates in this schema sorted by the site's type.

5. Template to Site Associations > Deployment Status—Provides the number of templates in this schema that are associated with one or more sites and their deployment status.

6. Application Management—Provides a summary of individual objects contained by the templates in this schema.

The Topology tile allows you to create a topology visualizer by selecting one or more objects to be displayed by the diagram as shown in the following figure.

Deployment Visualizer

1. Configuration Options—Allows you to choose which policy objects to display in the topology diagram below.

2. Topology Diagram—Provides visual representation of the policies configured in all of the Schema's templates that are assigned to sites.

You can choose which objects you want to display using the Configuration Options above.

You can also mouse over an objects to highlight all of its dependencies.

Part I. Operations

- System Configuration

- Audit Logs

- Backup and Restore

- Tech Support

- Upgrading NDO Service in Nexus Dashboard

Chapter 6. System Configuration

- System Configuration Settings

- System Alias and Banner

- Login Attempts and Lockout Time

System Configuration Settings

There is a number of global system settings that are available under Admin > System Configuration, which you can configure for your Multi-Site Orchestrator as described in the following sections.

System Alias and Banner

This section describes how to configure an alias for your Nexus Dashboard Orchestrator as well as enable a custom GUI-wide banner to be displayed at the top of your screen, as shown in the following figure.

System Banner Display

Procedure

Step 1

Log in to your Orchestrator.

Step 2

From the left navigation pane, select Admin > System Configuration.

Step 3

Click the Edit icon to the right of the System Alias & Banners area.

This opens the System Alias & Banners settings window.

Step 4

In the Alias field, specify the system alias.

Step 5

Choose whether you want to enable the GUI banner.

Step 6

If you enable the banner, you must provide the message that will be displayed on it.

Step 7

If you enable the banner, you must choose the severity, or color, for the banner.

Step 8

Click Save to save the changes.

Login Attempts and Lockout Time

When the Orchestrator detects a significant number of failed consecutive login attempts, the user is locked out of the system to prevent unauthorized access. You can configure how failed log in attempts are treated, for example the number of failed attempts before lockout and the length of the lockout.

Note

This feature is enabled by default when you first install or upgrade to Release 2.2(1) or later.

Procedure

Step 1

Log in to your Orchestrator.

Step 2

From the left navigation pane, select Admin > System Configuration.

Step 3

Click the Edit icon to the right of the Fail Attempts & Lockout Time area.

This opens the Fail Attempts & Lockout Time settings window.

Step 4

From the Fail Attempt Settings dropdown, select the number of attempts before the user is locked out.

Step 5

From the Lockout Time (Minutes) dropdown, select the length of the lockout.

This specifies the base lockout duration once it's triggered. The timer is extended up to three times exponentially with every additional consecutive login failure.

Step 6

Click Save to save the changes.

Chapter 7. Audit Logs

- Audit Logs

Audit Logs

Nexus Dashboard Orchestrator system logging is automatically enabled when you first deploy the Orchestrator cluster and captures the events and faults that occur in the environment.

You can view the Nexus Dashboard Orchestrator logs directly in the GUI by selecting Operations > Audit Logs from the main navigation menu.

From the Audit Logs page, you can click the Most Recent field to select a specific time period for which you want to see the logs. For example, when you select the range from November 14, 2019 to November 17, 2019 and click Apply, the audit log details for this time period are displayed on the Audit Logs page.

You can also click the Filter icon to filter the log details using the following criteria:

- User: Select this option to filter the audit logs by the user type, then click Apply to apply the filter.

- Type: Select this option to filter the audit logs by the policy types (for example, site, user, template) and click Apply.

- Action: Select this option to filter the audit logs by an action. The available actions are Created, Updated, Deleted, Added, Removed, Associated, Disassociated, Deployed, Undeployed, Downloaded, Uploaded, Restored, Logged in, Logged Out, Login Failed. Select an action and click Apply to filter the log details according to the action.

Chapter 8. Backup and Restore

- Configuration Backup and Restore

- Backup and Restore Guidelines

- Configuring a Remote Location for Backups

- Uploading Backups

- Creating Backups

- Restoring Backups

- Downloading Backups

- Backup Scheduler

Configuration Backup and Restore

You can create backups of your Nexus Dashboard Orchestrator configuration that can facilitate in recovering from Orchestrator failures or cluster restarts. We recommend creating a backup of the configuration before every upgrade or downgrade of your Orchestrator and after every configuration change or deployment. The backups are always created on a remote server (not Nexus Dashboard cluster), which is defined in the Nexus Dashboard Orchestrator as described in the following sections.

Backup and Restore Guidelines

When saving and restoring configuration backups, the following guidelines apply:

- Importing and restoring backups created from later releases is not supported.

For example, if you downgrade your Nexus Dashboard Orchestrator to an earlier release, you cannot restore a backup of the configuration created on a later release.

- Restoring configuration backups created on releases prior to Release 3.2(1) is supported as a one-time step during cluster migration to Nexus Dashboard.

Subsequent restore of backups from Multi-Site Orchestrator releases in VMware ESX or Application Services Engine deployments is not supported.

For detailed instructions on migrating your cluster to Nexus Dashboard, see the "Migrating Existing Cluster to Nexus Dashboard" chapter in the Cisco Nexus Dashboard Orchestrator Deployment Guide.

- When saving a backup, the configuration is saved in the same state in which it was deployed. When restoring a backup, any policies that were deployed will show as deployed, while any policies that were not deployed will remain in the undeployed state.

- Restoring a backup action restores the database on the Nexus Dashboard Orchestrator, but it does not make any changes to the controller (such as APIC, Cloud APIC, or NDFC/DCNM) databases on each site.

We recommend that after you restore the Orchestrator database you resolve any configuration drifts that may appear in the templates, as described in "Configuration Drifts" section of this guide, and then re-deploy the existing templates to avoid potentially mismatching policies between the Nexus Dashboard Orchestrator and each site's controller.

- Backups must be created on a remote location.

Prior to release 3.4(1), when you first deployed the cluster, any backups you created were saved to a default location on each node's local disk with an option to configure a remote location outside the Orchestrator cluster and relocate the backups there.

Starting with release 3.4(1), the local disk option has been deprecated and all backups must be created on a remote location outside the Nexus Dashboard cluster. You can configure a remote SCP or SFTP location using the NDO GUI and then exporting the backup files there as described in the following sections.

When you first upgrade from release 3.3(1) or earlier to release 3.4(1) or later, you will be able to download previously-created local backups as described in Downloading and Importing Older Local Backups. You can then re-import those backups into the Nexus Dashboard Orchestrator using a remote location.

Note

Local backups cannot be restored.

- When you create a configuration backup and export it to a remote server, the files are first created on the Orchestrator's local drives, then uploaded to the remote location, and finally deleted from the local storage. If there is not enough local disk space, the backup will fail.

- If you have a backup scheduler enabled to take local backups before upgrading to Release 3.4(1) or later, it will be disabled after the upgrade.

No Configuration Changes Since Backup

If there have been no policy changes between when the backup was created and when it is being restored, no additional considerations are required and you can simply restore the configuration as described in Restoring Backups.

Sites, Objects, or Policies Created, Modified, or Deleted Since Backup

If any configuration changes took place between the time when the configuration backup was created and the time it is being restored, consider the following:

- Restoring a backup will not modify any objects, policies, or configurations on the sites. Any new objects or policies created and deployed since the backup will remain deployed.

We recommend that after you restore the Orchestrator database you resolve any configuration drifts that may appear in the templates, as described in "Configuration Drifts" section of this guide, and then re-deploy the existing templates to avoid potentially mismatching policies between the Nexus Dashboard Orchestrator and each site's controller.

Alternatively, you can choose to undeploy all policies first, which will avoid any potential stale objects after the configuration is restored from backup. However, this would cause a disruption in traffic or services defined by those policies.

- The steps required to restore a configuration backup are described in Restoring Backups.

- If the configuration backup you restored was saved before it was deployed to the sites, it will be restored in the undeployed state and you can simply deploy it to the sites as necessary.

- If the configuration backup you restored was saved when the configuration was already deployed, it will be restored in the deployed state, even though none of the configurations will exist in the sites yet.

In this case, resolve any configuration drifts that may appear in the templates, as described in "Configuration Drifts" section of this guide and re-deploy the templates to sync the Nexus Dashboard Orchestrator's configuration with the sites.

- If sites that were managed when the backup was created are no longer present in the Nexus Dashboard, the restore will fail.

- If sites' status since the backup has changed (managed vs unmanaged) but the sites are still present in the Nexus Dashboard, the status will be restored to what it was at the time of backup.

- Downloading and Importing Older Local Backups

Downloading and Importing Older Local Backups

Releases prior to 3.4(1) supported creation of configuration backups on the Orchestrator's local disk. We recommend downloading any local backups before upgrading to release 3.4(1) or later. However, the local backups will still be available for download after the upgrade.

While you can download the old backups after the upgrade, you cannot restore them directly in the UI. This section describes how to download any such backups from the Orchestrator GUI to your local machine and then re-import them back into the Nexus Dashboard Orchestrator GUI this time using a remote location.

Before you begin

You must have completed the following:

- Upgraded from release 3.3(1) or earlier to release 3.4(1) or later, where local backups are no longer supported.

- Added a remote location for backups as described in Configuring a Remote Location for Backups.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Operations > Backups & Restore.

Step 3

In the main window, click the actions (...) icon next to the backup you want to download and select Download.

This will download the backup file to your system.

Step 4

Delete the backup you downloaded in the Nexus Dashboard Orchestrator GUI.

If you try to re-import the backup without deleting the existing local backup from previous version, the upload will fail as there is already a backup file with the same name.

To delete the backup you just downloaded, click the actions (...) menu next to the backup and select Delete.

Step 5

Import the backup to a remote location.

Simply re-upload the backup file you just downloaded back into the Nexus Dashboard Orchestrator but using a remote location, as described in Uploading Backups.

Configuring a Remote Location for Backups

This section describes how to configure a remote location in Nexus Dashboard Orchestrator to which you can then export your configuration backups.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator.

Step 2

From the left navigation pane, select Operations > Remote Locations.

Step 3

In the top right of the main window, click Add Remote Location.

An Add New Remote Location screen appears.

Step 4

Provide the name for the remote location and an optional description.

Two protocols are currently supported for remote export of configuration backups:

- SCP

- SFTP

Note

SCP is supported for non-Windows servers only. If your remote location is a Windows server, you must use the SFTP protocol

Step 5

Specify the host name or IP address of the remote server.

Based on your Protocol selection, the server you specify must allow SCP or SFTP connections.

Step 6

Provide the full path to a directory on the remote server where you will save the backups.

The path must start with a slash (/) characters and must not contain periods (.) or backslashes (\). For example, /backups/multisite.

Note

The directory must already exist on the remote server.

Step 7

Specify the port used to connect to the remote server.

By default, port is set to 22.

Step 8

Specify the authentication type used when connecting to the remote server.

You can configure one of the following two authentication methods:

- Password—provide the username and password used to log in to the remote server.

- SSH Private Files—provide the username and the SSH Key/Passphrase pair used to log in to the remote server.

Step 9

Click Save to add the remote server.

Uploading Backups

This section describes how to upload an existing configuration backup you have previously downloaded and import it into one of the remote locations configured in your Nexus Dashboard Orchestrator.

Before you begin

You must have completed the following:

- Created and downloaded a configuration backup as described in Creating Backups and Downloading Backups.

If your backup is already on a remote location, for example if it was created on release 3.4(1) or later, you can download it to your local machine and upload it to a different remote location.

- Added a remote location for backups as described in Configuring a Remote Location for Backups.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator.

Step 2

From the left navigation pane, select Operations > Backups & Restore.

Step 3

In the main pane, click Upload.

Step 4

In the Upload from file window that opens, click Select File and choose the backup file you want to import.

Uploading a backup will add it to the list of the backups displayed the Backups page.

Step 5

From the Remote Location dropdown menu, select the remote location.

Step 6

(Optional) Update the remote location path.

The target directory on the remote server, which you configured when creating the remote backup location, will be displayed in the Remote Path field.

You can choose to append additional subdirectories to the path. However, the directories must be under the default configured path and must have been already created on the remote server.

Step 7

Click Upload to import the file.

Importing a backup will add it to the list of the backups displayed the Backups page.

Note that even though the backups are shown on the NDO UI, they are located on the remote servers only.

Creating Backups

This section describes how to create a new backup of your Nexus Dashboard Orchestrator configuration.

Before you begin

You must first add the remote location as described in Configuring a Remote Location for Backups.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator.

Step 2

Backup existing deployment configuration.

1. From the left navigation pane, select Operations > Backups & Restore.

2. In the main window, click New Backup.

A New Backup window opens.

3. Provide the backup information.

- In the Name field, provide the name for the backup file.

The name can contain up to 10 alphanumeric characters, but no spaces or underscores (_).

- From the Remote Location drop-down, select a remote location you have configured for storing backups.

- (Optional) In the Remote Path, provide the specific directory on the remote server where to save the backup.

The directory you specify must already exist.

4. Click Save to create the backup.

Restoring Backups

This section describes how to restore a Nexus Dashboard Orchestrator configuration to a previous state.

Before you begin

- You must have configured a remote location for storing your NDO backups, as described in Configuring a Remote Location for Backups.

- Ensure that the backup you want to restore is on the remote location server or import the backup into the remote location, as described in Uploading Backups.

Note

Restoring a backup action restores the database on the Nexus Dashboard Orchestrator, but it does not make any changes to the controller (such as APIC, Cloud APIC, or NDFC/DCNM) databases on each site.

We recommend that after you restore the Orchestrator database you resolve any configuration drifts that may appear in the templates, as described in "Configuration Drifts" section of this guide, and then re-deploy the existing templates to avoid potentially mismatching policies between the Nexus Dashboard Orchestrator and each site's controller.

For information on specific configuration mismatch scenarios and recommended restore procedures related to each one, see Backup and Restore Guidelines.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

If necessary, undeploy existing policies.

We recommend you perform this step if new objects or policies were added to the configuration between when the backup was created and current configuration. Additional context is available in Backup and Restore Guidelines.

Step 3

From the left navigation menu, select Operations > Backups & Restore.

Step 4

In the main window, click the actions (...) icon next to the backup you want to restore and select Rollback to this backup.

If the version of the selected backup is different from the running Nexus Dashboard Orchestrator version, the rollback could cause a removal of the features that are not present in the backup version.

Step 5

Click Yes to confirm that you want to restore the backup you selected.

If you click Yes, the system terminates the current session and the user is logged out.

Note

Multiple services are restarted during the configuration restore process. As a result, you may notice an up to 10 minute delay before the restored configuration is properly reflected in the NDO GUI.

Step 6

Check if any templates contain configuration drifts.

You will repeat the following steps for every schema and template in your deployment

You can check for configuration drifts in one of the following two ways:

- Check the template deployment status icon for each site to which the template is assigned:

- Select the template and click Deploy to sites to bring up the configuration comparison screen to check which objects contain configuration drifts:

Step 7

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

For more information about configuration drifts, check the "Configuration Drifts" chapter in the Cisco Nexus Dashboard Orchestrator Configuration Guide for ACI Fabrics.

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 Reconcile Drift.

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. You can then click Deploy to sites to deploy the configuration and reconcile the drift for that template.

Step 8

After all configuration drifts are resolved and there are no changes shown in the Deploy to sites dialog for the template, perform full redeployment of the template.

Note

Due to database transformations in Release 3.7(1), you must perform a full redeployment of each template.

Ensure that the Deploy to sites dialog contains no changes as shown in the following figure, then click Deploy to redeploy complete configuration:

Step 9

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

Step 10

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

You can view the audit logs in the Operations tab.

Audit Logs page and confirm that all templates show as Redeployed to ensure that full re-deployment successfully completed.

Downloading Backups

This section describes how to download the backup from the Nexus Dashboard Orchestrator.

Before you begin

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Operations > Backups & Restore.

Step 3

In the main window, click the actions (...) icon next to the backup you want to download and select Download.

This will download the backup file in msc-backups-<timestamp>.tar.gz format to your system. You can then extract the file to view its contents.

Backup Scheduler

This section describes how to enable or disable the backup scheduler, which will perform complete configuration backup at regular intervals.

Before you begin

You must have already added a remote location for backups as described in Configuring a Remote Location for Backups.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

From the left navigation menu, select Operations > Backups & Restore.

Step 3

In the top right of the main pane, click Scheduler.

The Backup Scheduler Settings window will open.

Step 4

Set up backup scheduler.

1. Check the Enable Scheduler checkbox.

2. In the Select Starting Date field, provide the day when you want the scheduler to start.

3. In the Select Time fields, provide the time of day when you want the scheduler to start.

4. From the Select Frequency dropdown, choose how often the backup should be performed

5. From the Remote Location dropdown, select the location where the backups will be saved.

6. (Optional) In the Remote Path field, update the path on the remote location where the backups will be saved.

The target directory on the remote server, which you configured when creating the remote backup location, will be displayed in the Remote Path field.

You can choose to append additional subdirectories to the path. However, the directories must be under the default configured path and must have been already created on the remote server.

7. Click OK to finish.

Step 5

If you want to disable the backup scheduler, simply uncheck the Enable Schedulercheckbox in the above step.

Chapter 9. Tech Support

- Tech Support and System Logs

- Downloading System Logs

- Streaming System Logs to External Analyzer

Tech Support and System Logs

Nexus Dashboard Orchestrator system logging is automatically enabled when you first deploy the Orchestrator cluster and captures the events and faults that occur in the environment.

You can choose to download the logs at any time or stream them to an external log analyzer, such as Splunk, if you want to use additional tools to quickly parse, view, and respond to important events without a delay.

Starting with Release 3.3(1), the tech support logs are split into two parts:

- Original database backup files containing the same information as in prior releases

- JSON-based database backup for ease of readability

Within each backup archive, you will find the following contents:

- x.x.x.x—one or more files in x.x.x.x format for container logs available at the time of the backup.

- msc-backup-<date>_temp—Original database backup containing the same information as previous releases.

- msc-db-json-<date>_temp—Backup contents in JSON format.

For example:

msc_anpEpgRels.json
msc_anpExtEpgRels.json
msc_asyncExecutionStatus.json
msc_audit.json
msc_backup-versions.json
msc_backupRecords.json
msc_ca-cert.json
msc_cloudSecStatus.json
msc_consistency.json
...

Downloading System Logs

This section describes how to generate a troubleshooting report and infrastructure logs file for all the schemas, sites, tenants, and users that are managed by Nexus Dashboard Orchestrator.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

Open the System Logs screen.

1. In the main menu, select Operations > Tech Support.

2. In the top right corner of the System Logs frame, click the edit button.

Step 3

Click Download download the logs.

An archive will be downloaded to your system. Containing all the information as described in the first section of this chapter.

Streaming System Logs to External Analyzer

Nexus Dashboard Orchestrator allows you to send the Orchestrator logs to an external log analyzer tool in real time. By streaming any events as they are generated, you can use the additional tools to quickly parse, view, and respond to important events without a delay.

This section describes how to enable Nexus Dashboard Orchestrator to stream its logs to an external analyzer tool, such as Splunk or syslog.

Before you begin

- This release supports only Splunk and syslog as external log analyzer.

- This release supports syslog only for Nexus Dashboard Orchestrator in Nexus Dashboard deployments.

- This release supports up to 5 external servers.

- If using Splunk, set up and configure the log analyzer service provider.

For detailed instructions on how to configure an external log analyzer, consult its documentation.

- If using Splunk, obtain an authentication token for the service provider.

Obtaining an authentication token for Splunk service is detailed in the Splunk documentation, but in short, you can get the authentication token by logging into the Splunk server, selecting Settings > Data Inputs > HTTP Event Collector, and clicking New Token.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

Open the System Logs screen.

1. In the main menu, select Operations > Tech Support.

2. In the top right corner of the System Logs frame, click the edit button.

Step 3

In the System Logs window, enable external streaming and add a server.

1. Enable the External Streaming knob.

2. Choose whether you want to stream All Logs or just the Audit Logs.

3. Click Add Server to add an external log analyzer server.

Step 4

Add a Splunk server.

If you do not plan to use Splunk service, skip this step.

1. Choose Splunk for the server type.

2. Choose the protocol.

3. Provide the server name or IP address, port, and the authentication token you obtained from the Splunk service.

Obtaining an authentication token for Splunk service is detailed in the Splunk documentation, but in short, you can get the authentication token by logging into the Splunk server, selecting Settings > Data Inputs > HTTP Event Collector, and clicking New Token.

4. Click the checkmark icon to finish adding the server.

Step 5

Add a syslog server.

If you do not plan to use syslog, skip this step.

1. Choose syslog for the server type.

2. Choose the protocol.

3. Provide the server name or IP address, port number, and the severity level of the log messages to stream.

4. Click the checkmark icon to finish adding the server.

Step 6

Repeat the steps if you want to add multiple servers.

This release supports up to 5 external servers.

Step 7

Click Save to save the changes.

Chapter 10. Upgrading NDO Service in Nexus Dashboard

- Overview

- Prerequisites and Guidelines

- Upgrading NDO Service Manually

- Restore Existing Configuration for Database Optimization

- Resolve Configuration Drifts

Overview

The following sections describe how to upgrade Cisco Nexus Dashboard Orchestrator that is deployed in Cisco Nexus Dashboard.

If you are running an earlier release deployed in VMware ESX VMs or Cisco Application Services Engine, you must deploy a brand new cluster and then transfer the configuration from your existing cluster, as described in the "Migrating Existing MSO Cluster to Nexus Dashboard" chapter of the Cisco Nexus Dashboard Orchestrator Deployment Guide instead.

Prerequisites and Guidelines

Before you upgrade your Cisco Nexus Dashboard Orchestrator cluster:

- When upgrading an existing Nexus Dashboard Orchestrator release 3.2(1) or later, we recommend upgrading to release 3.7(2).

At this time, stateful upgrades from release 3.2(1) or later to release 4.x are not supported. You can migrate to a 4.x release as described in Cisco Nexus Dashboard Orchestrator Deployment Guide, Release 4.0(x), however we recommend upgrading to release 3.7(2) instead.

- We recommend that you first familiarize yourself with the Nexus Dashboard platform and overall deployment overview and guidelines described in the Cisco Nexus Dashboard Deployment Guide and the Cisco Nexus Dashboard Orchestrator Deployment Guide for your release.

Note

Ensure that you have followed the Nexus Dashboard deployment prerequisites and guidelines (such as CPU, RAM, and disk requirements) for the cluster where you deploy your Nexus Dashboard Orchestrator. Specifically, if you have a virtual cluster, the CPU and RAM system requirements must be available with physical reservation.

- Stateful upgrades from releases prior to Release 3.2(1) are not supported.

If you are upgrading from an earlier release, skip the rest of this chapter and follow the instructions described in the "Migrating Existing Cluster to Nexus Dashboard" chapter of the Cisco Nexus Dashboard Orchestrator Deployment Guide.

- Ensure that your current Nexus Dashboard cluster is healthy.

You can check the Nexus Dashboard cluster health in one of two ways:

- By logging into your Nexus Dashboard GUI and verifying system status in the System Overview page.

- By logging into any one of the nodes directly as rescue-user and running the following command:

# acs health
All components are healthy

- Ensure that your current Cisco Nexus Dashboard Orchestrator is healthy.

- When upgrading to this release, you will manually download the upgrade image and install it as described in Upgrading NDO Service Manually.

You must manually download the upgrade image because the DC App Center includes only the latest release of NDO and stateful upgrades from release 3.2(1) or later to release 4.x are not supported.

- If you plan to add and manage new Cloud APIC sites after you upgrade your Nexus Dashboard Orchestrator to this release, you must ensure that they are running Cloud APIC release 5.2(1) or later.

On-boarding and managing Cloud APIC sites running earlier releases is not support.

- Ensure that there are no configuration drifts between the Orchestrator's configuration and what is actually deployed in the fabrics before you upgrade.

Note

Any templates that have configuration changes that are not yet deployed to the sites may cause the upgrade to fail.

More information on resolving configuration drifts is available in the "Schemas" chapter of the Nexus Dashboard Orchestrator Configuration Guide for your current release.

- Back up your existing Orchestrator configurations.

Configuration backups are described in the "Backup and Restore" chapter of the Nexus Dashboard Orchestrator Configuration Guide for your release.

- Back up your existing fabrics' configurations.

We recommend creating configuration backups of all fabrics managed by your Nexus Dashboard Orchestrator:

- For more information on creating Cisco APIC configuration backups, see the "Management" chapter of the Cisco APIC Basic Configuration Guide for your release.

- For more information on creating Cisco Cloud Network Controller configuration backups, see the "Configuring Cisco Cloud Network Controller Components" chapter of the Cisco Cloud Network Controller for AWS User Guide for your release.

- For more information on creating Cisco Nexus Dashboard Fabric Controller configuration backups, see the "Backup and Restore" chapter of the Cisco NDFC Fabric Controller Configuration Guide for your release.

- Once you upgrade to this release, downgrading to an earlier release is not supported.

If you want to revert to an earlier release, you will need to re-install the NDO service and restore a configuration backup from that release.

Upgrading NDO Service Manually

This section describes how to upgrade Cisco Nexus Dashboard Orchestrator.

Before you begin

- Ensure that you have completed the prerequisites described in Prerequisites and Guidelines.

Procedure

Step 1

Download the target 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.

Note

We recommend upgrading to release 3.7(2).

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

Step 2

Log in to your Nexus Dashboard.

Step 3

Upload the image to your Nexus Dashboard.

1. From the left navigation menu, select Service Catalog.

2. In the Nexus Dashboard's Service Catalog 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 4

Wait for the new image to initialize.

It may take up to 20 minutes for the new application image to become available.

Step 5

Activate the new image.

1. In the Service Catalog screen, select the Installed Services tab.

2. In the top right 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 6

(Optional) Delete the old application image.

Downgrading from this release is not supported so we recommend delete the old Orchestrator release image as described in this step.

1. In the Service Catalog screen, select the Installed Services tab.

2. In the top right 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 previous image.

Step 7

Launch the app.

To launch the app, simply click Open on the application tile in the Nexus Dashboard's Service Catalog page.

The single sign-on (SSO) feature allows you to log in to the application using the same credentials as you used for the Nexus Dashboard.

What to do next

After you have upgraded the NDO service, we recommend you go through the configuration restore workflow to optimize your database, as described in Restore Existing Configuration for Database Optimization and then you must resolve any configuration drifts and redeploy the templates as described in Resolve Configuration Drifts.

Restore Existing Configuration for Database Optimization

Release 3.7(2) added database optimization functionality to the configuration restore workflow. After your upgrade is complete, we strongly recommend going through configuration restore process in order to update your existing configuration databases.

Note

Skipping this procedure may result in stale values from older configuration changes to remain in the database.

Before you begin

You must have:

- Upgraded your Nexus Dashboard Orchestrator as described in Upgrading NDO Service Manually.

- A backup of the existing configuration taken right before the upgrade to Release 3.7(2)

Procedure

Step 1

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

Step 2

Restore the configuration.

1. In the main window, click the actions (…) icon next to the backup you created prior to the upgrade and select Rollback to this backup.

This opens the Restore from this backup warning dialog.

2. In the Restore from this backup dialog window, click Restore to confirm that you want to restore the backup you selected.

The time required for the database rollback and optimization to complete depends on the size of your configuration. Very large configurations may take up to an hour to finish.

3. After the database is restored, click Update NDO Database to complete database optimization.

Release 3.7(2) added database optimization functionality to the configuration restore workflow. So you will get an additional prompt for database optimization workflow.

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 version's configuration 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 underlay and overlay connectivity is still successfully established.

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 APIC 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 APIC in earlier Nexus Dashboard Orchestrator releases.

Resolve Configuration Drifts

In some cases you may run into a situation where the configuration actually deployed in the site's controller is different from the configuration defined in the Nexus Dashboard Orchestrator. These configuration discrepancies are referred to as Configuration Drifts and are indicated by a yellow warning sign next to the template name in the schema view as shown in the following figure.

When migrating to NDO release 3.7(2) or later, enhancements have been introduced in the configuration rollback procedure to ensure that the content of the NDO database can be fully rebuilt based on the configuration information present in the backup file. This means that if some of the templates in your existing configuration were not fully deployed when the backup file was originally created (for example, left in the “edit” state), the NDO configuration for those templates would be based on that state and may differ from the configuration actually deployed on the fabrics' controllers resulting in a configuration drift.

Before you begin

You must have upgraded your Nexus Dashboard Orchestrator as described in Upgrading NDO Service Manually.

Procedure

Step 1

Check for configuration drifts using the API.

Beginning with release 3.7(2), you can generate a list of all templates that contain configuration drifts by using the /api/v1/schemas/template-modified-policy-states API call directly from your Nexus Dashboard Orchestrator's GUI as described in this step.

Alternatively, you can manually check every schema and template individually as described in the next step.

1. Ensure that you are logged in to you Orchestrator UI.

The API uses the authentication token from the Orchestrator UI login.

2. From the Help menu in the top right corner of the window, choose Help Center.

3. In the Help Center's Programming tile, click REST API.

4. From the dropdown at the top of the page, select Nexus Dashboard Orchestrator to show NDO APIs.

5. Scroll down to the /api/v1/schemas/template-modified-policy-states API and click Run.

Depending on the number of templates and the size of the configuration, this may take a few minutes, and the Run button will be grayed out during this process.

6. Note down all the templates returned by the API call.

Step 2

Check for configuration drifts using the GUI.

1. In your Nexus Dashboard Orchestrator, navigate to Application Management > Schemas.

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

You will repeat the following steps for every schema and template in your deployment

You can check for configuration drifts in one of the following two ways:

- Check the template deployment status icon for each site to which the template is assigned:

- Select the template and click Deploy to sites to bring up the configuration comparison screen to check which objects contain configuration drifts:

Step 3

For eveyr template that contains a configuration drift, resolve the conflicts.

For more information about configuration drifts, check the "Configuration Drifts" chapter in the Cisco Nexus Dashboard Orchestrator Configuration Guide for ACI Fabrics.

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 Reconcile Drift.

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. You can then click Deploy to sites to deploy the configuration and reconcile the drift for that template.

Part II. Features and Use Cases

- Brownfield Import of VRFs and Networks

Chapter 11. Brownfield Import of VRFs and Networks

- Overview

- Prerequisites

- Create Schema and Templates for Importing Configuration

- Importing Schema Elements From DCNM Sites

- Deploying Template and Making Changes

Overview

The following sections describe the brownfield import use case scenario which will allow you to import existing DCNM fabric configurations, including fabrics that are part of a Multi-Site Domain (MSD), and to stretch those configurations across multiple greenfield or brownfield fabrics from a single location using Nexus Dashboard Orchestrator. The same use case is demonstrated in the Cisco DCNM VRF and Network Configuration using Nexus Dashboard Orchestrator video demo.

The examples in this chapter will use two different DCNM controllers where Fabric-1 from the first DCNM is a single fabric, while Fabric-2 and Fabric-3 are part of an MSD and are managed by the second DCNM:

The following sections will detail how to import existing configuration, then stretch it from one fabric to another managed by different DCNMs, as well as how to deploy brand new VRFs and networks.

Prerequisites

Before you can import and manage VRFs and networks from the existing DCNM fabrics in your environment, you must have the following:

- Nexus Dashboard cluster deployed and the Nexus Dashboard Orchestrator service installed, as described in Cisco Nexus Dashboard Deployment Guide and Cisco Nexus Dashboard Orchestrator Deployment Guide.

- Existing DCNM fabrics on-boarded in the Nexus Dashboard and enabled for management in the Nexus Dashboard Orchestrator GUI, as described in Adding and Deleting Sites.

- Have the inter-site infrastructure configured and deployed, as described in Configuring Infra for Cisco DCNM Sites.

Expanding on the example fabrics show in the "Overview" section above, after you configure the Infra settings for all fabrics, you will see the inter-site connectivity deployed to each DCNM:

Create Schema and Templates for Importing Configuration

This section describes how to create a schema and template where you will import existing and then create new configurations.

Before you begin

- You must have reviewed and completed the prerequisites described in Prerequisites.

Procedure

Step 1

Log in to your Nexus Dashboard Orchestrator GUI.

Step 2

Create a new schema.

1. From the left navigation pane, choose Application Management > Schemas.

2. On the Schemas page, click Add Schema.

3. In the schema creation dialog, provide the Name and optional description for the schema.

By default, the new schema is empty, so you need to add one or more templates.

Step 3

Create a template.

We recommend creating two separate templates: one for the VRFs and one for Networks. The following two steps will describe how to create a tempalte.

1. In the left sidebar under Templates, click the + sign to add a new template.

2. In the Select a Template type window, choose Networking for the template type.

3. Click Add to create the template.

Step 4

Provide the name and the tenant for the template.

1. In the right sidebar, specify the Display Name for the template.

2. From the Select a Tenant dropdown, select the dcnm-default-tn tenant.

This tenant is created in NDO by default specifically for defining objects and configurations for DCNM sites

Step 5

Repeat the pervious two steps to create a second template.

In this release, we recommend creating separate templates for VRFs and Networks within each schema and then deploying the VRF templates first, followed by the templates that contain Networks. This way any VRFs required by the networks will be already created when you push Network configuration to the sites.

Similarly, when undeploying multiple networks and VRFs, we recommend undeploying the Networks template first, followed by the VRF templates. This will ensure that when VRFs are undeployed, there will be no conflicts with any existing Networks still using them.

Step 6

In the top right corner of the schema view, click Save to save the schema and template.

You must save the schema and template you created before you can import configuration.

Importing Schema Elements From DCNM Sites

This section describes how to import configuration from existing fabrics.

Before you begin

- You must have associated the template with the existing fabrics as described in the previous section.

Procedure

Step 1

In the main pane click the Import button and select the Site from which you want to import.

You can import from one fabric at a time, so you will repeat tese steps for each fabric.

Step 2

In the Import from <site-name> window that opens, select one or more VRFs.

1. In the import screen, you can select all or some of the existing objects.

In the example above, we import ENG-11 and CORP-11 networks from Fabric-2 which is part of the MSD.

Note

The names of the objects imported into the Nexus Dashboard Orchestrator must be unique across all sites. Importing different objects with duplicate names will cause a schema validation error and the import to fail. If you want to import objects that have the same name, you must first rename them.

2. Esnure that the Include Relations box is unchecked.

You will import the VRFs separately into the second template.

3. Click Import to import the objects.

Step 3

Repeat the steps to import Networks from other fabrics.

If you select the template under the site from which you imported (Fabric-2 in this example), the networks will have switch and port configuration already created as they were imported from that site. However, if you select the template under a different fabric (Fabric-3), where the same networks also exist, the switch configuration will be empty.

To get the interface configuration for the networks we imported, we import the same networks again from the other fabric.

Step 4

Select the second template and repeat previous two steps to import all required VRFs.

As best practice, you will use one of the templates to import the VRF configuration from your sites and the other template to import the Network configuration.

Deploying Template and Making Changes

This section describes how to deploy the imported configuration to the site where it doesn't yet exist.

Before you begin

You must have the configuration imported as described in the previous section.

Procedure

Step 1

In the left sidebar, select the template you want to deploy.

Following the same example, you can use the DCNM UI to verify that the networks and VRFs you have imported from Fabric-2 and Fabric-3 do not yet exist in Fabric-1.

Step 2

In the top right of the template edit view, click Deploy to sites.

The Deploy to Sites window opens that shows the summary of the objects to be deployed.

Step 3

Click Deploy to deploy the template.

Since this is the first time you are deploying this template, the Deploy to Sites summary will show the configuration difference that will be deployed to sites.

It may take a few minutes for the configuration to get deployed. After you see a confirmation message in the NDO GUI, you can verify that the configuration was deployed using the DCNM UI:

Step 4

Assign switch ports to the new network.

We have verified that the network you imported from Fabric-2 and Fabric-3 was deployed to Fabric-1, we need to assign one or more switch ports to it for Fabric-1.

1. Select the template under Fabric-1.

2. Select the Network we deployed.

3. In the right sidebar, click Add Static Ports.

In the Add Static Port window that opens, select the switch and the port to which you want to assign the network's VLAN. Then click Save.

Step 5

Save and redeploy the template with the new configuration changes.

You can once again verify the change by navigating back to the DCNM GUI and refreshing the Networks page. The status of the network will go from NA to In Progress to Deployed.

Trademarks

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS REFERENCED IN THIS DOCUMENTATION ARE SUBJECT TO CHANGE WITHOUT NOTICE. EXCEPT AS MAY OTHERWISE BE AGREED BY CISCO IN WRITING, ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS DOCUMENTATION ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.

The Cisco End User License Agreement and any supplemental license terms govern your use of any Cisco software, including this product documentation, and are located at: http://www.cisco.com/go/softwareterms.Cisco product warranty information is available at http://www.cisco.com/go/warranty. US Federal Communications Commission Notices are found here http://www.cisco.com/c/en/us/products/us-fcc-notice.html.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any products and features described herein as in development or available at a future date remain in varying stages of development and will be offered on a when-and if-available basis. Any such product or feature roadmaps are subject to change at the sole discretion of Cisco and Cisco will have no liability for delay in the delivery or failure to deliver any products or feature roadmap items that may be set forth in this document.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com go trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)