Nexus Dashboard Orchestrator Templates Overview and Operations for ACI Fabrics, Release 4.4.1

ACI Multi-Cloud-Templates used for Cisco ACI on-premises and cloud fabrics. This template supports two deployment types:

The following sections focus primarily on this type of templates.

NDFC-Templates designed for Cisco Nexus Dashboard Fabric Controller (formerly Data Center Network Manager) fabrics.

This guide describes Nexus Dashboard Orchestrator configurations for on-premises Cisco ACI fabrics. For information on working with Cisco NDFC fabrics, see the Cisco Nexus Dashboard Orchestrator Configuration Guide for NDFC Fabrics instead.

Cloud Local-Templates designed for specific Cloud Network Controller use cases, such as Google Cloud fabric connectivity, and cannot be stretched between multiple fabrics.

This guide describes Nexus Dashboard Orchestrator configurations for on-premises Cisco ACI fabrics. For information on working with Cloud Network Controller fabrics, see the Nexus Dashboard Orchestrator use case library instead.

Single Template Deployment

The simplest schema design approach is a single schema, single template deployment. You can create a single schema with a single template within it and add all VRFs, Bridge Domains, EPGs, Contracts and other elements to that template and deploy it to one or more fabrics.

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

Note also that with this approach all the objects defined in the template become "stretched objects" and all changes made to the template are always simultaneously deployed to all the fabrics associated to such template.

Multiple Templates with Network Separation

Another approach to schema design is to separate the networking objects from the application policy configuration. Networking objects include VRFs, Bridge Domains, and subnets, while the application policy objects include EPGs, Contracts, Filters, External EPGs, and Service Graphs.

You begin by defining a schema that contains the network elements. You can choose to create a single schema that contains all the network elements or you can split them into multiple schemas based on which applications reference them or which fabrics the network is stretched to.

You can then define one or more separate schemas which contain each application’s policy objects. This new schema can reference the network elements, such as bridge domains, defined in the previous schema.

After creating and deploying the policy schemas and templates, the networking objects in the networking schema will display the number of external references by the policy schema elements. The object with external references will also be denoted by the ribbon icon.

Schemas designed this way provide logical separation of networking objects from the policy objects. However, this creates additional complexity when it comes to keeping track of externally referenced objects in each schema.

Multiple Templates 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 fabrics. Because of that, you may choose to create a template around each individual fabric that contains only the objects used by that fabric and its applications, including the VRFs, BDs, EPGs, Contracts, and Filters. And create different templates containing the shared objects.

For example, you can create a Fabric1 template that contains only the objects that are local to Fabric1 and the template is deployed to only that fabric. Similarly, the Fabric2 template contains only the object relevant to fabric2 and is deployed to that fabric only. Any change made to any object in either of these templates has no effect on the other one. Then you can create a Shared template which contains objects that are shared between the fabrics.

You can extend this scenario for an additional fabric with the following template layout:

Similarly, rather than separating objects based on which fabric 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 fabrics as well as easily configure each application as local or stretched across fabrics.

+ 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 fabric or application.

Fabric Policies templates can be used for managing the following fabric-wide policies:

For additional information, see Creating Fabric Policies.

Fabric Resources Policies templates can be used for managing the following fabric-wide policies:

These templates reference policies are defined in the Fabric Policies templates, so those templates must be created and deployed first. For additional information, see Creating Fabric Resources Policies.

Monitoring Policy templates can be used for managing Tenant SPAN or Access SPAN policies.

For additional information, see Creating Monitoring Policies.

All policy objects must be deployed in order according to their dependencies.

For example, when creating a bridge domain (BD), you must associate it with a VRF. In this case, the BD has a VRF dependency so the VRF must be deployed to the fabric before or together with the BD. If these two objects are defined in the same template, then the Orchestrator will ensure that during deployment, the VRF is created first and associate it with the bridge domain.

However, if you define these two objects in separate templates and attempt to deploy the template with the BD first, the Orchestrator will return a validation error as the associated VRF is not yet deployed. In this case, you must deploy the VRF template first, followed by the BD template.

All policy objects must be undeployed in order according to their dependencies, or in the oppofabric order in which they were deployed.

As a corollary to the point above, when you undeploy templates, you must not undeploy objects on which other objects depend. For example, you cannot undeploy a VRF before undeploying the BD with which the VRF is associated.

No cyclical dependencies are allowed across multiple templates.

Consider a case of a VRF (vrf1) associated with a bridge domain (bd1), which is in turn associated with an EPG (epg1). If you create vrf1 in template1 and deploy that template, then create bd1 in template2 and deploy that template, there will be no validation errors since the objects are deployed in correct order. However, if you then attempt to create epg1 in template1, it would create a circular dependency between the two template, so the Orchestrator will not allow you to save template1 addition of the EPG.

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*
    }
]

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

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

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

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

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

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.

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

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

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

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

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

Configuration is modified directly in the fabric’s APIC-while the objects deployed from NDO are indicated by a warning icon and text in the fabric’s APIC, an admin user can still make changes to them causing the configuration drift.

Every time an object is modified on APIC, APIC sends a notification to Nexus Dashboard Orchestrator. On receiving the notification, Nexus Dashboard Orchestrator starts a 30 second timer (waiting for further notifications to arrive) and at the expiration of such timer then makes API calls to APIC to retrieve detailed information about the changes made all the objects for which it received a notification. This allows the Nexus Dashboard Orchestrator to display the drift symbol on the UI for all the templates where those objects are defined. The only exception to this behavior is when Nexus Dashboard Orchestrator deploys the configuration for all (or of a subset of) the objects defined in a specific template. In that case, for 60 seconds Nexus Dashboard Orchestrator would ignore any notification received from APIC relative to those specific objects and, as a consequence, it would not be able to display the drift symbol on the UI.

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 APIC 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 fabric’s APIC 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.