Network Automation using Ansible(Simple Commands)(Part 2)

Ad Hoc Commands

The first and simplest way to use Ansible is with ad hoc commands. These are commands that are meant to execute a single task. The only element that is required for this to function properly is a properly configured inventory(hosts) file. This is what it looks like:

I have a group called gns3-Routers, which then contains 4 hosts in it(R1 to R4).

Troubleshooting Use Cases

As a networking specialist, I find myself having to troubleshoot different issues related to the network. I always start my troubleshooting process at layer 1 and 2 of the OSI model. This is done in order to assure myself that the network cable is not defective and that my port is able to learn MAC addresses. This is the command used:

I can also see if there is any IP address issues(wrong assignment) or the port is manually shutdown. However, this requires me to connect to a device and manually input this command. Now with Ansible, we can accelerate this process at a much higher scale.

Using GNS3, I had some issues with the formatting of my text in the terminal. My lines were wrapping around in a weird manner. Therefore, I decided to use the history command in Linux to display the commands that I executed.

So now let us dissect this command bit by bit:

->The time command is used to keep track of the total amount of time required to execute this operation.

->Ansible performs an operation on the gns3-Routers group. Instead of the group name, I could have specified a single router.

->The -m option is used to specify which module we would like to use. I am using the raw module which is used to perform SSH commands. This is useful for hosts that do not have tools such as python installed on them. Many routers are unfortunately deprived of this amazing utility.

->The -a option specifies the argument that will be executed on the target device. I decided to pass it the "show ip int brief" command.

->The last 2 options are quite simple. The -u option tells Ansible which user(Ahnaf) will be used to remotely connect to those devices. The -k states that a password will be asked for when trying to connect to the target.

This is the output of my command:

It is quite long, so you will only see the interface information of router R2 to R4(R1 is cut out). So instead I decided to run a modified version of my instruction which tries to see if the operation succeeded on the 4 target devices. Here is the modified version with its respective result:

Say that you walked into a client's infrastructure which comprised of 100 switches. To gather up interface information from all of those devices, it would normally take an eternity! Now with Ansible, it can be done in a blink of an eye. Look at how long it took me to gather up all of this info of my network setup. Less than 5 seconds! Try to beat that. Why should you do the heavy lifting? Let the machine do it for you and keep enjoying your coffee.

Backup Use Case

Normally operations engineers, would go about installing and configuring their devices. Afterwards, they would make sure to backup the device configuration in a safe place(Backup server). Time to time, electronic devices fail or experience some form of malfunction. The usual routine taken to deal with this issue would be to pull the defective device out of the rack. Then take a replacement unit and install it into the rack. Then one, would take a working configuration(template) from the backup server and install it on it.

Well now, that we have grasped the power of Ansible, we can redesign this operation. Why not let Ansible gather up all of our devices configurations?

Let us analyze this command:

->Once again, the time command is being invoked.

->Same group(gns3-Routers), module(raw), user(Ahnaf), password prompt(-k) as before.

->This time the -a option is being passed the "show startup-config" option. On Cisco IOS, a device's configuration is saved in a file named startup-config. This file is stored in NVRAM(Non Volatile RAM).

->When running the "show startup-config", the device configuration is displayed on an output device(Screen). Instead of outputting to a screen, I use the redirection operartor(>) to send it to a file named "router_backups.txt".

At the moment, I have all of my device configurations in a single file. I then ran a Linux command to organize my information into different files:

Let us take a closer look at this command:

-The --prefix option is used to specify the beginning of the file names.

-The -z option is used to remove any empty output files that will be created. I noticed that my command was creating files named xx00 up to xx04 and that xx00 was always empty.

-I then specify my file that will be split up into many smaller files.

-The last part of the command instructs the system to search for the string called "SUCCESS" as many times as possible. In my case it would execute 4 times in total because I had 4 routers.

Now to verify my work, I listed the files in my current directory:

And Voila! How simpler could this get? I love how tedious tasks can now be performed in such a relaxed manner. You no longer need to spend hours typing long winded commands. Remember use the resources of the machine to do it for you. You can now tend to more important affairs.

Other Plausible Use Cases

All of the examples that have been demonstrated up until now can be performed on any device(Router,Switch,Firewall). However, for certain scenarios it can be useful to perform device specific operation. Depending on your needs, you would use platform specific commands.

Let's say that you were troubleshooting Layer 2(Switches) related issues. You could use Ansible to check if you had properly configured your VLANs on the proper switches. Then, if everything worked out well, you could once again check if your Trunk ports are correctly set up. Trunk ports can carry the traffic of many VLANS and they are configured between switches.

You could even troubleshoot some Layer 3(Routers) routing issues. With Ansible, you can now check the OSPF adjacencies at once. This can be very helpful in performing root cause analysis. Depending on which state your adjacency gets stuck in, you can determine if its a maximum packet size(MTU), packet filtering(ACL) or other configuration related issues.

I will not start enumerating every single use case because it would never end. Instead, I would recommend that you use your creativity to incorporate this fabulous tool in your toolkit.

Reference:

-https://www.pinterest.ca/pin/752734525188401046/