Automating IOS Configuration Archival on the Cheap Using Archive and FTP

One of the challenges of managing network infrastructure devices is maintaining a library of historical device configurations. You might think, “Maintain a library of old configs? Who cares? I make a change, I copy run start, and I’m done. Who cares about old configs?”

Yeah, so apparently you’re the most interesting network engineer in the world. (Have we beat this meme to death yet? I’m trying, I’m trying…) You don’t always test your code, but when you do, you do it in production. And – it would seem – without a safety net. Hey, Captain Interesting – what are you going to do when your masterfully-written-yet-untested change goes wrong? When you include too many interfaces in a range statement? When your paste buffer overruns and your code hits the switch with some important text missing? When you have 8 device CLIs open and paste into the wrong one? When you just screw up, plain and simple? Never happen? All this has happened before, and all this will happen again. To you. Probably today.

One handy bail out plan for an IOS device change fail is to have a backup copy of the device configuration. How do you get a config copy before embarking on your change to end all changes?

• You could do a “term len 0″ followed by “show run” while outputting to a text file. Or if not output to a text file, at least scroll back, highlight the config from your buffer, paste into a text editor, and save. It works, but you score zero style points. Really manual, really tedious, really annoying on multi-hundred line chassis switch configs, and probably the first thing you’re going to skip because when you’re ready to make a change, then you’re ready.
• You could buy a tool that collects your configs for you, and probably does a bunch of other config related stuff too. They work, but…you know. They cost money. You have to set them up. They’re really aimed at big shops. And some weenie is going to call you once a year for maintenance renewal. Sigh.
• You could…oh, there’s other hacktastic ways. You get the idea.
• OR! You could throw up an FTP server (tons of them out there for free, I like FileZilla) and set up IOS to copy its config to the FTP server on a timed interval, and/or every time you write mem. Oooo. Now we’re talking. Cheap AND effective.

For IOS versions that support it, the code is really simple. Take a look at this example:

 archive
  path ftp://username:password@10.100.200.10/MYSWITCH-config-
  write-memory
  time-period 1440
  exit

Line by line, here’s what’s happening:

• The keyword “archive” takes you into the “archive” subparagraph.
• The “path” is the destination the IOS device is going to send the configuration to. In my example, I set up an FTP URL in a standard format that embeds the username, password, and the destination IP of my FTP server. You can use a hostname instead of an IP if you’ve configured the device to resolve hostnames via the “ip name-server” command. The “MYSWITCH-config-” section is the part of the filename that will be prepended to a serial number at the end, which is usually a timestamp, but varies by IOS version. You should replace “MYSWITCH” with the hostname of the device who’s config you’re backing up.
• The “write-memory” directive tells the archive process to write a copy of the config every time you do a “copy run start” or “write memory” at the console.
• “Time-period 1440″ means that every 1440 minutes (once a day), the switch will auto-write another config to the FTP server. It doesn’t appear that you can schedule this to be at a specific time of day.

So, you blew up a Cisco box? Well, now you can go to your FTP server, take a look at the last config that was saved, and put the lava back in the volcano.

There’s other functionality available within the IOS archive tool, including saving a limited number of archived configurations to flash instead of off-box (I prefer off-box generally speaking, although saving to flash has advantages depending on just how badly you hosed the box), and rolling back configurations.

Take a look here for more deatiled information from Cisco on “Configuration Replace and Configuration Rollback”.

P.S. Yeah, I know. Juniper rocks. We get it.