Nexus-as-Code introduction

Cisco Nexus-as-Code

Welcome to the Nexus-as-Code (NAC) project page. Our modern cloud networking products and controllers have been designed with automation being top of mind. Extensive documentation and a plethory of detailed examples can be found everywhere. The goal of this project is to have existing code meet with best-practices, expressed through an easy to use, opinionated data model. Nexus-as-Code is aimed at users with limited experience with Ansible and or Terraform, or those that prefer automating through an inventory driven approach.

The majority of this project is aimed at leveraging this data model driven approach through Hashicorp Terraform. Terraform is commonly used to define cloud and on-prem resources in human-readable configuration, that you can version, reuse and share. This page also includes a few additional examples in the NDFC-NXOS and Other Examples section, using Ansible and Terraform to automate Application Centric Infrastructure (ACI), Nexus Dashboard Fabric Controller (NDFC) and NX-OS standalone based networks. These examples do not adhere to the same data model driven approach, but offer valuable resources for more experienced users.

Nexus-as-Code allows for complete separation of data (defining variables) from logic (infrastructure declaration). With little to no experience with automation, users can instantiate network fabrics in minutes. The model is structured in such a way that it logically represents the GUI. It also takes away the complexity of having to deal with references, dependencies or loops. To understand this better, consider the following main.tf Terraform plan to create a Tenant and a VRF in an Application Centric Infrastructure (ACI) network fabric:

resource "aci_tenant" "example" {
  name        = "nexus-as-code"
  description = "from terraform"
}

resource "aci_vrf" "example-vrf" {
  tenant_dn              = aci_tenant.example.id
  name                   = "nac-vrf"
  description            = "from terraform"
  name_alias             = "alias_vrf"
}

The same can be achieved through leveraging the data model for ACI, following a clean, simple to understand structure:

apic:
  tenants:
    - name: nexus-as-code
      vrfs:
        - name: nac-vrf

The data model presents what a user may expect when interacting with the Graphical User Interface (GUI), as it follows the same structure. Another Virtual Routing and Forwarding (VRF) could simply be added by adding -name: nac-vrf-2 to the vrfs: section. Using native resources, one would have to create two separate aci_vrf resources, one for each VRF or come up with a loop using the for_each attribute. That logic is not required when using the data model. One can simply add the resources in a nested format.

apic:
  tenants:
    - name: nexus-as-code
      vrfs:
        - name: nac-vrf
        - name: nac-vrf-2
</snip>

Note that many of the recommended values for knobs are part of the Nexus-as-Code module. There is no need to specify them for each resource. Users may alter the values in a defaults.yaml to change the settings to match their requirements for all resources, or choose to do this individually per resource.

A more detailed description of how the data model interacts with modules and resources can be found in the introduction section of each solution.

The data model and modules used in Nexus-as-Code, and the example code repositories are open-source and available as-is. For support and or customization it is required to engage with Cisco Professional Services (CX). The native resources in the Terraform Provider and Ansible Collections are fully supported by Cisco Technical Assistance Center (TAC).

Additional references:

• Cisco Application Centric Infrastructure
• Cisco Nexus Dashboard Fabric Controller
• Cisco Nexus Dashboard Orchestrator