One of our subscribers sent me this email when trying to use ideas from Ansible for Networking Engineers webinar to build BGP route reflector configuration:
I’m currently discovering Ansible/Jinja2 and trying to create BGP route reflector configuration from Jinja2 template using Ansible playbook. As part of group_vars YAML file, I wish to list all route reflector clients IP address. When I have 50+ neighbors, the YAML file gets quite unreadable and it’s hard to see data model anymore.
Whenever you hit a roadblock like this one, you should start with the bigger picture and maybe redefine the problem.
One of the first roadblocks you’ll hit in your “let’s master Ansible” journey will be a weird error deep inside a Jinja2 template. Can we manage that complexity somehow… or as one of the participants in our Building Network Automation Solutions online course asked:
Is there any recommendation/best practices on Jinja templates size and/or complexity, when is it time to split single template into function portions, what do you guys do? And what is better in terms of where to put logic - into jinja or playbooks
One of my friends described the challenge as “Debugging Ansible is one of the most terrible experiences one can endure…” and debugging Jinja2 errors within Ansible playbooks is even worse, but there are still a few things you can do.
Some network devices return structured data in either text- or XML format (but cannot spell JSON). Ansible prefers getting JSON-formatted data, and has a number of filters to process text printouts… but what could you do if you want to work with XML documents within Ansible? I described a few solutions in Transforming XML Data in Ansible.
Here’s an interesting tidbit from “Last Week in AWS” blog:
From a philosophical point of view, AWS fundamentally considers an API to be a promise. Services that aren’t promoted anymore are still available […] Think about that for a second - a service launched 13 years ago is still actively supported to the point where you can use it today.
A month ago I described how Paddy Kelly used pyATS to get VRF data from a Cisco router to create per-VRF connectivity graphs.
Recently he also wrote a short article describing how to get started with pyATS and Ansible. Thank you, Paddy!
Imagine you want to create a Jinja2 report that includes only a select subset of elements of a data structure… and want to have header, footer, and element count in that report.
Traditionally we’d solve that challenge with an extra variable, but as Jinja2 variables don’t survive loop termination, the code to do that in Jinja2 gets exceedingly convoluted.
Fortunately, Jinja2 provides a better way: using a conditional expression to select the elements you want to iterate over.
Have you ever seen an Ansible playbook where 90% of the code prepares the environment, and then all the work is done in a few template and assemble modules? Here’s an alternative way of getting that done. Is it better? You tell me ;)
I had a fantastic chat with David Bombal a while ago in which we covered tons of network automation topics including “should I use Nornir or NAPALM or Netmiko?”
The only answer one can give would be “it depends… on what you’re trying to do” as these three tools solve completely different challenges.
Paramiko is SSH implementation in Python. It’s used by most Python tools that want to use SSH to connect to other hosts (including networking devices).
As I was preparing the materials for Ansible 2.7 Update webinar sessions I wanted to dive deeper into declarative configuration modules, starting with “I wonder what’s going on behind the scenes”
No problem: configure EEM applet command logging on Cisco IOS and execute an ios_interface module (more about that in another blog post)
Next step: let’s see how multi-platform modules work. Ansible has net_interface module that’s supposed to be used to configure interfaces on many different platforms significantly simplifying Ansible playbooks.
I always love to hear from networking engineers who managed to start their network automation journey. Here’s what one of them wrote after watching Ansible for Networking Engineers webinar (part of paid ipSpace.net subscription, also available as an online course).
This webinar helped me a lot in understanding Ansible and the benefits we can gain. It is a big area to grasp for a non-coder and this webinar was exactly what I needed to get started (in a lab), including a lot of tips and tricks and how to think. It was more fun than I expected so started with Python just to get a better grasp of programing and Jinja.
In early 2019 we made the webinar even better with a series of live sessions covering new features added to recent Ansible releases, from core features (loops) to networking plugins and new declarative intent modules.
Have you ever wondered how many free ports you have on your stackable campus switches? I’m sure there must be a wonderful network management tool that creates that reports with a click of a button… but what if the tool your PHB purchased based on awesome PowerPoint and glitzy demo can’t do that?
Nadeem Lughmani decided to solve this challenge as a hands-on assignment in the Building Network Automation Solutions online course and created an Ansible playbook and a Python plugin that counts the total number of ports and number of free ports for each switch stack specified in the device inventory.
Wonder what else course attendees created in the past? Here’s a small sample.
This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.
One of the common questions I get once the networking engineers progress from Ansible 101 to large-scale deployments (example: generating configurations for 1000 devices) is “Can Ansible use a relational database? Text files don’t scale…”
TL&DR answer: Not directly, but there are tons of database Ansible plugins or custom Jinja2 filters out there.
This is a guest blog post by Albert Siersema, senior network and cloud engineer at Mediacaster.nl. He’s always busy broadening his horizons and helping his customers in (re)designing and automating their infrastructure deployment and management.
We’d like to be able to automate our network deployment and management from a single source of truth, but before we get there from a running (enterprise, campus!) network, we’ll have to take some small steps first.
These posts are not focused on 802.1x, but it serves as a nice use case in which I’ll show you how automation can save time and bring some consistency and uniformity to the network (device) configuration.
A long while ago I published a sample Ansible/NAPALM/Jinja2 solution that would take LLDP information and turn it into a network diagram (I described its details in a short video that’s accessible to anyone attending our network automation course or having an Expert subscription).
The trickiest part of that solution was detection of bidirectional links:
When I started working with Ansible networking modules they had a distinct science fair feel: everything was in flux, every new version of Ansible would break my playbooks, modules would disappear from one release to next, documentation was sketchy and describing the latest development code not a shipped release.
In the meantime, code, documentation, and release/deprecation management improved dramatically: