AutoCon4 and NautoCon@AutoCon are in the books. It was quite the day, and I have to say that it ranks among my best days of the year in Network Automation — right up there with being able to meet up with the Network to Code team earlier in the year. It was great to see many friends from across the community. Hopefully we’ll be able to keep the conversation going in Slack and maintain the momentum.
It’s been a while since my last post — life and work have both been full. Today, I’m diving into one of the most quietly critical aspects of network design: time synchronization. Specifically, how to design NTP within an enterprise network and how to think about time zones when correlating logs.
We’ll look at two main topics in this post: designing NTP (Network Time Protocol) and managing time zone display in logs.
As the AI movement continues to expand its reach into the networking space, the need for an appropriate source of truth for network data becomes more critical than ever. What I have been seeing so far in the industry for networking and AI has been a lot of working on the individual devices one by one. But when looking at leveraging AI for the network, I believe it is best to look at the network as a whole. And that is where the Source of Truth data being stored in Nautobot is going to provide the right information about the network and the relationships between pieces of information - AI thrives on context, and relationships provide that context for more accurate insights and actions.
At a previous position to joining Network to Code I was asked to help to build automation to help with the configuration of switches going into a MLS stadium. The stadium was under construction and the network build out would take place at the same time as the stadium was being built out. It was definitely a first and maybe only opportunity that I would have to build out a new stadium.
The task at hand is that each of the ports would need to be configured leveraging a good L2/L3 separation with each of the service providers that provide a service to the stadium their own network segment to work through. A large number of ports were going to need to be configured.
Nornir includes a function that allows for the transformation of inventory data, a feature integrated within the Nornir platform itself. The documentation for Nornir 3.0 is somewhat sparse regarding the usage of Transform functions, so I often refer to the more comprehensive 2.5 documentation. According to the Nornir documentation:
A transform function is a plugin that manipulates the inventory independently from the inventory plugin used. Useful to extend data using the environment, a secret store or similar.
Today I’m going to dive into my getting started with network automation, and perhaps my first successful automation. There are definitely some things that I would re-do and complete differently, and some things that I consider a success.
I’m working on a new series within my blog, about how I would look to have done things differently than I had done before, with the tooling and knowledge that I now have, years later. This is the first in the series.