Schema and Template Design Considerations
Nexus Dashboard Orchestrator provides a number of policy templates that allow you to define one or more policies together and deploy them to one or more sites at the same time. These include tenant policy templates, fabric and fabric resources policy templates, monitoring templates, and application templates. A schema is a collection of application templates, which are used for defining application policies, with each template assigned to a specific tenant. There are multiple approaches you can take when it comes to creating schema and application 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.
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 described 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 described 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, theSite2
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 aShared
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 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
orAccess SPAN
policies.For additional information, see Creating Monitoring Policies.
Template Design Best Practices
Beginning with Release 4.0(1), Nexus Dashboard Orchestrator will validate and enforce 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 createvrf1
intemplate1
and deploy that template, then createbd1
intemplate2
and deploy that template, there will be no validation errors since the objects are deployed in correct order. However, if you then attempt to createepg1
intemplate1
, it would create a circular dependency between the two template, so the Orchestrator will not allow you to savetemplate1
addition of the EPG.