Using DevOps for networking involves taking the functions the IT team uses for testing, deploying and managing...
servers and applications, and applying those principles to networking. The DevOps processes result in smaller changes applied more frequently to IT systems, which leads to nearly continuous improvement. Some organizations deploy new code or perform system changes many times a day. That's probably more than what networking needs at this time, but it is an indication of where the concept can go.
In the networking world, we need to make the cultural transition to spending time developing test systems that can validate our configurations pre-deployment, as well as post-deployment. Building these test systems takes time and a different approach to network configuration.
To get a better idea of the current state of DevOps for networking, I signed up for a six-week course on network automation by Ivan Pepelnjak at ipSpace. It was an excellent course, with webinars by various people who are using network automation on a regular basis. I found there are many more people starting to use network automation than I thought, and they are doing some pretty remarkable things.
The course focused on using software support tools and automation software, like GitHub, Jinja2 and Ansible, to build some simple automations. The webinars focused on what could be done with the automation tools we learned.
What tools are needed?
The first tool isn't really a tool; it is a mind that is open to change. Networking teams need to begin learning the new tools and determining how to apply them to their networks. This is a cultural change, and one that can take years to accomplish. Processes need to change, and the staff has to become accustomed to the new processes.
Executive staff has to accept that changes will be occurring to support the networking team during the transition. Some new tools will be needed, and it's quite possible organizations will have to hire some software developers to work as part of their networking teams to build the necessary systems.
As for specific tools for DevOps for networking, Python seems to be the language of choice for network automation. For example, Ansible is written in Python, and Jinja2 is a templating system for Python. GitHub is a good system to use as a code repository -- both for tools that you build and for configuration revisions.
DevOps teams use server virtualization to build test versions of applications and to run simulated loads on those applications. The developers can validate application software changes before running them in production. A similar approach to building a virtual network is needed in using DevOps for networking. A number of networking vendors -- such as Juniper Networks, Cumulus and Cisco -- now offer virtual instances of their OSes. Some of them require a license and are restricted in the number of instances that can be run concurrently.
Practically speaking, you'll want to limit the number of devices in your network simulation. Cisco's Virtual Internet Routing Lab has a limit of 10, 15, 50 or 100 devices, depending on which license you purchase. That's enough to construct a simulation of key network parts, provided your server is beefy enough to run it.
Initially, you may load the necessary configurations manually, but you'll eventually want to automate that process. Add tags to the Simple Network Management Protocol location string to identify the function of network building blocks -- data center block, demilitarized zone block, WAN block, remote site block and so on. Then, build some automation scripts to create the topology and load the configurations that correspond to the blocks you need for a given test.
The result is what the DevOps people call infrastructure as code. In other words, you can replicate your network infrastructure in a test environment by running a few scripts, paving your way to DevOps for networking.
Testing automation for DevOps for networking
Then, you can test the automation that is supposed to make changes to the network configurations. You can also test topology changes that, in the real world, require hardware. When verifying the changes, don't just check that the configuration commands made it into the configurations -- i.e., by examining the output of show running-configuration.
The automated checks should be using other show commands that verify the proper functioning of the proposed change. For example, if you were adding a new internet service provider as an alternate Border Gateway Protocol neighbor, use commands to verify that the proper BGP routes and neighbor relationships exist. Write some test scripts to take down one BGP neighbor and validate that the proper failover functionality works as you intended. The testing process provides a level of confidence in the proposed change that examining configurations does not.
Finally, the ideal solution would include the ability to generate simulated network traffic that emulates real application flows. Many of the simulation environments will allow external connectivity, so you could potentially connect your network to a set of virtualized servers and run real application traffic over it.
It can take a lot of work to build a DevOps environment for network testing. Don't be deterred. Designing and building networks is also a big job, and we've been doing that for years. It's time for us to build DevOps for networking tools that allow us to verify network changes before applying them to a real network. Start with small steps and go from there. A lot of basic tests can be built by using show commands and parsing the output.
DevOps and automation in SD networks
Prepping network teams for DevOps
Priming network engineers for DevOps