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.
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.
Tired of scrolling through massive directories on a file server, flooded with config files? Easy to implement ‘backup’ solution at day one (IOS archive?), but often based on debatable, unreliable protocols like TFTP, combined with great challenges in tracking changes on day two.
So, your lab is set up and waiting for something meaningful to do? This post introduces the two probably most commonly used networking modules in the Cisco IOS world – it’s no rocket science to use other vendors’ modules in the same way, by the way. IOS_command executes, well, commands at the privileged level, while IOS_config is used in config mode – no surprise there, right?
Depending on your personal background there are many different ways to approach networks or (more general) infrastructure devices in a programmatic way. If you are blessed with sufficient coding skills, please go straight to Python and frameworks like Nornir to get things started. This post though is for long time network engineers with little or no software experience.