As you might have noticed form this week’s blog posts, I enjoy writing code to automate tedious or time consuming tasks. Well, maybe it might be a stretch to say I enjoy it — but I certainly reap the benefit of putting in the hard work to automate tasks that I otherwise hate performing. I do, however, enjoy publishing much of this code on the Internet in hopes that others will find it useful and I occasionally hear from them stating such.

In a past life, as a Network Engineer, I wrote a small application which automates the ability to search a Cisco router for a VRF VPN profile and back it up to disk. (If you’re making changes to your Cisco routers and you don’t back up your configurations before you change them, then you obviously haven’t broken one yet.) I received a lot of feedback from other people who found this tool to be useful and use it regularly. I also recently received word that it doesn’t work under Cisco IOS 15.4.

If you’ve been working in IT any length of time, you understand that every once in a while a piece of hardware just needs a good kick in the pants. I’ve generally found most Cisco products to be very reliable. Cisco Prime Infrastructure, however, seems to be an exception. I’ll spare you my biased opinion of this particular product and we’ll move on…

We have yet to fully implement Cisco Prime Infrastructure and use it for it’s intended purpose: making my life easier. It’s made my life anything but easier, but I’m still hoping to see it operate in all it’s glory and witness it effortlessly deploy updates to thousands of routers simultaneously. Before that can happen, we’re still continually updating devices which often required bulk imports containing hundreds of devices (either to add or update existing records) and the occasional deletion of devices. For whatever (unknown) reason, the jobs often fail to complete thereby prohibiting you from submitting subsequent jobs.

Unfortunately, the only “solution” we have to date is to reload the box. Only not-so-recently have I determined that there is a wrong way to reload Prime and a right way to do it. Guess which method I’ve been using?

Last year I discovered a bug in the “show crypto debug-condition” command. This bug doesn’t impact the operation of the router and is purely cosmetic. By cosmetic, I mean the output from the show command isn’t correct although the setting in the router is.

Here is what I’m talking about (compare the profile name I set in line #1 “abcdefgh” to the output you see line #11):

One of my favorite interview questions to ask network engineering candidates is “How many different ways can you describe to determine the serial number of a Cisco router?”

Surprisingly, a majority of candidates never get beyond physically inspecting the router to obtain the serial number. A few give me the obvious answer of using the “show version” command and a rare handful have ever given me more than two commands that might display that information.

Yet, despite the many ways to determine the serial number of a Cisco router and the thousands of Cisco routers that I’ve managed, I finally came across this unsociable router.

Yesterday I discovered an error in my DownloadRouterConfig application where it would terminate abnormally if a variable (a path name) in the settings.cfg file was left blank. Should no path name be specified, the application should have used it’s current working directory. Instead, it just crashed.

In fixing the code, I realized that all my other applications used this same function — so I corrected all of them as well. (I also took care of a few other miscellaneous things while I was in there. See the CHANGELOG, if interested.) If you happen to be using any of these applications to help manage your own Cisco routers, you’ll want to pull the latest code down to prevent any possible errors in the future.

The primary reason I decided to revive my rusty programming skills was to automate tedious or time-consuming functions at work. I’m a big proponent of automation whenever possible and in an age of employment where we’re all asked to do more with less, I’ll gladly invest the time required to “automate all the things”.

However, automation is only useful if embraced by everyone that can benefit from it. Despite frequent lip service from colleagues who expressed excitement over the creation of a few of my applications, I had reservations about who may actually be using what within the team.

So I decided to have a look…

Several weeks ago I placed a small bit of code in all of my applications to capture their usage data:

import getpass # Required to read username from the command line
def trackUsage():
# This function appends a line to a file with the timestamp, user name
# and name of the application so I can see who is using what
with open("X:\path\to\file.log", "a") as appUsage:
try:
appUsage.write(str(datetime.now())+","+getpass.getuser()+","+__title__+" "+__version__+"\n")
except IOError:
pass

Of course, it could be that some of my teammates are using antiquated versions of some of my applications despite corrected bugs or limited functionality — and there certainly isn’t any way for me to determine that. Given the frequency in which I have communicated that each person obtain the newest version AND the results I’ve outlined above — I must conclude that either my enthusiasm for improving our work flow and time management isn’t shared among my team or I hold my applications in higher regard than they’re actually worth.

If you’ve been following any of my other Python applications I’ve written to automate tedious tasks on a Cisco router, you might have noticed that they all seem related. Between BuildVRFIndex.py, VRFBackupTool.py and VRFSearchTool.py — you may have wondered why all these weren’t combined into a single application. With the exception of BuildVRFIndex.py, it was always my intention to combine the VRFBackupTool and VRFSearchTool into one application.

It’s been more than 10 years before I’ve written any meaningful amount of code and that was last done in C++. Learning Python has been an enjoyable experience — but I’m still learning the language. I wasn’t certain that I would be able to easily (or cleanly) create the application I had in mind with Search AND Backup functionality — so I broke these functions out into separate applications until I was certain that this would be something I could accomplish with as little frustration as possible.

Having said all that, the VRFSearchAndBackup tool is the combination of the search and backup features of the other two and, in my opinion, supersedes both of the prior tools in functionality. You can still search for a VRF Name to determine where it is without having to back it up (the application prompts you to backup upon a successful search).

There is a lot more I could say about this application but since it’s been out several weeks now and I’m just now catching up on blogging about it, you can head on over to it’s GitHub repository if you’d like to learn more or see it in action.

Building on the experiences of my other Python applications (namely the VRFSearchTool), I took this knowledge to the next level and created an entirely new application. Similar in functionality to the VRFSearchTool, the VRFBackupTool will back up the VRF VPN configuration of a Cisco router when provided with the VRF Name. Unlike the VRFSearchTool, it does not display any information regarding the VRF Name provided — it simply locates it among the index file, connects to the router(s) holding the configuration specific to the VRF Name and backs it up to a directory specified in the configuration file.

There is a lot more I could say about this application but since it’s been out several weeks now and I’m just now catching up on blogging about it, you can head on over to it’s GitHub repository if you’d like to learn more or see it in action.