We already highlighted how critical the design phase is in any automation project. This is even more true when working with NDO, since a design mistake could easily compromise the entire project.

When designing templates, you must carefully plan the deployment order to ensure no circular dependencies are created. Dependency checks are performed at the template level, not at the level of the individual objects inside them. Let’s look at an example:

In this example (courtesy of Mario Rosi ), we have a single schema containing six templates. Each template includes the objects listed below:

• The first two templates are site-specific and contain objects that are meaningful only within their respective site. These objects do not need to communicate with objects in other sites.
• The third template is shared across all sites and includes objects that must communicate with those in other sites.
• The remaining templates contain reusable objects that are also shared across all sites.
• The arrows in the diagram represent dependencies: they start from the dependent object and point to the object they rely on. For example, a Bridge Domain requires a VRF to be created first.

Continue reading the post on Patreon .