No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Network Configuration: Using CI/CD Methodology

metamorworks__sentation1.jpg

Image: metamorworks - stock.adobe.com
The process of making and integrating minor changes to software projects is known as continuous integration. Smaller changes have a lower impact and are easier to test than larger changes. Continuous deployment/delivery pushes those changes to the production environment in a controlled manner, helping avoid human error due to manual processes. The combination is called DevOps, shorthand for software development operations.
 
The software development world has employed DevOps methodology for years, but few organizations use it for their networks. The problem is that networks and their configurations are fundamentally different than that of business software. With business software, it’s relatively easy to create software-only test environments and employ various tools to run automated tests to verify the operational correctness of changes. Similar tools for networking are in their infancy. As a result, most organizations are not yet applying CI/CD techniques to network configurations—something that must change.
 
Requirements for Change
To apply CI/CD to networking, our network change process must model the hardware and software of the existing network infrastructure. We can then create tests to validate network configuration changes before deploying them to the production network.
 
To build the model, we need discovery systems that identify the network infrastructure components, interconnections, and configurations. The use of network virtualization techniques like virtual routing and forwarding (VRF) instances and Ethernet VPN (EVPN) complicate the task by layering virtual networks on top of the physical infrastructure.
 
Ideally, the discovery system would also determine the network flows requiring support, potentially identifying each application and its interconnection requirements. This task is problematic in large networks that support hundreds of applications. It would be inappropriate to model and replicate the connectivity used by an unknown malware package in a network model.
 
We also need tools that use the discovered topology and configuration to create a “network digital twin” and use it for pre-deployment testing. This digital twin must be an “act-alike” twin that can accurately model configuration and topology changes. To verify the operation, it will need to replicate enough of the traffic flows to validate whether the desired connectivity exists (or doesn’t exist) after a proposed change.
 
Lastly, we need methods for evaluating the correctness of network operation—in both the test network and eventually in the operational network. The simple checks would verify neighboring network device reachability or routing table entries. This area is where the networking industry’s capabilities are today. In the future, I expect to see greater fidelity regarding network digital twins where synthetic network traffic can potentially allow verification of security and quality of service (QoS) functionality.
 
Development, Continuous Integration, and Continuous Delivery
The network design and development process must be the same as we are using for software development. That is, develop and test the change in a development environment that mirrors the real environment. When it passes all tests, the change gets submitted to the CI/CD process.
 
The CI phase builds the virtual test network, applies the proposed network change, and evaluates the results. Did the change achieve the desired result? Test failures could be because the change was incorrect, incomplete, or that the tests were insufficient. A test failure could also be due to a conflict between two changes. Regardless, the network engineer receives the test results for evaluation and correction.
 
However, if the CI process indicates a successful change, the CD process can apply this change to the production network. Undoubtedly, many organizations will want to verify the results of successful tests before applying them to the production network as part of their normal change control process.
 
The goal of the CI/CD process is to avoid the human errors that are prevalent in today’s network operational processes.
 
Adopting CI/CD Processes
Adopting networking change CI/CD processes is a major operational shift and is best done with a slow and easy approach. Begin with simple automation tasks that have little impact on network operations when you make a mistake. Yes, you will make mistakes, so strive to make them small and low impact.
 
Keep your changes small by breaking larger changes into small, independent pieces. For example, a QoS implementation might start with classification and marking, while the next step would implement queueing and forwarding logic.
 
You should adopt a CI/CD process for sub-sets of the overall network configuration. For example, start with managing the configuration of all the global static configuration items like network time protocol (NTP), simple network management protocol (SNMP), system logging protocol (Syslog) , dynamic host configuration protocol (DHCP), and login authentication. Then apply what you learn to more advanced parts of the configuration like interfaces and routing protocols. As you get started, make the network’s design and configuration consistent across similar constructs. Branch sites of the same general size should use one design and a configuration that differs only in things like IP addresses. This consistency greatly simplifies the creation of test environments and makes it easier to automate configuration changes.
 
Your CI/CD process should become the only way to deploy new changes to the covered parts of the configuration. Otherwise, you create inconsistencies across the network that adds unnecessary complexity to your CI/CD automation process.
 
Next Steps
If you’re beginning to embark on the networking CI/CD journey, the next step is reading and research. I recommend How Do You Set Up a Network CICD Pipeline?, an article by Brunner Toywa, a telecommunications engineer. In addition, generic articles on CI/CD, abound, such as An Introduction to CI/CD Best Practices. Then work on setting up a development and test environment for change development and the CI part of the process. You’ll also need to learn about code repositories and how to automate your build cycle using tools like Jenkins or Drone.
 
The whole process may seem like a lot of work, but its objective is to reduce network outages by adopting best practices from the software development industry.