Skip to content

Cisco Nexus as Code Architecture

Estimated time to read: 7 minutes

  • Originally Written: November, 2022

Updated NaC Architecture

The Nexus as Code project is comprised of one root module with 10s/100s of sub-modules. Originally the sub-modules existed in their own repositories. These have now been combined into a single repository to simplify the project contribution process and to decrease the terraform init download time.

All sub-modules are now stored in the modules folder and are references in the aci_xxx.tf files. e.g. aci_tenants.tf.

One day in the future I may find some time to update the original architecture diagrams below.

While Cisco ACI offers very powerful APIs and integrations with tools such as Ansible and Terraform, not all network engineers are developers. The Nexus as Code (NaC) project makes it easy for users to gain the benefits of programmability and Infrastructure as Code with minimal effort.

https://developer.cisco.com/docs/nexus-as-code

NaC uses Terraform to translate the data model (YAML files with the ACI configurations) and implement the configuration in the ACI fabric. Sometimes errors can appear and therefore it can be helpful to understand how the NaC data model and Terraform modules work together. Understanding the architecture can also be useful if you want to contribute to the project.

The following diagram represents a high level view of the NaC structure.

Directory Structure and Files

The NaC directory structure should look similar to the following screenshot

When you run the terraform init command to initialise Terraform, the modules and providers that Cisco have built will be downloaded into the current directory. You should not need to modify these files.

The data model is provided in one or more YAML files and contains the ACI configuration as shown in this example. The YAML files can be found in the data folder. These are the files that are modified by the user to suit their environment.

The defaults directory/file contains the default ACI settings which are used to simplify the user experience. As the name suggests, if a user does not explicitly set the configuration for a resource property (e.g. VRF should be unenforced), NaC will use the value set in the defaults file if one exists. This allows a user to get up and running with NaC and ACI without having to provide a large amount of configuration. The defaults file is not mandatory but the user is free to add any default values they require into this file.

The main.tf file contains the ACI provider settings such as URL/username (although these can be set as environmental variables) and the entry point to the ACI Terraform modules. The policies to create various resources such as tenants or interface policies can be enabled or disabled.

Configuration is provided in the simple and comprehensive examples below.

https://github.com/netascode/nac-aci-simple-example

https://github.com/netascode/nac-aci-comprehensive-example

Terraform Modules

As outlined in the Terraform documentation,

Modules are containers for multiple resources that are used together. A module consists of a collection of .tf and/or .tf.json files kept together in a directory.

Modules are the main way to package and reuse resource configurations with Terraform.

The Root Module

Every Terraform configuration has at least one module, known as its root module, which consists of the resources defined in the .tf files in the main working directory.

Sub Modules

A Terraform module (usually the root module of a configuration) can call other modules to include their resources into the configuration. A module that has been called by another module is often referred to as a sub module.

Sub modules can be called multiple times within the same configuration, and multiple configurations can use the same sub module.

https://developer.hashicorp.com/terraform/language/modules

Nexus as Code Modules

Nexus as Code Architecture - Summary

Info

The following explanation includes a couple of resources (Tenant and VRF) as examples. Nexus-as-code follows the same architecture for many other ACI resources. See the data model documentation for further information.

https://developer.cisco.com/docs/nexus-as-code/#!data-model

To understand the Nexus as Code architecture have a look at the following architecture diagram.

  • nac-aci-simple-example
    • Root module containing the data YAML file(s) and the main.tf
  • nac-aci-simple-example/main.tf
    • Loads the data model into a variable, model, which is then passed to the terraform-aci-nac-tenant module
  • terraform-aci-nac-aci/aci_tenants.tf
    • The terraform-aci-nac-aci module consolidates all calls to the sub modules which implement the configuration changes. In previous versions of NaC there were multiple higher level modules (tenant, access policies etc). These have now been brought together in the terraform-aci-nac-aci module.
    • It parses the model variable received from the simple example into individual variables (e.g. name, description). These are then passed to the relevant sub modules e.g. terraform-aci-tenant
  • terraform-aci-tenant/main.tf
    • This is the module containing the aci_rest_managed resource used to create the tenant
  • terraform-aci-vrf/main.tf
    • This is the module containing the aci_rest_managed resource used to create the VRF

Nexus as Code Architecture - Detailed

Helpful Tools

Although NaC greatly simplifies how you work with ACI programmatically, you will still need to understand and write YAML files. Here are some VS Code extensions which make it easy to identify any errors that may exist.

Pre-commit Hooks

Indent Rainbow

https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow

YAML Linter

https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml

YAML :heart: JSON

https://marketplace.visualstudio.com/items?itemName=hilleer.yaml-plus-json

Comments