ACI NDO Nexus Dashboard Orchestrator 4.x Design Best Practice

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:

Deployment and Un-deployment Order

Deployment Order:

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.

Un-deployment Order:

• All policy objects must be undeployed in order according to their dependencies, or in the opposite order in which they were deployed.
• 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.

Circular Dependency

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 (NDO 4.x) will not allow you to save template1 addition of the EPG (epg-1 associated to bd-1).

How this Example of Circular dependency can be fixed:

Another Example for L3OUTs use case:

Which can be fixed in a similar way:

Implicit Template Stretching

starting 4.x, you cannot perform implicit object stretching, for example if you have contract in Template-1 (mapped to site-1) and referencing to the contract in Template-2 (mapped to site-2), that will create an implicit object stretching.

This is no allowed in NDO 4.x and later releases:

In case of Upgrade from NDO/MSO pre 4.x to 4.x:

• Implicit template stretching: if one or more objects are implicitly stretched, the upgrade process will create new explicitly-stretched templates and move the objects into those templates.
  
  For example, if you have a template (t1) that contains vrf1 and is associated to site1 and another template (t2) that contains a BD that references vrf1 but is associated to two sites (site1 and site2), then vrf1 will be implicitly stretched between the two sites.
  
  This is no longer allowed starting with release 4.0(1) and the VRF must be explicitly stretched to both sites. In such cases during the upgrade, the VRF will be either moved to a different template which will be explicitly stretched between both sites or the original template will be associated with both sites, depending on whether the other policies in that template require stretching as well.
  
  Any templates that are created in this case will be named UpgradeTemplate%d, where %d is an incrementing number starting with 1 to ensure that all newly added templates are unique.

How it should be explicitly defined (otherwise, NDO upgrade will atomically create the explicit stretch template:

• Global policy migration: all global tenant policies (such as DHCP relay or route maps) and fabric policies (such as QoS) will be moved into the new tenant and fabric policy templates that have been added in release 4.0(1).

So what is the Best Practice design for ACI Template on NDO?

According to white paper, for greenfield configurations created directly on NDO 4.0(1), the best-practice recommendation previously shown in the following figure:

Reference: White paper