Network automation options in Go with scrapligo#
Just recently the network automation folks witnessed a great library to be ported from Python to Go - scrapligo.
Been working on learning go a bit and have published scrapligo https://t.co/NDXQ6khxCr -- still a work in progress, but has been a fun learning experience! Check it out and let me know what ya think! 🤠
— Carl Montanari (@carlrmontanari) May 19, 2021
For me personally this was a pivotal point because with scrapligo the Go-minded netengs can now automate their networks with a solid and performant library.
One of the things that scrapligo packs is, of course, the ability to reliably talk to the network devices using the same command line interface as a human would normally do. That means that scrapligo would send and receive the pieces of data that an operator would send/receive if they were connected with a terminal over SSH.
Containerlab - your network-centric labs with a Docker UX#
With the growing number of containerized Network Operating Systems (NOS) grows the demand to easily run them in the user-defined, versatile lab topologies. Unfortunately, container runtimes alone and tools like docker-compose are not a particularly good fit for that purpose, as they do not allow a user to easily create p2p connections between the containers.
Containerlab provides a framework for orchestrating networking labs with containers. It starts the containers, builds a virtual wiring between them to create a topology of users choice and then manages a lab lifecycle.
Containerlab focuses on containerized Network Operating Systems such as:
- Nokia SR-Linux
- Arista cEOS
- Azure SONiC
- Juniper cRPD
- FRR
In addition to native containerized NOSes, containerlab can launch traditional virtual-machine based routers using vrnetlab integration:
- Nokia virtual SR OS (vSim/VSR)
- Juniper vMX
- Cisco IOS XRv
- Arista vEOS
And, of course, containerlab is perfectly capable of wiring up arbitrary linux containers which can host your network applications, virtual functions or simply be a test client. With all that, containerlab provides a single IaaC interface to manage labs which can span contain all the needed variants of nodes:
Building and publishing deb/rpm packages with goreleaser and gemfury#
I am a huge fan of a goreleaser tool that enables users to build Go projects and package/publish build artifacts in a fully automated and highly customizable way. We've have been using goreleaser with all our recent projects and we couldn't be any happier since then.
But once the artifacts are built and published, the next important step is to make them easily installable. Especially if you provide deb/rpm packages which are built with NFPM integration.
The "challenge" with deb/rpm packages comes to light when project owners want to add those packages to Apt/Yum repositories. Goreleaser doesn't provide any integrations with 3rd party repositories nor there are Apt/Yum repositories which are free and provide an API to upload artifacts. Or are there?
Transparently redirecting packets/frames between interfaces#
Lately I have been consumed by an idea of running container-based labs that span containerized NOSes, classical VM-based routers and regular containers with a single and uniform UX.
Luckily the foundation was already there. With plajjan/vrnetlab you get a toolchain that cleverly packages qemu-based VMs inside the container packaging, and with networkop/docker-topo you can run, deploy and wire containers in meshed topologies.
One particular thing though we needed to address, and it was the way we interconnect containers which host vrnetlab-created routers inside.
Vrnetlab uses its own "overlay datapath" to wire up containers by means of an additional "vr-xcon" container that stitches the exposed sockets. Although this approach allows to re-wire containers in different topologies after the start, this was not something that we could use if we wanted use non-vrnetlab containers in our topology. Ideally I wanted to emulate p2p links between the routers (running inside containers) by veth pairs stretched between them, pretty much like docker does when it launches containers. And that is also the way docker-topo works.
How to patch Ubuntu 20.04 Focal Fossa with UKSM?#
Running multiple VMs out of the same disk image is something we, network engineers, do quite often. A virtualized network usually consists of a few identical virtualized network elements that we interconnected with links making a topology.
In the example above we have 7 virtualized routers in total, although we used only two VM images to create this topology (virtualized Nokia router and it's Juniper vMX counterpart). Each of this VMs require some memory to run, for the simplicity, lets say each VM requires 5GB of RAM.
So roughly, the above topology will claim 30-35GB of RAM in order to operate. Enriching the topology by adding more VMs of the same type will continue to push for more memory, thus running big topologies often becomes an exercise of hunting for RAM.
Luckily, there are technologies like Kernel Same Merging (KSM) and it's enhanced version Ultra-KSM (UKSM) that are able to lift the memory requirement for use cases like above. In a nutshell, they allow to merge mem pages of the same content, effectively reusing the same memory pages between virtual machines.
Remove binaries and big files from Git repo#
You slice and dice your files in a Git repo like a pro and accidentally commit a binary file. It happened to you as well, don't pretend it didn't.
Sooner or later you recognizes this file shouldn't be there, it is clogging your Git repo for no reason. OK, you delete the file and commit. But the repo size doesn't get any smaller. Hm...
Projectdocs#
I am a firm believer that documentation is an integral part of the project. A terse, twisted, incomplete or sometimes even missing documentation penalizes your projects success. At the same time clean, concise and comprehensive documentation is not only something worth being proud of, but an opening to a users' appreciation and fame.
I am sharing the way I build, publish and host documentation sites for my projects via this live-example site - projectdocs.netdevops.me
gNMIc got better with YANG-completions#
gnmic was the first opensource project that I've been part of that got widely adopted. As the maintainers of a public project, Karim and I were wondering when would we get the first external contribution.
To our surprise, the very first external contribution laid out the foundation to one of the most exciting features of gnmic - YANG-Completions.
I thought that the best way to describe what YANG-completions is showing you a quick demo augmented with some comments. This resulted in this twitter-series:
💻Fellow Network Automation engineers,
— Roman Dodin (@ntdvps) October 21, 2020
today is a special day for YANG-based automation as we release the "YANG-completions" feature with gnmic v0.4
I have only 1m30s to convince you that it is a dream turned into reality (or a black magic 💀)https://t.co/Nylyay1pl4 pic.twitter.com/IOnumRCOZi
Arista EOS gNMI Tutorial#
We were pleasantly surprised by the way community appreciated gNMIc release. Thank you 🙏! That solidifies the fact that a well-formed, documented and easy to use gNMI tool was needed.
Now with gNMIc available to everybody its easy like never before to test gNMI implementation of different routing OSes. And in this post we will get our hands on Arista vEOS.
gNMIc - gNMI CLI client and collector#
Despite the fact that gNMI is defacto the go-to interface for a model-driven telemetry collection, we, as a community, had no gNMI tool that was easy to install, pleasure to use, documented and pre-built for common platforms. Until now.
I am excited to announce the public release of gnmic - a CLI client and a collector that talks gNMI to your devices.
Tip
October 2022: gNMIc has joined Openconfig.
