Behind the scenes of RANCID (5 of 30)

If you are a network guy, even if you have never installed, used, or seen RANCID, you probably still know about it. However, in case not, you can find more at Shrubbery Networks, where you will find this short write-up on what RANCID does.

RANCID monitors a router’s (or more generally a device’s) configuration, including software and hardware (cards, serial numbers, etc) and uses CVS (Concurrent Version System) or Subversion to maintain history of changes.

There is a log of documentation on how to install, configure and run RANCID, but I haven’t found much that explains how all of the configurations files and scripts interact with each other. If you are looking for an installation guide, you are best to use the previous link, the below links, or search google, is this will not be covering that aspect of it. If you were like me, and trying to figure out how it all interacts, so you can make adjustments, here is what I have come up with.

TLDR Version: rancid.conf is the main configuration file, rancid.types.base specifies what the script and commands you run for each file, .cloginrc is the password file, rancid-run creates directories and handles all of the svn/cvs of your config changes, and can run one device or all devices in one command. Understand the login script, vs the type script and it will help you troubleshoot auth/connection issues.

The Primary configuration file is under the etc/ directory and is called rancid.conf. In there you can configure your e-mail list, choose CVS or SVN, create your groups, how many devices it will pull in parallel, how many times it will try before giving up.

For me I preferred SVN, and I used this guide to help. I also configured the configuration file with 10 times parallel count and 2 times to max attempt, as I noticed very little difference in configuring less parallel files on CPU in memory, and the failed attempts took a long time.


The group creation is pretty simple and it a easy way to differentiate your devices by type, region, etc…

The next file is rancid.types.base–which the function best I can tell–historically was taken care of by rancid-fe (rancid front-end), however I have only been using it for a few months and haven’t used any of the older versions. In the rancid-fe there is a loop that pulls all of the “Router” types you have.

There will you see one of two types of configurations, one that only refers to a script, and the other where you define the script and the commands you will run. In the second type,  you refer to a perl module, that is located in lib/rancid/ which is good to know in case one of your parser’s is not working correctly.

As previously indicated, you can simply call a script, that locks you into which commands and parsers are used. The only way to modify is to modify the actual script.


However, if it is referring to a module, you declare the login script, the module, and the the parser you need per command. This is convenient, since you can add and remove commands used.

cisco;script;rancid -t cisco
cisco;command;ios::ShowVersion;show version
cisco;command;ios::ShowRedundancy;show redundancy secondary
cisco;command;ios::ShowIDprom;show idprom backplane
cisco;command;ios::ShowInstallActive;show install active
cisco;command;ios::ShowEnv;show env all
cisco;command;ios::ShowRSP;show rsp chassis-info
cisco;command;ios::ShowGSR;show gsr chassis
cisco;command;ios::ShowGSR;show diag chassis-info

If you care to create your own types, here is a short description how, just remember that rancid-fe is no longer needed to be changed, instead use the rancid.types.base.

When you are specifying the script, it is of interest to know what it is doing, which can help you trouble shoot later. Let’s say you look at the “rancid” script, it points to clogin as it’s underlying expect script, which informs the “rancid” perl script how to login what type of prompt to expect, e.g. test-sw01> or test-sw01# and how to parse that out. You can run the rancid script by itself with a “-d” flag and it will show you the clogin command it is running. If the rancid file fails, you can see the raw output of the script by running the same clogin command. This will help you find where your issues are. This has helped me find issues like password mismatches, ssh version mismatch, and some more obscure things.

.cloginrc is your password configuration file, (see other links for more details)

The router.db file located at var/<group name/router.db maintains the list of devices that rancid-run will pull from. This directory is created after you have updated the rancid.conf file, and ran rancid-run. (again, see other links for more details.)

The main process is  rancid-run which pulls the names of the devices from the various router.db files, runs the type specific script (based on information from the rancid.types.base file) and updates your cvs or svn commit’s. You can specify a group, an individual device, or just let it run wild.

The logs are time stamped per group and can be found in var/logs from the base rancid directory.

I have created a series of scripts that pull from dns the devices, based on dns name figures out which type it is, and populates the router.db. I check to see what has changed week to week, and ensure something was removed manually before removing it from the router.db.

I also put together a web grep front end, that I have come to enjoy, with the parsing it makes it easy to pull things like OS, serials, module #’s etc… from one place. I also find that I don’t login to devices as much anymore, I just go the the svn web page and do a search from there, as I find it easier to be able to search forward and backwards.

RANCID certainly requires some configuration and know how, hopefully this will help you along your way. If you have any other tips, please share in the comments.

Here are some more links that I found useful in along the way.

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>