It started out as a question. If you are using several networking modules in a playbook, do you really have to repeat the same credentials on every task? Just like the last few articles about Ansible this one came to life after answering questions in a chat room. The short answer is; No you don’t have to include all of the required parameters for every task, you can use an action plugin to work around that. Great! So what’s an action plugin?
At the outset, a 1200 word article about saving configuration sounds strange. It would perhaps be perfectly normal if the topic was Vi and not Ansible, however there’s a reason for this and its simply speed and itempotency. Saving the configuration in the “wrong” way can take quite a lot of time and one reason for network automation is to accomplish tasks faster and constantly search for ways to improve your processes. This article assumes that you are running Ansible 2.4, but it should work in a similar way regardless.
Aside from being a user, I write about Ansible and try to help others to understand how it works. A few days ago I was answering questions from other Ansible users. Someone was having trouble figuring out why the ios_config module didn’t apply his template correctly. I explained what was wrong with the template, afterwards I thought about the issue some more and realized that the error could potentially be really dangerous. As in a game-over-level-event for your employment dangerous.
Flask includes a Python decorator which allows you to run a function before the first request from a user is processed. The problem I had is that the function doesn’t get run until after a user has visited a page for the first time. This article describes a way to solve that. If you haven’t heard of Flask before it’s a Python microframework for web applications. With Flask you can create small or large websites. While this article isn’t a getting started guide for Flask, it will include a complete working application.
A lot of people who aren’t familiar with Napalm tend to laugh nervously when you suggest they use it in their network. The name Napalm is partly based on getting that perfect acronym and partly a desire to incinerate the old way of doing things and move to network automation. This article is about explaining what Napalm is and what lies behind the acronym.
A lot of new networking modules were released as part of Ansible 2.1. The Cisco IOS, IOS XR, NXOS, Junos and Arista EOS platforms got three common modules, the platform_config, platform_command and platform_template. The command and template modules more or less explains themselves. The config modules have some more tricks to them and I’ve gotten a few questions about how they work. In this article I’m going to focus on the ios_config module and show how you can use it to configure Cisco IOS devices. Future version of Ansible will add more parameters, this article is for Ansible 2.1.
It can get quite exciting when you start to think about network automation and what it can do for you and your network. Once you’ve automated everything you can instead focus on deep work to evolve your business. However this daydream can soon fade away as you start to think about the things you can’t automate, or at least don’t know how to do. Ivan Pepelnjak wrote a piece about automating the exceptions. The post is based on a discussion he had with Rok Papež and his ideas about handling exceptions in an automated way. While the strategy presented is great I think it overlooks some parts when it comes to exceptions that can arise, also the post doesn’t highlight how limitation of the configuration management tools were solved.
I was recently asked to automate the way a client handles Cisco IOS upgrades. As I’ve been using Ansible a lot lately I decided to start there. Basically the steps required to do the upgrade can be broken down into parts which map quite nicely to tasks in an Ansible playbook. Even if you aren’t using IOS you might find it interesting to see how different Ansible modules can be combined in order to complete a set of tasks.
Even if you have tools in place to automate your network configuration, there’s a good chance that someone has made some manual changes. Perhaps some of your routers were overlooked the last time you send out that access-list, or a new site has been deployed using an old template. In those situations you want to audit the configuration of your network devices. Network configuration audit is one of the features of Nelkit.
Until there is a universal standard which states how to access network devices I believe SNMP is the best option when it comes to determining what a device actually is. While SNMP’s glory days might be long gone, if there in fact were any. There are still some instances where SNMP is more handy than the modern APIs we have now. All network devices respond in the same way to SNMP queries. This can be compared to a REST API where you have to know the URL of the API before you can target a device. Even with SSH which is also a standard the implementation differs between various vendors, while this doesn’t matter if you are connecting to the device manually it does if you are using a script. Looking at Netmiko a Python library for SSH, you have to specify device vendor and class when you connect. This is because SSH doesn’t work the same with Cisco devices, compared to HP devices, as prompts and paging work differently. However with SNMP it always works the same, sure all vendors have specific MIBs that they use. But general queries for standard MIBs work the same. Using a standard MIB it’s possible to identify the manufacturer of a device and often it’s version.