Jan 092011
 

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 ?
Jan 052011
 

Please read the disclaimer before continuing …

Once the basics of my router were up and running, I wanted to ensure that my wireless network could be served by a DHCP server. This is complicated by the fact that :-

  1. My wireless network is a separate network.
  2. I use a Unix-based DHCP server (partially because I’m very familiar with it).

The first thing to do is to configure a “helper address” on the wireless interface – in this case the vlan that incorporates the wireless network :-

interface Vlan102
...
ip helper-address 10.0.0.21
...

You can configure more than one helper address in here, which may be useful for debugging purposes – or in a production environment you may wish to run a failover dhcp server.

In theory, this should send all broadcast DHCP packets onto the specified network address. However it also forwards other UDP broadcast traffic onto that host which may not be what we want. Specifically for a DHCP server we don’t want DNS, TFTP, etc. These other protocols can be excluded with (at the global level) :-

no ip forward-protocol udp tftp
no ip forward-protocol udp domain
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs

Using the ‘symbolic’ names for the protocols aids the readability of the configuration file.

At which point the instinct is to fire up the dhcp server and see if it works. Very natural of course, but I would suggest that sniffing the traffic to check that the relevant packets are being forwarded is wise at this point. Or you are risking testing two things at once – the packet forwarding and the dhcp server. Despite being very experienced with DHCP servers, it turned out that my main problem in setting this all up was a faulty DHCP server!

After fixing that problem, my newly configured wireless network worked fine.

Some additional configuration that may be worth trying :-

  • ip dhcp relay prefer known-good-server – The explanation for this on the command line is somewhat mysterious, but the documentation indicates that with this turned on, the DHCP clients will need to renew their leases less frequently. How this works, I don’t know.
  • ip dhcp relay information option – This inserts information about the relay agent (the router) into “option 82”. This additional information can be logged which can be useful.
Jan 052011
 

Firstly I will point out that this series of blog entries has nothing to do with Apple’s OSX operating system build for the iPhone retrospectively named iOS; these are about a far older operating system from Cisco that runs on most of their routers and switches – IOS. They are intended as ‘aide memoires’ for myself – a crusty old Unix geek who wanted to find out about this IOS stuff when he finally got sick and tired of consumer grade routers.

The router I’m using for all of this is a Cisco 881W running IOS version 15. This is a ridiculously overpowered router for a domestic broadband connection, but it does have lots of interesting stuff to play with.

Now to the disclaimer part – I’m no CCIE; I’m a Unix geek and whilst I have considerable experience with networking, it has all been with networking services such as DNS and DHCP. So anything you find here could well be done better in a different way. Or perhaps I’ve encountered a feature that shouldn’t be used just yet, or perhaps I’ve found something in my ignorance that could actually be useful!