NANOG87: Network Automation Show Down

A couple of months ago, Cat Gurinsky sent a general message in Linkedin asking for people to participate in a network automation panel during NANOG87 in Atlanta (2023, Feb 13-15). coincidentally, I was thinking over those days, what sort of presentation I could submit. Thinking in something that could be a good contribution to the community and saving a few bucks on the way for the registration. I told her I can bring something for the panel talking about how Kubernetes is helping with new things like “Custom Resource Definitions”.

After our first internal call with the panelist, she proposed to do a 101 of Kubernetes. She told many attendees would be interested in know more about it. And she was right. Coincidently, Karim also did a tutorial of his project gnmic. it’s like all things aligned at our favor.

The panel lasted for 90 minutes, I we got many questions from the onsite and online audience. I found many of the questions interesting to share:

When to start automating? From my point of view, it should have been happened Yesterday if your network has an important level of complexity and including a bunch of cloud systems. Cloud systems are automating some tasks that you don’t know already, like the connection between VMs or pods. If you feel that other areas of the network are also worth it to automate, well, that depends on the size of the networks, use cases, and related systems. Do it also If you feel like there’s an opportunity of making things faster every time you need to upgrade or give some access to an endpoint. Unnecessary meetings or tickets for things that are repetitive and relatively easy to parametrize, there you have your more opportunities.

How can I learn to be a developer and keep doing my job as network engineer (online question)? You don’t need to be a developer to start automating things. But you need to learn to do some code and change your mindset regarding how to do some operation tasks. it shouldn’t be a big difference between the logic you use to set up a complex peering configurations in routers, you know you need to be respectful of the syntax and order of the elements you are adding to the network. Coding is the same thing. I recommend to start with baby steps, doing some scripting to improve your troubleshooting work. Things first what arguments I need to get all the info I want to see what is the problem. Ansible could be a good starting point, there are tons of tutorials in youtube you can use as a starting point.

What about the language like go or python? In automation, you don’t necessarily must be a experienced developer. I know I am not. Most of the things I do in this space are copy and paste from online searches. Then, the answer to that can be very subjective. Personally, I prefer python, because it’s easier to understand, faster to code (copy/paste) and good enough for automation. With my minimal experience with Go, my feeling it is harder to read than python, like when someone wants to share an app with you, but efficient than python when you need better use of compute resources. Also Go, have better features to be used when you create your own apps on top of Kubernetes, to interact via APIs. Then, for advance applications, intended to work in containers, exposing APIs, I’d recommend Go. Anything else, I’d stick with python. Also, you have helm, sometimes the app is already developed and you just need to add a few values to make it work via K8s, no coding there.

Things I must do in automation to avoid issues in the future? On the top of my mind: document everything you do, hopefully any change should be immediately documented. You can use ‘git’ to add messages to every commit you do. Also ‘git’ will give you peace of mind, all your changes and progress will be backed up. using a ‘git repository’, shouldn’t be a big deal, you just need to learn a few commands. I use ‘github’ for example, it’s free. You can back up anything via ‘git’, from text files, images, yaml files to code. As soon as you finish and you are ready to play, create a document that explains all what you need to make it work. It’s easy to forget later, that would be helpful for you and anyone that want to use it. Create a virtual lab, I use containerlab, then you can try all your tools safely before go and do it with any real hardware. I also like to share what I did openly, it would be easy to look up later, people would contribute and that will force you to do a good documentation.

That’s all have (or remember). Let me know what you think. If you have comments, shoot. See ya!

Leave a Reply

Blog at

%d bloggers like this: