Backing Up Router Configurations
Problem
You need to download all of the active router configurations to see what has changed recently.
Solution
The Perl script in Example 1-4 automatically retrieves and stores router configuration files on a nightly basis. By default, it retains these configuration files for 30 days. The script should be run through the Unix cron utility to get the automatic nightly updates, but you can also run it manually if required. No arguments are required or expected.
Example 1-4. backup.pl
#!/usr/local/bin/perl |
Discussion
As we mentioned earlier in the chapter, it is extremely important to make regular backup copies of your router configuration files. However, as the size of your network grows, it becomes quite tedious to maintain a useful archive of these backups. This script automates the task of collecting and storing router configuration files on a Unix-based TFTP server.
This script will maintain 30 days worth of configuration files. We have found that this is a reasonable length of time, allowing engineers to recover router configuration files that are up to one month old. However, if you prefer, you can change the $days variable to increase or decrease how long the script will store these files before deleting them. If you increase the length of time that the server must store these files, it will obviously increase the amount of disk space you need to hold the extra configuration files. But router configuration files are generally quite small, so this is usually not a serious problem unless you support thousands of routers.
Before executing this script, you will need to modify a few variables. First, the $workingdir variable should contain the name of the directory that the server will run the script in. Then the $snmprw variable must contain your SNMP read-write community string. Please note that the read-only community string will not allow you to copy a configuration fileit must be the read-write string. The other variable you need to change is $ipaddress, which should contain the IP address of your TFTP server.
The script is written in Perl, and it makes a few system calls out to Bourne Shell commands. The script expects to find the Perl executable in the /usr/local/bin directory. The script is also dependent on NET-SNMP, and it expects to find the executable snmpset in the /usr/local/bin directory as well. If these files are in different locations on your local system, you will need to modify these paths. For more information on Perl or NET-SNMP, please see Appendix A.
Finally, you will need a file called RTR_LIST that contains the list of router names. This file must be in the working directory.
As we mentioned earlier, you should run this backup script should from the Unix cron utility on a nightly basis. This will ensure that you have an up-to-date backup of your configuration files. We recommend launching this script during off hours, since it does generate traffic across your network, as well as a small amount of CPU loading on the routers, although neither of these should be large. Here is an example crontab entry to start the script every night at 1:30AM.
30 1 * * * /home/cisco/bkup/backup.pl
When the script runs, it will create a new directory, called storage, under the working directory. Under this directory, the script will create several subdirectories, including LATEST, PREV, and dated directory names, such as 2003_01_28. The directory LATEST will always contain the most up-to-date router configuration files. And you can find the previous stored version of each router's configuration in the directory called PREV. The dated directories will contain all of the router configuration files that were captured on the date indicated in the directory name.
You can use the Unix diff command to see what changes have occurred on a given router.
Finally, the script will create a nightly status report that it stores in a file called RESULT in the working directory:
Freebsd% cat RESULT
Router Configuration Backup Report for 2003/1/28
======================================================
Device Name Status
======================================================
toronto ok
boston not ok
test ok
frame ok
With slight modification, you can configure the script to email this report to the responsible engineer. However, since each different Unix flavor uses a different mail program, we chose not to include it here in the interest of compatibility. On a Solaris server, for example, you could add the following line to the bottom of the script to mail this report:
system ("/usr/ucb/mail -s \"Config Report for $today1\" \Q/bin/cat $mail\Q < $workingdir/RESULT");
In this case, you would need to define the variable $mail to be email distribution list for the report. For other Unix or Linux variants, please consult you man pages for more information on your local mail program.