Nexus Dashboard Orchestrator Fabric Management, Release 4.4.1

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.

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

Three default tenants are pre-configured for you:

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 fabrics. 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-Fabric 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-Fabric Verified Scalability Guides for your release.

The Nexus Dashboard Orchestrator GUI will ensure that any concurrent updates on the same fabric or schema object cannot unintentionally overwrite each other. If you attempt to make changes to a fabric 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:

Figure 1. Concurrent Configuration Updates

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.

When enabling this feature, note the following:

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,*
    "fabrics": [...]
}

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

---

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,*
      "fabrics": [...]
  }

• 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"
}

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

This feature is supported for Cisco APIC and Cisco NDFC fabrics only; it is not supported for Cisco Cloud Network Controller fabrics.

The following example will walk you through the process.

This section describes how to rename a template. In previous NDO releases, performing this operation only changed the "Display Name" for the template. From NDO 4.4 release, both the "Display Name" and the "Internal Name" (i.e. the name in the NDO internal database) for the template are changed.

In order to change the template name, ensure there are no unsaved changes in the schema.

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:

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

This section describes how to deploy new or updated configuration to NDFC fabrics. . Navigate to the schema that contains the template that you want to deploy.

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

Occasionally, you may run into a situation where the configuration actually deployed in a NDFC 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:

Figure 11. Configuration Drifts

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:

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

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 controllers of the fabrics part of the Multi-Fabric 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 directly) and give the user the choice on how to reconcile the drift, as described in the steps below.

---

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.

---

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

2. From the template’s Actions menu, select Reconcile Drift.

   

   Figure 12.

   The Drift Reconciliation wizard opens.

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

   

   Figure 13.

   Template-level properties are common across all fabrics associated to the template. You can compare the template level properties defined on Nexus Dashboard Orchestrator with the configuration rendered in each fabric and decide what should become the new configuration in the Nexus Dashboard Orchestrator template. Selecting the fabric 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 Fabric Specific Properties to switch to fabric-level configuration.

   

   Figure 14.

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

   Even though in most scenarios you will make the same choice for both template-level and fabric-level configuration, the drift reconciliation wizard allows you to choose the configuration defined in the fabric’s controller at the "Template Properties" level and the configuration defined in Nexus Dashboard Orchestrator at the "Fabric 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 fabrics to deploy the configuration and reconcile the drift for that template.

You can view all objects currently deployed to fabrics 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 Fabric1, 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 fabric’s controller.

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.

Figure 15. Schema Overview

The following details are provided on this page:

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.

Figure 16. Deployment Visualizer

First Published: 2024-03-11
Last Modified: 2024-07-26

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883