Tag: automation

This is the second post in the series on Napalm validation in which we will explore more options available to us for writing validation tests. First part can be found here: NAPALM-Ansible - Automatic validation - part 1. First we'll make amendments to YAML files we used to describe desired LLDP state and see how it affects validation results. After that we'll introduce two more examples, one for checking BGP peerings, and one for verifying reported interfaces. Contents Partial string matching and regex BGP peering validation example Strict mode and 'list' key Listings of Playbooks GitHub repository with resources for...

Continue reading »

Have you ever found yourself needing to quickly sort IP addresses directly from the Linux shell? You just ran grep against all of your configs looking for IPs in some subnet, but they're all unordered, and you just wish you could pipe the output and have them sorted. I kept running into the same problem. When it got painful enough I found a website that allowed me to copy-paste and sort all of the IPs. That worked for a while but wasn't satisfying enough. Then I found a cool looking bash one-liner, with cut, sort, and other unix utilities, combined...

Continue reading »

Network automation is not just about configuration management. Equally, if not more, important is validation of the state and models. After all, what is automating configuration changes good for if you don't know whether the end state of the system is correct? In the first blog post in the series I'll briefly describe Napalm, and it's validation feature, followed by an example Ansible playbook that we will use to automatically validate LLDP neighbours. This can be used to makes sure newly deployed devices are correctly patched, or to confirm that the existing environment is connected the way we think it...

Continue reading »

Let's talk about passing extra Playbook variables from command line. First off, why would you want to do it? Maybe you want to execute task only if a variable is defined, which is handy for debugs and tasks with additional processing. Or maybe you have a more generic playbook that can work with more than one version of OS, and you want your user to decide which one OS he wants to run Playbook for. I will show in this post how we can tackle both of these problems. Contents Introduction to extra variables Execute task when variable is defined...

Continue reading »

When running tasks Ansible allows you to access facts about host currently being processed. These could be facts discovered by Ansible itself or loaded from the files in the host_vars directory. This is something that we use all the time and is fairly intuitive. Sooner or later you will probably find out that some of your tasks, or data models, could be made simpler if you could access another host's facts, not just the ones belonging to the host Ansible is currently processing. As it happens, this is possible by using something Ansible calls magic variables. The particular variable...

Continue reading »