Configuration management is one of those network management topics people often neglect. It’s not very exciting—but it’s incredibly important.
In this context, the “configuration” of a network device consists of all the commands and settings necessary to set up the functions on that device. If you had to replace the device with a new one, the configuration file contains every piece of information you need to replicate the original device’s functionality.
And that should explain exactly why configuration management so important.
The main purpose of configuration management is to allow you to quickly replace the functionality of a piece of network equipment after a failure. If you don’t have a recent backup of that device, you’ll be starting over from scratch to configure a new device based on whatever scraps of functional documentation you can find.
It’s best if configuration files are backed up in a human readable format to get all of the benefits I’m going to talk about in this article, but some equipment only offers binary configuration files.
Most common network devices like switches, routers, firewalls, and load balancers allow you to download some sort of flat text file that looks like the set of commands you’d type at the command line interface.
This is true of all Cisco routers, switches, and firewalls, for example. HP ProCurve devices are similar. Some other devices like Fortinet firewalls use an XML format for their configuration information.
The text files are the most useful format because you can easily copy them around, store them on file servers, read them, and write scripts that either read them for reporting or create them for mass rollouts.
Backing up network devices
Part of the problem with configuration management is that every different type of network device saves its configuration in a different format. There’s also no standard method for downloading or uploading configuration files.
Historically, the most common protocol for backing up config files was TFTP (Trivial File Transfer Protocol). This protocol has several serious security and reliability problems that make it less than perfect for this type of task, but it’s still in common use.
Most modern network devices offer alternatives such as SSH/SFTP, RCP. and frequently CIFS/SMB. Of these, SFTP is the preferred option because it’s both secure and reliable.
The configuration management system will be some centrally located server that automatically downloads and stores all of your device configurations. In most cases, I recommend doing backups every night, even in networks where the configurations rarely change.
Manual or scripted config backups
There are several ways to trigger a configuration backup. For devices with a command line interface, it’s usually done by having a scripted session that logs into the device using a standard protocol such as SSH. The script issues the appropriate command to copy the configuration back to the central configuration management system.
You’ll need a suitable administrator account on your devices so the script can log into them. This inherently represents a serious security risk. So the security of the central server is important.
Of course, anything you can do with a script, you can do manually. However, with a script you can automate the backups. Then you know they’re being done regularly and you can start to take advantage of some of the other benefits of configuration backups like automatic comparisons.
Using a third party can help with automating backups because it tends to scale better, and will in general have already solved these security problems.
Uses for configuration files
I use network device configuration files for several important things, not just rebuilding a device after a failure.
The first use case is reporting. If the configuration management tool does a comparison between yesterday’s backup and today’s, it can immediately show you all of the devices that changed and exactly what the changes were.
Is somebody making unauthorized changes to your devices? This is the easiest way to see it. And, if you’re using unique per-user login credentials, you can often see who made the change.
You can also see whether a scheduled change didn’t happen.
One of the things that I use a configuration management tool to do is to create bulk changes. Suppose I need to change the administrator passwords on all my devices because somebody has left the organization (or because I think the password might have leaked). The tool is already logging into every device on a scheduled basis, so pushing out changes is an easy capability to add.
Bulk management capability can also be useful for rollouts. For example, I might need to implement a batch of new switches or turn up several new remote sites. I like to use the configuration management server as a central location for this type of thing.
For creating lots of new configuration files in bulk, I will generally create a standard template configuration. Then I’ll do a variable substitution (like a mail merge) in that template for all the locally unique values like IP addresses.
I should note that I’m often uncomfortable with making changes automatically. I worry that something will go wrong during the update, like a syntax error in the configuration file, or maybe an SSH session will hang halfway through loading the changes.
But I can still partially automate configuration updates by automatically generating the change scripts, and then manually cutting and pasting the commands into the remote devices. This way I can immediately see if there’s a problem.
And sometimes, if I have a lot of devices to update, I’ll manually input the changes like this for a few devices until I’m confident that everything is right, then have the tools do the rest automatically.
Auditing and reviewing configurations
When I’m asked to look at a network that’s having stability problems or might just be in need of updates, one of the first things I ask for is a set of all the configurations.
If they don’t have a recent set of configurations, the first thing I do is log into all of the devices and download them.
The configuration files don’t tell you everything. They won’t show you dynamic information like ARP tables or interface error counts or whether the CPU is running high or the memory is running low. But they do give you an incredibly useful snapshot to start with.
The information is also useful for things like security audits. They show the exact firewall rules, VPN parameters, and how the IDS/IPS inspects traffic.