Application Templates

There are 3 types of schema templates, also known as application templates, available in Nexus Dashboard Orchestrator, each designed for a specific purpose:

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

  • Multi-Site - The template can be associated to a single site (site-local policies) or to multiple sites (stretched policies) and the option should be selected for Multi-Site Network (ISN) or VXLAN intersite communication to allow template and object stretching between multiple sites.

  • Autonomous - The template can be associated to one or more sites that are operated independently and are not connected through an Inter-Site Network (no intersite VXLAN communication).

    Because autonomous sites are by definition isolated and do not have any intersite connectivity, there is no shadow object configuration across sites and no cross-programming of pctags or VNIDs in the spine switches for intersite traffic flow.

    The autonomous templates also allow for significantly higher deployment scale.

  The following sections focus primarily on this type of templates.

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

  This guide describes Nexus Dashboard Orchestrator configurations for on-premises Cisco ACI fabrics. For information on working with Cisco NDFC sites, 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 site connectivity, and cannot be stretched between multiple sites.

  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.

When creating schemas and application templates, you can choose to adopt one of the following simple approaches:

• 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 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 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 sites 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 sites 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 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, including the VRFs, BDs, EPGs, Contracts, and Filters. And create different templates containing the shared objects.

  For example, you can create a Site1 template that contains only the objects that are local to Site1 and the template is deployed to only that site. Similarly, the Site2 template contains only the object relevant to site2 and is deployed to that site 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 sites.

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

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

Fabric Policy Templates

In addition to the three types of application templates, Release 4.0(1) adds 3 new templates designed for fabric-wide policies:

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

  • VLAN Pool

  • Physical Domains

  • SyncE Interface Policies

  • Interface Settings

  • Node Settings

  • Pod Settings

  • MACsec

  • NTP Policies

  • PTP Policies

  • QoS DSCP Policies

  • QoS SR-MPLS Policies

  • QoS Class Policies

  For additional information, see Creating Fabric Policies.

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

  • Physical Interfaces

  • Port Channel Interfaces

  • Virtual Port Channel Interfaces

  • Node Profiles

  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.

Template Design Best Practices

Beginning with Release 4.0(1), Nexus Dashboard Orchestrator validates and enforces a number of best practices when it comes to template design and deployment. Regardless of the type of template you are creating, keep in mind the following:

• 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 opposite 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.

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

Occasionally, you may run into a situation where the configuration actually deployed to an APIC domain is different from the configuration defined for that domain in the Nexus Dashboard Orchestrator (NDO). These configuration discrepancies are referred to as Configuration Drifts and are indicated by an Out of Sync warning next to the site name in the template view page as shown in the following figure:

Note

In certain cases, the template-level notification of a configuration drift shown above may not trigger if the configuration of properties of objects managed by NDO is modified directly in the site’s controller. Specifically, addition (and subsequent removal) of the following properties do not show drift notification on NDO: Subnets for EPGs or BDs Bridge Domain DHCL Labels Static Ports configuration for EPGs Contract Relationships between EPGs In these cases, you can still check for configuration drift by manually running drift reconciliation workflow as described in Reconciling Configuration Drifts in Application Templates. When you deploy a template from NDO, drift notification for objects in that template is disabled for 60 seconds.

Configuration Drift Causes

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 APIC—while the objects deployed from NDO are indicated by a warning icon and text in the site's APIC, an admin user can still make changes to them causing the configuration drift.

  Note

  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 site'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.

We recommend that you check for configuration drifts and, if necessary, run the "Reconcile Drift" workflow for templates, 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.