### Archives For VRFSearchTool

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.

I’ve updated my VRFSearchTool to version 0.0.10-beta.

Version 0.0.9-alpha was created as a new branch to address issue #1 and issue #2.  A few individuals uses this version for nearly two weeks and did not report any problems with it.  Therefore, I merged the new branch into the master, updated the version and took the application out of pre-release.

I now consider this version to be in Beta and ready for observed use in production environments.

Should you encounter any problems with it, please create an Issue here.

Should no problems be reported, then I’ll make it official and we’ll call it good as version 1.0.0

I’ve published VRFSearchTool version 0.06 Alpha on GitHub.

Approximately two weeks after I published my preliminary plans for the VRFSearchTool and not quite a week after I completely rewrote the functionality of the tool, I’m releasing the Alpha version.

Although it’s as functional as I expect the final product to be, I’m still calling it an Alpha at this stage because it’s still a little rough around the edges.  It contains the minimum amount of code to be usable, lacks some error-checking on user input and is short on commentary in certain sections of the code.

I expect the Beta version of the application to be published sometime next week, put into production and turned loose so the team can start playing with it and provide feedback.  Standby for another update, examples and screenshots next week!

This week I made great progress with my VRFSearchTool.  I’m still not ready to push it to GitHub just yet, so I thought I’d blog a little bit about how it’s coming along.

While working through the functions I realized that I could better streamline the flow of the application by moving some of the functions around.  Originally, the application design did not check for the presence of the “routers.txt” file until later in the program.  The more I thought about this, the more backwards this seemed.  The “routers.txt” file is required by the program to know which routers to log into.  This is a requirement, if you plan on updating the index of VRF names in your environment.

I’ve begun working on a new project entitled VRFSearchTool.

Put simply, this is a Python application that allows a user to search for a VRF name and returns the hostname/router of the gateway on which it is configured.

I regularly have the need to locate a VPN tunnel configuration across multiple routers and lack a quick-and-easy way determine which router this tunnel is configured on without using other slow or inconvenient means. The idea is that this tool will provide a (very) basic means of maintaining an index of all configured VRFs throughout a Cisco environment and provide the user with the ability to search for those VRFs.