Templates Overview and Operations for ACI Fabrics, Release 4.3.1

The following table provides an overview of the significant changes up to this current release. The table does not provide an exhaustive list of all changes or of the new features up to this release.

Nexus Dashboard provides a number of policy templates that allow you to define one or more policies together and deploy them to one or more fabrics at the same time. These include Application templates, Tenant Policies templates, Fabric Policies and Fabric Resources Policies templates, and Monitoring templates. A schema is a collection of Application templates, which are used for defining application policies, with each template assigned to a specific tenant; schemas apply to Application templates only. There are multiple approaches you can take when it comes to creating the templates 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 domain.

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 Nexus Dashboard Verified Scalability Guides for your release.

The Nexus Dashboard 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:

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 Nexus Dashboard to keep track of configuration changes.

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

This section describes how to rename a template. Both the "Display Name" and the "Internal Name" (i.e. the name in the Nexus Dashboard internal database) for the template are changed in this procedure.

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

This section describes how to assign a template to fabrics.

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 Nexus Dashboard while removing the template-fabric association in the schema. The managed object and policy ownership is transferred from Nexus Dashboard to the fabric’s controller.

Disassociate is supported on all templates.

When you use the Disassociate Fabric operation in the orchestrator, understand its effect on different template types:

This section describes how to deploy new or updated policies to the ACI fabrics.

This section describes how to undeploy a template from a fabric. Undeploying a template removes all configurations defined in that template from a specific fabric where the template is deployed.

This action removes managed objects (MOs) and their properties from the fabric’s controller and can disrupt the network connectivity that depends on those configurations.

The bulk update feature allows you to update multiple properties on multiple different objects of the same type within a template at once. For example, you can enforce Infra EPG Isolation on two or more EPGs at the same time, instead of having to modify each object individually. When using this workflow, all selected objects must be of the same type, for example, you cannot choose to update an EPG and a BD simultaneously.

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 allows you update template-level object properties for on-premises; updating fabric-local properties is not supported.

This feature is supported for Application templates only with Cisco NDFC fabrics; it is not supported for other template types, or Cisco APIC.

A new version of the template is created every time it is saved. From within the Nexus Dashboard 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 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 Nexus Dashboard UI, a template designer can request review on the template they create, and also approve their own designed templates. 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 Support Engineer role. Finally, the deployers themselves can deny deployment of an approved template and restart the review process from the beginning. Once deployed, the user with Support Engineer role cannot deny their own deployed template. You can redeploy or if any edits are made on the template, the approval process must be completed before a new deployment.

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

Occasionally, you may run into a situation where the configuration deployed to an APIC fabric differs from the configuration you defined for that fabric in Orchestrator. These discrepancies are called configuration drifts, and Orchestrator flags them with an Out of sync warning on the Templates page, as shown in the following figure.

Orchestrator detects a configuration drift whenever the configuration you define in a template diverges from the configuration present on the APIC.

Orchestrator supports drift detection for Application templates, including supported top-level objects (such as VRFs, bridge domains, EPGs, ESGs, external EPGs, contracts, and filters) and their nested properties (such as subnets, contract relationships, static ports, domain associations, uSeg attributes, EPG selectors, and filter entries).

The following table details the parent objects and their supported nested properties for drift detection in Application templates.

When Orchestrator detects a drift, it marks the affected template Out of sync and displays a Config Drift indicator on the Deploy view. You can hover over the indicator and choose View details to view a detailed comparison of the configuration you defined in Orchestrator against the configuration currently on the APIC. From there, you can launch the drift reconciliation workflow to resolve the differences—either by accepting the APIC changes to update the Orchestrator template or by redeploying the Orchestrator configuration to overwrite the changes on the APIC.

For properties not covered by automatic drift detection, you can check for configuration drift manually by running the drift reconciliation workflow. For more information, see Reconcile configuration drift in application templates.

When you deploy a template from Orchestrator, it suppresses drift notifications for objects in that template for 60 seconds. Orchestrator does not detect any configuration changes you make directly on the APIC during this window as drift.

Orchestrator does not support all APIC configurations, and even for APIC objects that are supported by Orchestrator, it may not support all attributes or nested child objects. For such configurations, these can be managed locally on APIC, and Orchestrator will not overwrite configurations when deploying templates or detect any configuration drifts for any objects managed locally on APIC that are not supported.

For example, Orchestrator does not support every EPG domain association type, such as Nutanix domains. For domains not supported on Orchestrator, they can be managed locally on APIC.

Details for the APIC object models can be found in Cloud APIC & APIC Object Model Documentation, Release 6.1(x).

This section describes how to create a copy of an existing template using the "Clone Template" feature in the Schema view.

Before deploying a cloned template, change its site association. You cannot deploy templates with identical object names to the same site, regardless of their source template. To avoid deployment failure, rename the objects or associate the cloned template with a different site.

This section describes how to move objects between templates or schemas. In Nexus Dashboard 4.1.1, you can now manage and migrate VRF, EPG, External EPG, ESG, contracts, filters, and bridge domain objects.

These restrictions apply when moving objects:

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 BD1 and redeploy, the API will return both objects, BD1 and VRF1, 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 ACI fabrics, the schema Overview page will provide you with a summary of the deployment.

Schema Overview and Deployment Visualizer

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.

Deployment Visualizer

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

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 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: https://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. (1110R)

© 2017-2026 Cisco Systems, Inc. All rights reserved.

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