The most important part of any network automation solution is a reliable inventory. In large and complex network environments, a central DCIM like Netbox or Nautobot with dynamically generated inventories seems to be the gold standard.
But many of us start their automation journey with simple text files, following the idea of infrastructure as code. However, even this approach is suitable as a comprehensive device asset management and can even replace existing tooling. Here is the why and how.
DevAsc has been a dream of mine since the beginning, but I never really found the time during this crazy year. When Cisco extended the deadline for the DevNetClassof2020 though, I took that as a sign and started my journey at short notice towards the end of 2020. Now you can learn what I think about the exam and the way I prepared.
So far this little InfraAsCode series was all about declarative Ansible playbooks and Git version control. In this last post we go full circle and discover how CI/CD pipelines helps with automation workflows, taking full advantage of good software development practices.
In part one we learned how to use Ansible and a data model to represent infrastructure as code. Now it’s time to introduce Git as the central network automation tool to use the advantages that result from working with text files.
I cannot emphasize enough how important this step is to long-term success with an automation initiative. Unversioned files with funny names in a random directory are not the solution.
Infrastructure as code is all the rage, but sounds hypercomplex. How should it be possible to represent a router or even a whole network as code? We definitely need deep software development skills and an extensive version control plus CI/CD pipeline, right? Well, no! Actually, it’s pretty darn simple and by the end of this blog post you might wonder what took you so long to get started.
This topic came up via Twitter recently and I heard this use case before but wasn’t aware how easy it could be solved with Ansible, until I started thinking about it. The little playbook in this blogpost fetches all discovered neighbors per device and sets the interface description according to the remote host and port. It supports the two platforms Cisco IOS XE and NX-OS to demonstrate the path to a multivendor solution for the common brownfield networks out there.
Most Network Automation publications tend to focus on the technology, how to code, build useful pipelines, and this week’s tool of fashion. But isn’t that a very one-sided view of the topic? I mean after all, people are what make automation happen and drive those projects forward. Thankfully Skynet is too far away to autonomously build automation frameworks and the ‘Self-driving Network’ never made it from marketing to the real world.
I know, even Cisco NX-OS has a REST-API and Streaming Telemetry these days. But you, or established processes in your organisation, might find it helpful to handle all switch ‘Telemetry’ in the same way using good old per device SNMP polling. A quick poll* on the Twitters seems to validate that ~80% of production network metrics are still SNMP anyway.
This blog post from the folks at NetworkToCode about the DRY principle (Don’t Repeat Yourself) reminded me of our early network automation days. There were playbooks involved, external variable definition files as a first step to source of truth and, well, lot’s of redundant data …
Managing hundreds of devices with your monitoring system might be a tedious task, especially when using GUI based device onboarding. But why not let your config management tool of choice take care of it? This blog post is about a declarative Ansible playbook to generate Telegraf configuration files leveraging the inputs.ping plugin and populate a Grafana World Map.