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.
It seems that the TIG-Stack not only excels in the data center, but as a home automation UI as well – thanks to the versatile Telegraf input agent. Stock OEM display solutions often cost an arm and a leg, so I decided to build my own over a year ago. This post is about the hard- and software in use, as well as the necessary configuration to realize a useful dashboard system for your precious home.
Whether you are looking for a little test bed or an always-on home dashbording system, the RaspberryPi is a great, affordable platform for the TIG-Stack. So let’s ride through all the necessary steps ‘From Zero to Awesome’ in less than one hour.
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 …
Modern controller based networks are quite different from a monitoring perspective, all the fancy network abstraction information is hiding behind this thing called API. SNMP might still be there, but is missing most of the interesting bits like health scores, faults and Tenant/App/Policy based metrics. And sometimes your legacy ehm, established NMS has no clue how to query or interpret those programmable interfaces…
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.