More Zonkyness

First of all, please read the disclaimer.

This section is all about maintaining some level of revision control on the configuration file that configures the Cisco router. This is obviously coloured by my prejudices which include using Subversion as a revision control package. You might like this or might not, but you may wish to consider it if you have not encountered something like Subversion before as being able to travel backwards in time through previous versions of your router’s (or anything else) configuration can come in very handy.

You may be thinking that you can do this already with a backup mechanism whereby you can restore previous versions of the configuration from tape, and undoubtedly thinking that in practice you don’t use it. Indeed I have found that even with very convenient access to the restoration mechanism, restoring files from tape is just too much work to do for anything less than serious – certainly trivial questions like “why did we turn on ‘warm-reboot’ and when?’ just don’t get answered. However they can and do get answered when using a revision control mechanism.

There is also the built-in archiving mechanism on the router itself, which is an option. However this option does not quite match Subversion for convenience, features, and indeed efficiency. But if you choose the archiving option, at least use an archive location not on the router itself!

The section on turning on warm rebooting has been moved to a new “tweaks” blog posting.

Copying Configuration Files

To make use of any Unix tools such as Subversion, we need a mechanism to copy files from the Cisco router to the Unix machine (and visa-versa). My chosen method is SSH (and “SCP”) although there are many other possibilities including the traditional option of TFTP. However using something a little less 1980s such as SSH is worth considering.

Before attempting to copy any configuration anywhere, we need a few details :-

1. The name of the server providing the SSH service. In the example below, the server is called “hemp-chocolate” (and is in the same DNS domain as the router).
2. The username on that SSH server which is roocfg in the example below.
3. And finally the password for that user account.

To copy the configuration :-

router#copy startup-config scp://roocfg@hemp-chocolate/router.cfg
Address of name of remote host [cotton]?
Destination username [roocfg]?
Destination filename [router.cfg]?
Writing router.cfg
Password:
! Sink: C0644 3255 router.cfg
3255 bytes copied in 3.400 secs (957 bytes/sec)

Anyone surprised at the use of host names in the command above should be aware that my router quite happily uses the DNS.

There is a chance you may get a “protocol error” when performing that copy. This may be due to the ssh server and client not supporting a common set of ciphers; it seems that Cisco supports a limited set of ciphers. When this interacts with a server that supports a different limited set of ciphers (certain unsupported versions of Solaris), you may have issues. In which case switching to the real openssh software package (see OpenCSW) solves the problem.

Preparing The Repository

The first task is to create the repository – assuming you have already installed Subversion of course! The following instructions assume that the place in the filesystem for all repositories is /repositories.

# svnadmin create /repositories/router-configuration
# chown -R roocfg /repositories/router-configuration

The permissions changes are my way of ensuring that the user:roocfg will be able to use Subversion without permissions problems. There are different ways to handle this, but this one works for me. After creating the repository, the next task is to check out a working copy of the repository which we will use to copy configuration files into.

To do this, we switch to the user:roocfg, check out a working copy, move all of the contents of the new subdirectory into the user’s home directory, and check in the first version of the configuration file.

# su - roocfg
$ svn co file:///repositories/router-configuration
Checked out revision 0.
$ mv router-configuration/.svn .
$ rm -rf router-configuration
$ svn status
?       .bashrc
?       .sh_history
?       router.cfg
?       .subversion
?       .profile
$ svn add router.cfg
A         router.cfg
$ svn commit

The commit command drops you into an editor to write details of what you are committing. These details are important for future reference in the sense they describe the change you are making. Subversion can show you the actual differences between two different versions; the log entry that you write when committing a change tells you why the change was made – or perhaps logs a change control system ticket to refer back to.

At this point we can commit a change to the Subversion repository by :-

1. Copying the configuration to the repository server.
2. Logging into that account and committing a new version to the repository with an appropriate comment.

This is of course a manual process so is not ideal. When it should be done is up to you, but during pre-production, it is useful to commit a change at every significant milestone … but not every tiny tweak. Whereas in production, every change should be committed so it can be reverted.

Final Word

Not!

There is plenty more that could be done here, which I may return to in the future.

1. It would be nice if the router were to automatically copy the configuration to the repository server in case someone forgets to perform the manual process. If the repository were reachable via TFTP, this could be setup with the router’s Kron facility, but a different method will be necessary for an SCP reachable repository.
2. We need to be able to use the contents of the repository to configure the router. This is possible in various ways, but which one works best ?