The configure replace command is a very neat feature which can save a lot of time during lab sessions. When I started doing some home grown labs I used to waste a lot of time getting the gear ready. All I wanted was to set all devices to a blank or to a particular base line configuration I had saved in flash so I could do some magic.
The reset process involved copying the required config file into startup-config, normally from flash, and then reloading the device. If I was working through a particular workbook lab for instance I would also copy and paste the desired pre-configuration provided for a given set of tasks as well–where I didn’t have the required configuration saved in flash already of course. Now imagine doing that to another 10 devices. Literally. Sounds familiar? Well, this was my world not long ago. It’s kinda fun at first, but it gets tedious after a while. More importantly soon enough you’ll realise that a good chunk of your studying time is being spent on getting the stage ready for the show which obviously isn’t as much fun as rocking it!
The current process I use if I want to make a base or any other config for that matter active whilst removing all the previous configuration is through the use of an exec alias I’ve called rollback. Here’s the syntax:
alias exec rollback configure replace nvram:startup-config force
Once in place, all you have to do is to copy whatever config you want into startup-config then type rollback. The device will then be “refreshed” to whatever the startup-config happens to be.
One thing to keep in mind though is that the configuration you’ve just “rolled back to” might not have the same alias set up which means you wont’ be able to re-use it again until obviously you add it again. For that reason, I would recommend adding it to every configuration you have saved so when you need it’s just there. Make it part of your base config.
In addition, I’ve experienced issues when rolling back some of the switches depending on the current existing configuration- for example when I did a roll-back a routed interface stayed where the rest of the config was cleared. So, if you’re working on a lab for the switches at least I would recommended the long way. That is, copy base config to startup, delete vlan.dat, reload it, copy lab pre-configuration then save it… In that way you know the configuration will be “fresh.” Nonetheless you should always verify your current config and setup before attempting any task in order to spot any possible issues early on. The last thing you want is to be half way through a particular task and then realise that you’re config looks odd and that your base addressing doesn’t match your rack number for instance. No proctor will give you an hour extra over something you should have spotted in a few minutes into the lab.
Of course an easier way to have your entire lab devices ready would be to one or more scripts to handle it. However, I doubt you’ll have access to a shell or any scripting interpreter for that matter during your lab. Even if you could pull some magic via TCL and risk using one of the routers… Would you have time for that?