Understanding Network as Code (NaC)

Network as Code (NaC) is an architecture and methodology that applies the principles of Infrastructure as Code (IaC) to network management. It allows network engineers to define, deploy, and manage network configurations in a “software defined” manner. To assist network engineers in managing network configuration change, Network as Code leverages a standard base of tools and processes that enable automation, version control, and testing of network configurations.

One of the core benefits of Network as Code is that the engineer focuses on “describing the intent” of the network configuration and automation reads this data to apply the configuration to the network devices. Using this method, network engineers can focus on networking concepts and not on how to “create” automation. This allows:

• Network engineers to work on familiar networking concepts and terminology.
• Network engineers to focus on the intent of the network configuration rather than the implementation details.
• Network engineers to leverage existing software development practices, such as version control and testing, to manage network configurations.
• Network engineers to collaborate more effectively with software developers and operations teams, as they can use the same tools and processes to manage network configurations.

In traditional network automation, network engineers often write scripts or use configuration management tools to automate specific tasks or configurations. This is the most common approach. Using tools like Ansible and Python scripts, engineers create automation that is specific to the requested change or task. While this approach can be effective for automating individual tasks, it often leads to challenges such as:

• Complexity: As the number of scripts and configurations grow, managing them becomes increasingly complex. This can lead to difficulties in maintaining and updating configurations.
• Lack of Standardization: Different engineers may use different tools and approaches, leading to inconsistencies in configurations and processes. This hurts the ability to collaborate and share knowledge effectively.
• Limited Reusability: Scripts and configurations are often tailored to specific tasks, making it difficult to reuse them across different projects or environments.
• Difficult Collaboration: Collaboration between network engineers and software developers can be challenging, as they may use different tools and processes.
• Limited Testing and Validation: Traditional automation often lacks robust testing and validation mechanisms, leading to potential errors and downtime when changes are applied.
• Limited Visibility: It can be difficult to track changes and understand the current state of the network, leading to potential issues with compliance and auditing.

It is important to understand the differences between Network as Code and traditional automation approaches. When we look at the differences between traditional automation and Network as Code, one key aspect is how the automation requires to be integrated into the network operations. Infrastructure as Code (IaC) methodology requires a strict adherence to its practices, which can be challenging in the networking domain.

Customers are used to traditional change management, where change is implemented on network devices directly. When presented with the concept of Network as Code, they may struggle to understand how it fits into their operating model.

Network as Code (NaC) addresses these challenges by providing a structured and standardized approach to network management. Here are some key differences between Network as Code and traditional automation:

Network as Code can be broken down into several key components that work together to enable effective network management:

• Declarative Models: Network configurations are defined using declarative models that describe the desired state of the network. This allows engineers to focus on the intent of the configuration rather than the implementation details.
• Version Control: Network configurations are stored in version control systems, enabling teams to track changes, roll back to previous versions, and collaborate more effectively.
• Automation Tools: Network as Code leverages automation tools and frameworks to apply configurations to network devices. These tools read the declarative models and translate them into device-specific configurations.
• Testing and Validation: Network as Code includes robust testing and validation mechanisms to ensure that changes are safe, compliant, and do not introduce errors into the network. This can include automated tests, simulations, and validation against predefined rules.

Declarative models are a key component of Network as Code. They allow network engineers to define the desired state of the network in a high-level, human-readable format. This approach contrasts with imperative models, where engineers specify the exact steps to achieve a configuration.

Declarative models focus on the “what” rather than the “how”. This means that engineers describe what they want the network to look like, and the automation tools handle the details of how to achieve that state. This abstraction allows for greater flexibility and easier management of complex network configurations.

Declarative models can be represented in various formats, such as YAML, JSON, or XML. For Network as Code we utilize YAML as the primary format for defining network configurations. YAML is a human-readable data serialization format that is easy to understand and write, making it suitable for defining network configurations.

For each technology, we have built a model that is unique to the technology. For Unified Brancha as code, foundational data model is based on Meraki. This model defines the desired state of organizations, networks, and configurations within Meraki. Automation tools then use this model to apply configurations to the Meraki environment, enabling seamless management of devices and network settings.

The model for Meraki is available in full detail on this site Data Model Section and includes the following top level elements:

• organization: Defines the top-level Meraki organization settings, including general information and administrators.
• network: Encompasses various network-level configurations, such as product types (appliance, switch, wireless), time zones, notes, tags, and specific settings for different network types.
• device: Represents individual Meraki devices and their specific configuration settings, often managed as part of an inventory.
• inventory: Manages the assignment of devices to sites and handles device discovery.
• network settings: Covers configurations such as AAA servers, device credentials, IP pools, and telemetry settings for networks.
• network profiles: Includes configurations for both switching and wireless network profiles.
• templates: Allows for the definition and management of projects, tags, and templates to standardize configurations.
• wireless: Specifically addresses wireless network configurations like RF profiles and SSIDs.
• switch: Manages configurations related to Meraki switches, as indicated by specific YAML files.
• appliance: Handles configurations for Meraki security appliances, including features like content filtering.

The model is designed to be easy to consume for humans.

Example of simple configuration model:

---
organization:
  name: meraki-org
  global_settings:
    country: "US"
    timezone: "America/Los_Angeles"
  network:
    name: office-network
    type: "wireless"
    settings:
      ssid: "Office WiFi"
      vlan: 10
      ip_range: "192.168.10.0/24"
      security: "WPA2"

This top level structure also allows for the data to be split across files. For example, you can have a file that contains the global organization configuration, another file that contains the branch networks, and another file that contains the firewall rules. This allows for better organization of the configuration and makes it easier to manage.

A key component of the BaC Toolkit is the integration of CVD-aligned templates. These templates are built in accordance with Unified Branch Cisco Validated Design (CVD) , ensuring that the configurations are optimized for performance, scalability, and security.

The CVD-aligned templates serve as pre-engineered, validated configurations that cover a wide array of network services as described in the above CVD Document. These templates are delivered in form of YAML files and available from nac-branch central repository.

Each template is crafted to encompass optimal settings for core network services, including robust routing configurations, stringent security policies, high-performance wireless and Ethernet switching parameters.

Benefits of Using CVD-Aligned Templates

• Speed and Consistency: The validated YAML templates allow network engineers to quickly and reliably deploy complex branch networks without the risk of manual configuration errors.
• Reduced Manual Effort: By automating the deployment process, the need for manual intervention is minimized, freeing up valuable time for more strategic tasks.
• Best Practice Alignment: All templates are aligned with Cisco’s CVDs, ensuring that the network is built using the latest, proven best practices. This reduces the risk of misconfiguration and optimizes the deployment for performance and security.
• Scalability: The templates are designed to scale easily, whether deploying a single site or managing multiple branches across a large enterprise network.

These templates are then applied by providing environment-specific variables, such as serial numbers, IP addressing, passwords, and other configurations, to match network environment.

As you can see, the data model is represented in YAML which is a human-readable data serialization format (data structure). While this is a human-readable format, it can grow complex and difficult to manage as the network grows. To address this, we utilize a pre-change validation process that ensures the data model is valid before it is applied to the network controller and devices.

To make it possible for a computer to understand the different parameters and attributes of the data model we utilize a pre-defined schema that defines the structure of the data model. Think of the schema as a blueprint for the data model. It defines the expected structure, data types, and constraints for each element in the data model. In Network as Code parlance, imagine a user has the option to enter an IP address as value to a specific parameter. With this method, we can validate that the only option for that parameter is a string that matches the IP address format. If the user enters a value that does not match the expected format, the validation will fail and the user will be notified of the error. You can repeat the same process for other parameters, including specific values that are defined based on the only options that can be entered.

The schema method that is used is called Yamale. Yamale is a Python library that allows you to define a schema for your YAML data and validate it against that schema. Each of the architectures for Network as Code contains a specific schema to that data model.

After the changes have been applied to the network controller and devices, it is important to validate that the changes were successful and that the network is configured and operating as expected. This is done through a post-change validation process that checks the state of the network devices and ensures that they are in the desired state.

The post-change validation process includes the following steps:

1. Collecting Data: Gather data from the network devices to understand their current state. This can include configuration data, operational data, and telemetry data. This data is collected by using the Nexus Dashboard’s APIs or device specific APIs (NXAPI) for some specific operational expected state validation.

2. Validating State: Compare the collected data against the desired state defined in the data model. This includes checking that all configurations have been applied correctly and that the network is functioning as intended.

3. Reporting Results: Generate a report that summarizes the results of the post-change validation process. This report should highlight any discrepancies between the actual state and the desired state, as well as any issues that were encountered during the validation process.

By following this post-change validation process, we can ensure that the network changes have been applied successfully and that the network is operating as expected.

To accomplish the pre- and post-change validation, we utilize two tools that are part of the Network as Code (NaC) framework. These tools are:

• nac-validate: This tool is used to validate the data model before it is applied to the network devices. It checks the data model against the predefined schema and ensures that it is valid.
• nac-test: This tool is used to validate the state of the network devices after the changes have been applied. It checks the state of the network devices against the desired state defined in the data model. If the state of the network devices does not match the desired state, it will provide feedback on what needs to be corrected.