11-16-2012 05:20 AM
Hi,
I've seen posts where people say you should use the archive command instead of EEM for backing up configs but, I don't see an option for doing this when a config change is made:
Archive configuration commands:
default Set a command to its defaults
exit Exit from archive configuration mode
log Logging commands
maximum maximum number of backup copies
no Negate a command or set its defaults
path path for backups
rollback Rollback parameters
time-period Period of time in minutes to automatically archive the
running-config
write-memory Enable automatic backup generation during write memory
I want to write an EEM script that will issue a "write mem" everytime a change is made to a device. Is there a way to do this silently so, the person on the console doesn't see the command "write mem" issued and the the tranfer of the SCP file to the SCP server?
I think this would get annoying to see everytime you made a change - especially when you are making changes to switchports.
Thanks, Pat.
11-23-2012 04:46 PM
No, the config archive feature doesn't support persisting each change when they are made. That could be dangerous. If a bad change is made such that the device reloads (but enough time is given to save the change), then the router may enter a reboot loop.
However, if you're sure you want to do this, then EEM can do it by reacting the SYS-5-CONFIG_I syslog message, or the PARSER-5-CFGLOG_LOGGEDCMD syslog message (generated by the archive feature).
11-24-2012 09:14 AM
Joseph,
what I have done is backup the config each time someone does a write mem and also once a day (1440) minutes. This is probably insurance enough that we are saving changes.
I don't quite follow what you mean by "If a bad change is made such that the device reloads (but enough time is given to save the change), then the router may enter a reboot loop."
could you provide an example?
Thanks, Pat.
11-24-2012 02:24 PM
What you describe is fully doable with config archive. The config change I meant was more of an idea than something specific. If you encounter a bug that could trigger a crash, you may commit the change before the device crashes. Then this could trigger a reload loop.
A more probable example could be a change that locks you out of the device (maybe if the device is remote). If the change is persisted, then a reload wouldn't recover. In that case, you'd have to have someone onsite to fix the problem.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide