Working with NaC Data Model

In this section, we will explore building an example data model using Network as Code (NaC). The data model will be structured to represent the configuration of a VXLAN/EVPN fabric using Nexus Dashboard. This example will help you understand how to define and organize the data needed.

Understanding the Data Model

The data model in Network as Code is the structured data (in YAML) that is read by the automation engine. Inside the automation engine ( Terraform or Ansible ), the data model is read and the parameters are passed into the specific modules and resources. The following examples shows how a terraform resource that reads the value from the data model. One of the reasons that we perform validation against the data model is to ensure that when automation execution runs, the data that the automation engine is going to read is correct. For Ansible, the process is similar but more difficult to visualize in a single image as more steps are involved.

When we talk about infrastructure as code, the data model represents the declaration that the network operator wants to achieve. You declare the intent of the configuration of the network and it is the job of the underlying automation engine to translate the data model information into the actual configuration that is pushed to the network devices. This has the benefit of allowing the network operator to simply declare how the network should be configured instead of having to also write the code to perform the action. In Infrastructure as Code circles, the data model is known as the source of truth.

---
vxlan:
  topology:
    switches:
      - name: spine1
        serial_number: 9myuniqueserialnumber
      - name: spine2
        serial_number: 9myuniqueserialnumber
      - name: leaf1
        serial_number: 9myuniqueserialnumber

The data model is constrained by the schema definition. Each parameter in the data model is expected to follow a specific type, specific defined values, and whether it is mandatory or not. For Nexus Dashboard, the serial numbers of the switches are a required field. And the requirements for the data model are available for viewing in the Network as Code Documentation. The documentation is built from the schema of the data model automatically and enhanced by engineers working on the technology. This represents the source of truth for the data model.

From the example above you will see that we left out some important information for Nexus Dashboard. The role and management are not defined and need to be added.

---
vxlan:
  topology:
    switches:
      - name: spine1
        role: spine
        serial_number: 9myuniqueserialnumber
      - name: spine2
        role: spine
        serial_number: 9myuniqueserialnumber
      - name: leaf1
        role: leaf
        serial_number: 9myuniqueserialnumber

Since the management section is another tier of the data model, it is represented in the documentation in a separate table.

Which is added to the data model as follows:

---
vxlan:
  topology:
    switches:
      - name: spine1
        role: spine
        serial_number: 9myuniqueserialnumber
        management:
          default_gateway_v4: 10.1.1.11
          management_ipv4_address: 10.1.1.1
      - name: spine2
        role: spine
        serial_number: 9myuniqueserialnumber
        management:
          default_gateway_v4: 10.1.1.12
          management_ipv4_address: 10.1.1.1
      - name: leaf1
        role: leaf
        serial_number: 9myuniqueserialnumber
        management:
          default_gateway_v4: 10.1.1.13
          management_ipv4_address: 10.1.1.1

And just like this is the rest of the data model. Each section represented in the table and examples on the site. This information is exposed internally and externally for you to use.

Nexus Dashboard Switches and POAP

Since we utilize virtual switches for this lab, we will not be using the POAP (Power On Auto Provisioning) feature of Nexus Dashboard. POAP is a feature that allows for automatic provisioning of switches when they are powered on. In a real world environment, you would use POAP to automatically provision the switches in the fabric.

Network as Code for Nexus Dashboard provides a way to define the POAP configuration in the data model. We have created a separaate document that explains how to use POAP with Network as Code for Nexus Dashboard.

Construct the Model for this Lab

Now that we have a basic understanding of the data model, we will build a data model for the lab environment that we are using. The repository that was cloned in the previous section contains a starter data model that you will use.

Serial Numbers of the Switches

Nexus Dashboard (ND) requires the serial numbers of the switches that will be managed. This is important for the automation to correctly identify and manage the devices in the fabric. The serial numbers are typically obtained from the device itself. In a real world environment, you would obtain the serial numbers from the customer or the PO/Web order itself.

This information might come in the form of a spreadsheet or a CSV file. Which you would then have to parse and extract the relevant serial numbers such that we can place them in the data model.

When working with virtual switches in the CML topology, the serial numbers change with every fresh deployment. Therefore, you will need to obtain all the serial numbers of the switches.

Step 1: Retrieve serial numbers from virtual topology

For this lab we are building the data model using the Cisco Modeling Labs (CML) topology. We have included a small script to go read all the serial numbers from the fresh topology that was built for this lab.

python ~/script/serials.py

This will output a list like the following but with the actual serial numbers of the switches in your CML topology:

Retrieving serial numbers for the switches...

198.18.133.201: Serial Number: 9myuniqueserialnumber
198.18.133.202: Serial Number: 9myuniqueserialnumber
198.18.133.203: Serial Number: 9myuniqueserialnumber
198.18.133.204: Serial Number: 9myuniqueserialnumber
198.18.133.205: Serial Number: 9myuniqueserialnumber
198.18.133.206: Serial Number: 9myuniqueserialnumber
198.18.133.207: Serial Number: 9myuniqueserialnumber
198.18.133.208: Serial Number: 9myuniqueserialnumber

Step 2: Modify topology data model

Now that we have the serial numbers, we need to modify the topology data model to include these serial numbers for each switch. This will ensure that the automation can correctly identify and manage the devices in the fabric.

code-server ~/network-as-code/nac-nd/host_vars/nac-fabric1/topology_switches.nac.yaml

With the file now open you must make the following changes.

The file is in YAML format and you will need to modify the serial numbers and management information for each switch. YAML is a human-readable data serialization format that is often used for configuration files. It is important to maintain the correct indentation and structure of the YAML file.

As an example for the first switch, you must replace the values for serial_number, management_ipv4_address, and default_gateway_v4 with the values retrieved from the script and the table above. This is your first exercise in building the data model. Remember that indentation in YAML is significant, so make sure to maintain the correct structure.

---
vxlan:
  topology:
    switches:
      - name: netascode-spine1
        serial_number: 99H2TUPCVFK
        role: spine
        management:
          default_gateway_v4: 198.18.128.1
          management_ipv4_address: 198.18.133.201
        routing_loopback_id: 0
        vtep_loopback_id: 1

You must repeat the process for each switch. Save the file after you have made the changes.

Step 3: Add border switches to the data model

There are two switches that have to be added to the example data model that are part of this topology. These are the border switches that connect the fabric to the outside world. They are typically used for routing and security purposes.

The best approach is to copy the netascode-leaf1 switch and modify it to be a border switch. This will ensure the right indentation and structure of the YAML file is maintained.

      - name: netascode-border1
        serial_number: 92EDZUF9LG6
        role: border
        management:
          default_gateway_v4: 198.18.128.1
          management_ipv4_address: 198.18.133.207
        routing_loopback_id: 0
        vtep_loopback_id: 1

Repeat the step for the second border switch, netascode-border2, with the appropriate serial number and management information.

Conclusion

With this step completed and the rest of the example data model in place, you can start the process of making Network as Code push the configuration towards Nexus Dashboard.