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.
RANCID is, in my opinion, a must for anyone who must manage and/or maintain network devices. It will automatically backup the configurations on all your devices, as well as providing notification of any changes that have occurred. This is very useful in an environment where numerous people may be making changes to the network devices.
Packages exist for recent versions of Ubuntu making installation and configuration of RANCID on Linux much easier.
To get started setting up RANCID, let’s first install the applicable packages:
[jlgaddis@SERVER ~]$ sudo apt-get install rancid
This installation will create a new user and group named “rancid” with a home directory of “/var/lib/rancid”.
Now, we must create at one least one group in RANCID to logically organize our devices. Groups can be based on any criteria you wish. In our installation, we create groups based on the geographical location of devices. For the sake of example, let’s assume we have network devices in three locations: Atlanta, Chicago, and New York. We’ll create a group for each.
Open up the file “/etc/rancid/rancid.conf” in your favorite text editor, add a line similar to the following, and save and exit.
LIST_OF_GROUPS="atlanta chicago newyork"
Next, we need to let RANCID know who should receive e-mail notifications for each group of devices. This is done by creating e-mail aliases in your MTA’s configuration files. Most MTAs will use the “/etc/aliases” file for this, making our job simple.
For each group that you created, we need to add two aliases to the aliases file named “rancid-<groupname>” and “rancid-admin-<groupname>”. Open up the “/etc/aliases” file in your text editor and add lines similar to the following:
rancid-atlanta: jlgaddis rancid-admin-atlanta: jlgaddis rancid-chicago: jlgaddis rancid-admin-chicago: jlgaddis rancid-newyork: jlgaddis rancid-admin-newyork: jlgaddis
After saving your changes and exiting, you’ll need to let your MTA know about the changes. Depending on the MTA, this may be accomplished by running (as root) “/usr/bin/newaliases” (if you’re using sendmail) or “/usr/sbin/postalias /etc/aliases” (if you’re cool and use Postfix).
Running “rancid-cvs” is our next step. “rancid-cvs” will take care of creating groups in CVS for us, using a structure based off of the RANCID groups we created. We’ll need to run this as the rancid user that was automatically created earlier, like so:
[jlgaddis@SERVER ~]$ sudo su -c /var/lib/rancid/bin/rancid-cvs -s /bin/bash -l rancid
Assuming that runs without any errors, you should see a number of new directories created under “/var/lib/rancid”, named according to the RANCID groups you defined earlier (e.g. “/var/lib/rancid/atlanta”, “/var/lib/rancid/chicago”, “/var/lib/rancid/newyork”, etc). Inside each will be a file named “router.db”:
[jlgaddis@SERVER ~]$ sudo find /var/lib/rancid -type f -name router.db ./atlanta/router.db ./chicago/router.db ./newyork/router.db
Inside each of these “router.db” files is where we let RANCID know what devices exist in each location. A single line in each file is used to identify a single device. The format of the definitions is of the format “hostname:type:status”, where “hostname” is the fully-qualified domain name or IP address, “type” defines the type of device (e.g. “cisco”, “hp”, “foundry”, etc.) and “status” is either “up” or “down”. If “status” is set to “down”, RANCID will simply ignore the device.
Sample entries might look like this:
atl-c3750.net.example.com:cisco:up chi-hp8212.net.example.com:hp:up ny-b8000.net.example.com:foundry:down
Once you have successfully added your devices to the appropriate “router.db” files, we need to let RANCID know how to access the devices (telnet, SSH, etc.) and what credentials to use to login. This is done via the “.cloginrc” file that exists in the rancid user’s home directory (“/var/lib/rancid/.cloginrc”, by default).
In my case, all devices are accessed using SSH (telnet is bad!) and we have created a user object in our enterprise LDAP directory just for RANCID. That makes this step of the configuration process that much simpler, as we can use one entry in “.cloginrc” for all devices. My “.cloginrc” file looks similar to this:
add autoenable * 1 add method * ssh add user * rancid add password * s3cr3tpassw0rd
NOTE: The cloginrc(5) man page details all the available options and keywords available for use.
With RANCID now configured, it’s time to test it out! Let’s manually invoke “rancid-run” (as the “rancid” user) to see if it all blows up!
[jlgaddis@SERVER ~]$ sudo su -c /var/lib/rancid/bin/rancid-run -s /bin/bash -l rancid
This command may take a while to run, depending on how many devices you have configured. Be patient and, when it finishes, review the logfiles created in “/var/log/rancid”.
Assuming all goes well, you should receive e-mails from RANCID sent to the addresses that you defined in earlier in “/etc/aliases”.
Once everything is working, it’s time to automate the collection and archiving. The easiest way to do this is to simply create a cronjob under the rancid user that calls “rancid-run” for us on a periodic basis. We have RANCID run every hour at one minute past the top of hour, e.g. 12:01, 1:01, 2:01, etc.
Let’s begin by editing the “rancid” user’s crontab:
[jlgaddis@SERVER ~]$ sudo su -c "/usr/bin/crontab -e -u rancid"
Add the following line to the crontab and save and exit:
1 * * * * /usr/bin/rancid-run
You’re all done! RANCID should now begin polling all your devices one minute past the hour and will generate e-mail notifications showing the differences in configuration since the last run.
Here’s a portion of a sample notification e-mail:
- !VLAN: 2964 VLAN2964 active + !VLAN: 2964 VLAN2964 active Gi0/4 @@ -278,8 +277,9 @@ no cdp enable spanning-tree portfast ! interface GigabitEthernet0/4 + switchport access vlan 2964 switchport mode access switchport nonegotiate shutdown no lldp transmit
The first portion shows that, previously, no interfaces were a part of VLAN 2964. Now, we can see that interface Gi0/4 is a part of VLAN 2964.
The second portion shows the actual differences in the running configuration. We can see that the command “switchport access vlan 2964″ now exists under the interface configuration for GigabitEthernet0/4, while it did not previously. As you can see, from the e-mail notification, we can quickly determine what configuration change was made.