Homebrew NMS: Manage and Configure Network Devices

When a network scales past a certain number of devices, it becomes extremely time consuming to login to each device manually. A simple password change could take all day to complete, not to mention the impending carpal tunnel. There must be a better way. As part of our ideal NMS, we’d like to be able to manage our network devices—a capability that large NMS solutions never provide.

Cisco would have us use their CiscoWorks product to automatically push changes to all devices at once, but there are also free ways to do the same. We’re tempted to say "SNMP!" at first glance, but you cannot manage every aspect of a switch or router configuration via SNMP MIBs. CiscoWorks does use SNMP to make this happen, but in a much more creative way. (We provided an SNMP primer and explanation of Perl’s Net::SNMP in a previous Homebrew NMS article.

The security-conscious will not want to use this method, but here’s how the Cisco product works, you can do the same.

TFTP and SNMP

The TFTP+SNMP method requires that you first set up a TFTP server. The Trivial File Transfer Protocol is a quick and dirty service that allows you to host files for both reading and writing. It is not secure by any stretch of the imagination. Many argue that your management network should not be accessible to more than a few "management stations," but security has to be done in layers. One cracked layer should not provide an attacker full, unfettered access to your most precious jewels.

Once TFTP is configured, and all your configuration files are stored with the correct permissions, you’re ready to do two things. First, a bit off-topic, you can use TFTP as a backup location for your configuration files. Just create an alias in IOS to write the config to the TFTP address, and it can be copied there whenever you make a change on the device. Second, the usage we’re talking about, is that you can read in the configuration file from the TFTP server.

In IOS, you can merge configurations by using the copy command to overwrite the existing config. The same concept applies, but via SNMP. Using a special snmpset command, once the SNMP options are set up properly, you can instruct your device to merge in a new configuration. Details are available on Cisco’s Web site, which also explains the CISCO-COPY-CONFIGURATION-MIB.

The SNMP triggered TFTP copy method does not work with catalyst devices, unfortunately. It certainly is a nice way to push out large configuration changes. Just edit the config files on the TFTP server, and run a script that does an snmpset for each network device.

Expect and other types of Scripting

Devolving a bit from the last example, a more brute-force method is to simply script the login and commands you wish to run. The Expect tool is ideal for this, but you could also use something like the Perl Net::Telnet module. It isn’t possible to script a Cisco console login with a shell script, because you need to be able to provide input to multiple prompts.

Expect is extremely simple to use. An Expect script requires that you provide what you expect to see, and what you’d like to say in response. For example, if you run, ‘ssh switch_hostname’ and expect to be presented with a login prompt, the Expect script must give the text that you expect to see. Then the script needs to provide a password, and handle more output, and so on. Simple, indeed, but not very maintainable.

RANCID

RANCID, or Really Awesome New Cisco confIg Differ, is a tool that allows you to keep track of Cisco configuration changes. RANCID also comes with a program called clogin which can be used to automatically login to all your devices and run arbitrary commands. The clogin command is certainly a suitable replacement for a hand crafted Expect script.

RANCID also fulfills another NMS need: storing a history of device configuration changes. The clogin program is normally used by RANCID itself, to login and extract configuration data from all your network devices. The configurations, if changed, are stored in a revision control system such as SVN. An old Unix command diff is used to compare the contents of two text files, hence RANCID is a "Cisco config differ." Despite the name, RANCID supports most popular network devices, not just Cisco products.

Most non-CiscoWorks sites us a combination of tools. In lieu of RANCID, I’ve even seen some people copy configs to a TFTP server, and then run an RCS check-in script nightly to get some semblance of revision control going. Whatever the method, it is absolutely imperative that you be able to track configuration change. Heck, because of the lack of tools that certain vendors provide, many sites are still without configuration backups at all. After the first lost configuration due to hardware failure, people do generally configure a TFTP server to write configs to.

Even still, there’s no easy way to backout a change based on revision control data, but it wouldn’t be difficult to script, given the tools we’ve talked about today. Either use clogin to reverse the commands, if it’s a trivial change, or revert the working revision control copy (in the TFTP directory) to the desired configuration, and use snmpset to apply that configuration.

It’s not nearly as refined as Unix configuration management tools, but it wouldn’t take much to add network device support to these systems. The end result is the same: avoid logging in to each device manually to make configuration changes that get applied to many devices at once.

The benefits of automation are nearly endless, and utilizing these tools means that network devices can be managed in a sane fashion, without purchasing yet another product.