The example presented here covers the deployment of a multi-site fabric managed through NDO. The current setup, based on a legacy environment, must be migrated to a newly implemented multi-site environment. Although this is not a greenfield project, we can treat it as such since the entire configuration will be generated from scratch.

The automation project requirements are to:

• Distribute the production workload across all sites
• Ensure fast deployment
• Provide simple tools for the operations team

In the current infrastructure, most of the L3 routing is handled by firewalls. Some basic L3 routing scenarios within the fabric may be implemented in the future.

Unfortunately, there is no single “correct” approach that guarantees results. Furthermore, what works today may require changes tomorrow, as NDO, the Terraform NDO provider, and NaC are constantly evolving.

In this case, I chose to:

• Focus on the production tenant, managing fabric setup and inter-site communication manually
• Prefer tools in the order: NaC, Terraform, Python
• Store automation code and data structures in Git
• Manage configuration on NDO, configuring only unsupported features directly on APIC
• Use NaC data structures for objects that rarely require modification
• Use a simple CSV-based structure for operations requiring frequent updates (networks, L3Outs)
• Create a parser to convert CSV files into NaC and Terraform data structures

NDO

All logical configuration, i.e., related to templates, is managed by NDO, with a few exceptions described later. The physical configuration, however, is managed directly on the APIC for two reasons:

• There is currently no complete NaC or Terraform module for managing the physical layer.
• The Terraform provider for NDO has poor performance, so it’s more efficient to perform non-critical tasks directly on the APIC.

NDO therefore contains:

• The production tenant, applied across all sites

• A schema template including six tenant templates:

  • One template per site containing BDs, subnets, Applications, and EPGs (deploy order 2)
  • One shared template for all sites containing BDs, Applications, and EPGs (deploy order 2)
  • One shared template for all sites containing VRFs (deploy order 1)
  • One shared template for all sites containing Contracts (deploy order 1)
  • One shared template for all sites containing External EPGs (deploy order 3)

Continue reading the post on Patreon .