Automating ACI using Cisco Nexus as Code

Cisco released a nice toolset based on Terraform to help us automate our fabrics. The mayor benefit of this toolset is that no programming knowledge is required. You don’t even need any Terraform knowledge to get started. It is awesome. I was honored to be able to talk about this solution with Cisco in the Cisco Champion Radio episode about this. That episode can be listened to here:

CCR Automate ACI Deployments with Terraform

This post will go into the getting started with this solution. I’ll check whether I can do another post using this to implement a complete CI/CD pipeline, but there are many blogposts available about creating such a pipeline. For now I wanted to focus on the Cisco ACI specific part.

What is Nexus as Code?

Nexus as code is just a set of tools made available by Cisco to help you automate your network. As the name implies, it’s not limited to ACI deployments. However, to be fair, most of it is currently focussed on the ACI deployments. Cisco Nexus as Code is actually a wrapper around Terraform. The wrapper makes it easier to write Terraform playbooks (or whatever they are called). Because of this you only need to know about the ACI constructs. You don’t have to know how to write Terraform scripts.

Ok, nice. I don’t need to know about Terraform, but what do I need to know?

Actually, you only need to know the policy model of ACI. That means that if you have some experience managing ACI you’re already likely to have sufficient knowledge to manage ACI through Nexus as Code. If you have no experience with either ACI or Terraform you only need to learn ACI. Let’s look at an example, the difference between creating a Tenant, Application Profile, VRF, Bridge Domain and EPG using Terraform versus using Nexus as Code.

The code below is the Terraform code (HCL):

terraform {
  required_providers {
    aci = {
      source = "ciscodevnet/aci"

#configure provider with your cisco aci credentials.
provider "aci" {
  # cisco-aci user name
  username = "admin"
  # cisco-aci password
  password = "password"
  # cisco-aci url
  url      = ""
  insecure = true

resource "aci_tenant" "Tenant_Terraform_Demo" {
  name        = "Michael_Tenant"

resource "aci_vrf" "VRF_Terraform_Demo" {
  tenant_dn =
  name      = "demo_vrf"

resource "aci_bridge_domain" "BD_Terraform_Demo" {
  tenant_dn          =
  name               = "demo_bd"
  relation_fv_rs_ctx =

resource "aci_application_profile" "APP_Terraform_Demo" {
  tenant_dn   =
  name        = "demo_app"

resource "aci_application_epg" "EPG_Terraform_Demo" {
    application_profile_dn  =
    name                    = "demo_epg"
    relation_fv_rs_bd       =

Now compare this to the following code:

    - name: Michael_Tenant
        - name: demo_vrf
        - name: demo_bd
          vrf: demo_vrf
        - name: demo_app
            - name: demo_epg
              bridge_domain: demo_bd

Isn’t that a lot simpler? It really looks like what you would do within the GUI. Because it’s nested you don’t have to create references between resources as you would need to do in Terraform.

But wait a minute. In the first paragraph I described it was based on Terraform. Why doesn’t it look like HCL? That’s because the Nexus as Code actually is a wrapper. It creates the corresponding HCL code for you when you execute it.

What can I do with it?

As far as I’ve been able to discover the tool is pretty feature complete. It is possible to stage a complete fabric from scratch. The only thing you need to do first is ensure the APICs go through their initial setup wizard. Afterwards you can add switches, policies, tenents and whatever you can imagine to your fabric using Nexus as code.

Let’s give some examples:

Adding a switch to the fabric:

      - id: 1101
        pod: 1
        role: spine
        serial_number: FDO2XXXXXX
        name: ACILAB-SP1101
      - id: 1201
        pod: 1
        role: leaf
        serial_number: FDO2XXXXXX
        name: ACILAB-LF1201

Configuring NTP:

        - name:
            - hostname_ip:
              Preferred: true
              Mgmt_epg: oob

Configuring vlan pools:

      - name: vlanp_mdc
        description: "Multi-Pod vlan pool"
        allocation: static
          - from: 4
            to: 4
            role: external
      - name: vlanp_physical
        description: "On the wire physical vlans"
        allocation: static
          - from: 100
            to: 1999
            role: external
      - name: vlanp_l3out
        description: "L3out vlan pool"
        allocation: static
          - from: 3600
            to: 3699
            role: external
      - name: vlanp_vmware
        description: "VMware vlan pool"
        allocation: dynamic
          - from: 2000
            to: 2999
            role: external

And like you saw earlier you can configure tenants, vrfs, bridge domains and more using Nexus as Code.

Are there any downsides?

There are always downsides to any technology. The biggest one to using Nexus as Code is that, because it uses Terraform, it’s a declarative way of working. What does this mean? That means that Terraform keeps state for your environment. Every time you perform a change it will check the state to see whether the environment is still in it’s intended state before applying the change.

Let’s use an example to clarify that somewhat. Say for example I define an EPG using Nexus as code like this:

    - name: Michael_Tenant

        - name: demo_app
            - name: EPG1
              bridge_domain: BD1
            - name: EPG2
              bridge_domain: BD1

As you can see I made the mistake of configuring BD1 under EPG2, instead of configuring BD2. Say I notice that error while in the GUI. It’s an easy change to modify the BD in the GUI. Let’s say I do that. Next time I run the Nexus as Code it will however overwrite my manually changed configuration. So BD1 will again be configured under EPG2.

That means that these kinds of changes must be done in the configuration files of Nexus as Code. When you configure something with Nexus as Code you either keep using Nexus as Code for that configuration, or you stop using Nexus as Code at all.

For lab environments this behaviour might actually be something you really want. As it’s easy to revert to a known configuration. For production environments it’s a good idea to consider this behaviour.

Another possible downside is the state file. Since there might be a lot of configuration options in your fabric, your state file might be very big. A big state file slows down the operation of Terraform quite a bit. That means that you have to handle your state files with care. It might be smart to create multiple different statefiles. Maybe one for each tenant, or even one for each VRF in a tenant.

Where to learn more?

Cisco created a very good website to help you get started with Nexus as Code. You can find it here: