Powering the new NetOps era with Containerlab, Nokia

Nokia’s product line manager Roman Dodin dives into how Nokia’s Containerlab is going to power the new NetOps era:

The success and growth of the cloud is changing the role and operation of the network. Not only are we adopting virtualization and cloud-native approaches in our network architectures, but we are also re-engineering the network so that it is consumable by cloud applications. Operationally, this means integrating NetOps into the continuous integration and deployment pipeline, which calls for more powerful tools for developing and testing network topologies to ensure they will support cloud applications.

There are many tools available for creating and testing network topologies on your server today, but they’re oriented to VMs, not containers. When we launched our SR Linux network operating system (NOS), we needed to find a tool that would allow us to work with containers, since this is the packaging format of our NOS and most future NOS’s. As they say, necessity is the mother of invention. Unable to find a tool that worked for our purposes, we decided to build our own.

We originally developed Containerlab as an emulation tool to create and test network topologies for our own use, but as it matured, we realized that it was something needed by the broader industry. We also recognized that the lab tool could become even more powerful if others joined in to help with development. This thinking led us to opensource the tool, and we subsequently released Containerlab as an opensource project for working with any NOS that uses containers. Since its introduction, we’ve been pleased to see an enthusiastic response, with developers pitching in to improve aspects of the tool. It can now be used with any container-based NOS, and can accommodate VMs, for NOSs that haven’t yet been re-written to support a container-based packaging format.

Containerlab is a CLI tool designed to deploy networking lab topologies using a declarative approach. Network engineers can simply declare how many nodes and links they want in their topology, and the tool will create and deploy them. Engineers can then configure the lab with the protocols and services they wish and test the control and data plane functions.

All that is required to use Containerlab is the Linux command line utility to download files and Docker. It can be done on a Linux instance, in Windows or on a Mac. A topology is a single YAML text file that can be checked into a Git repository. All of these are open-sourced tools that are readily available. The average network engineer can download Containerlab and be up in running in a matter of minutes.

Working with Git also helps fit Containerlab into a CI/CD pipeline, even very complex ones. A NetOps team can use Containerlab to create topologies and store them in a code repository (such as GitHub) as a catalog of templates that can be called upon depending on the application being readied for release. These network abstractions can later be pulled out of the code repository as needed and tested alongside the application in development to ensure that the network has been optimized for the application. Containerlab-based lab topologies can be built for network automation try-outs, data center fabrics or even ISP backbones.

EVPN is a key capability supported by the SR Linux NOS, which means that testing multihoming was a key requirement. That made it important that we overcome some traditional issues with classic Linux bridges, which can have trouble with data protocols like LACP on standard bridge-based links. We overcame this issue in Containerlab using virtual Ethernet pairs for a very clean data path channel. The great advantage of making Containerlab open source is that these kinds of problems can profit from a strong community of network engineers and developers who will only extend the strength of the tool over time.

Whether used for training, by single network engineers or integrated into complex development pipelines, we believe Containerlab is the tool the industry needs as we embrace the use of containers and integrate network operations into the larger DevOps environment.”

CT Bureau