How to configure networks using CI/CD pipelines

The current workflow

Imagine a simple campus network with a few access switches and a distribution switch. Someone issues a ticket to create a new virtual LAN (VLAN). Engineers who make these changes manually likely prepare the configurations, create new VLANs, add them to the trunk ports, create switch virtual interfaces (SVIs) on the core switch and configure any Hot Standby Router Protocol/Virtual Router Redundancy Protocol configurations.

Someone usually then reviews and approves the changes. Finally, an engineer applies the configurations to the devices, performs some post-checks to ensure the changes didn't break anything else and documents these checks in the ticket as evidence.

This manual process works, but some of the following challenges emerge:

1. Engineers need to define the process.
2. Someone might miss a device when adding the VLANs.
3. Post-checks are all manual.
4. Engineers need to budget time to perform tasks and check that all uplinks are active.

Many engineers can relate to what happens if they forget to include the add command when adding a new VLAN to the trunk interface.

A quick look at CI/CD pipelines

CI/CD is a software development process that automatically builds, tests and deploys changes to a codebase. CI enables enterprises to use a shared repository to track how code is built and tested. It keeps codebases current and quickly identifies and corrects any errors that occur. CD then automatically deploys validated changes to network devices. This enables new configurations and updates to be implemented quickly and reliably.

This approach can also apply to network infrastructure. By using CI/CD principles, network engineers can automate many of the manual tasks involved in managing network configurations, which reduces the risk of human error and speeds up network changes.

Let's see how CI/CD works in a networking context and discuss some of the benefits it can provide.

CI/CD workflow in networking

CI/CD lets engineers abstract most configurations using different methods. One of the simplest ways to do this is to use Ansible and Jinja2. Here are some possible steps:

1. Define the configuration parameters in a simple YAML file.
2. Create a configuration template using Jinja2.
3. Use Ansible to generate the config and push it to the devices.

Ansible also comes with built-in modules that eliminate the need to manage custom-built templates. Network engineers can also opt to use Python, which offers more flexibility in the long run. Plenty of Python libraries are available for working with network devices, such as Nornir, Napalm and Netmiko.

Most vendors also provide their testing options. Remember all the manual tests network engineers used to do? They can now use specific Python libraries to automate these tests. For example, Cisco offers PyATS, a testing framework that helps oversee pre-checks and post-checks. PyATS can take a snapshot before a change, take another after the change and show the differences. Arista also provides a testing framework -- Arista Network Test Automation -- where engineers can define tests, such as checking if all uplinks or SVIs are up or ensuring a specific route is in the routing table.

Network CI/CD pipelines let engineers stitch everything together into a sequence of automated steps.

Finally, network engineers need a tool to handle the CI/CD part of the equation. Many options exist, among them Jenkins, GitHub Actions and GitLab. Each has its benefits, but the example below focuses on GitLab.

Network CI/CD pipelines let engineers stitch everything together into a sequence of automated steps. Instead of manually running pre-tests, applying configurations and then rerunning post-checks, engineers define each step in an automated way within the pipeline configuration.

In a CI/CD pipeline, engineers create stages and jobs. Each stage can have one or more jobs. For example, it's possible to create a stage for pre-tests, another for configuration changes and a final one for post-checks. Each job runs in sequence -- first the pre-tests, then the configuration and finally the post-checks -- ensuring everything happens in the right order without manual intervention.

Engineers can even take it a step further by automating the change management process. Based on the pipeline's outcome, they can automatically update tickets or documentation, making the entire workflow smoother and more efficient.

Using GitLab to create a VLAN

Let's look at a quick example of how to manage VLANs on network devices using Ansible and a CI/CD pipeline. If you're looking for a deeper explanation of how this works, check out my blog post series on network CI/CD.

Here, I keep things simple with a basic CI/CD pipeline that automates the creation of a VLAN. Instead of manually logging in to the switch to create VLANs, I use Ansible. Ansible stores the list of VLANs in a YAML file and has a simple playbook that creates them. I use GitLab as the CI/CD platform. The workflow is as follows:

1. Receive a request to create a new VLAN.
2. Pull the latest Git repository, and create a new branch.
3. Update the YAML file by adding the new VLAN, and then commit to pushing the branch back to GitLab.
4. Define a test that checks whether the VLAN ID is within the allocated range.
5. Have the reviewer examine the change and approve the merge request.
6. Run the playbook, and create the VLAN.

Here is the example YAML file that contains all the VLANs.

vlans:
  - vlan_id: 10
    name: cctv
  - vlan_id: 11
    name: voip

Here is the playbook to create the VLANs.

---
- name: "VLAN Playbook"
  hosts: switches
  gather_facts: no

  vars_files:
    - vlans.yml

  tasks:
    - name: Create VLANs
      arista.eos.eos_vlans:
        config: "{{ vlans }}"

Here is the validation playbook to ensure the VLAN IDs are in the correct range.

---
- name: "VLAN Validation Playbook"
  hosts: localhost
  gather_facts: no

  vars_files:
    - vlans.yml

  tasks:
    - name: Validate VLAN IDs are between 1 and 100
      assert:
        that:
          - vlan.vlan_id >= 10
          - vlan.vlan_id <= 100
      loop: "{{ vlans }}"
      loop_control:
        loop_var: vlan

Here is the GitLab CI/CD pipeline configuration.

default:
  image: python:3.10

stages:
  - test
  - deploy

test:
  stage: test
  before_script:
    - pip install ansible paramiko
  script:
    - ansible-playbook pre_test.yml

deploy:
  stage: deploy
  before_script:
    - pip install ansible paramiko
  script:
    - ansible-playbook create_vlan.yml
  only:
    - main

In this pipeline configuration, I use a default Python 3.10 image to run the jobs. The pipeline consists of two stages: test and deploy. In the test stage, the pipeline installs the necessary Ansible and Paramiko libraries before running a playbook -- pre_test.yml -- to validate the configurations.

Once the tests pass, the deploy stage executes. Here, the same libraries are installed, and another playbook -- create_vlan.yml -- runs to create the VLANs on the devices. The deploy stage is configured to run only when changes are merged into the main branch. This ensures that deployments happen only after the changes are approved.

Remember to start small and build on your development. It's almost impossible to have a fully working network CI/CD pipeline ready to deploy right away.

Suresh Vina is a network engineer who has worked in the networking field for the past eight years. He has hands-on experience with technologies from Cisco, Juniper, Palo Alto Networks, Fortinet and more.