NXOS process for reverting running-config to archive after idle timer

[vv0bbLeS]

Hello all,

On Cisco IOS, the archive command and rollback procedure seem well documented and straight-forward, and I can even set an idle timer such that after a specified amount of time, the config will revert to my last archive-config that was taken. Very convenient safety-net for sure!

However on the NXOS side, I can create config archive files, but I can't figure out how to set an idle timer to have the config rollback to my archive file. What I'm wanting to accomplish on an NXOS box is to take an archive config (i.e. a copy of the current running-config), then set an idle timer such that if I'm idle for that amount of time (i.e. some change I made caused me to lose connection to my NXOS box), the NXOS box will revert the running-configuration back to my last archive config that I took, which should restore my connection (basically a fail-safe in case I lose connection, so instead of having to reboot the NXOS box to restore my last good config, the config will just auto-revert back to my archive-config file).

I've tried to Google this but I'm getting lost in the articles about NXOS Checkpoints and NXOS Rollbacks, and was hoping someone could give me a clear-cut process for this? Thanks!

[jkpawlik]

Good morning.  I hope you found your answer to this.

I found the answer on the following thread:
NEXUS auto configuration rollback - Cisco Community

It is strange because NX-OS let's you go through the process of building the Archive path like you would do on IOS-XE, but then does not have the conf t revert timer idle <#_sec>.

Instead, it seems you have to copy out the running configuration to a scp or sftp server, or even a target in the bootflash.

Once you have the target config file with the desired changes, run config replace <TARGET_PATH> commit-timeout <#_sec>.

This will load the configuration file and give you the number of seconds you specify to validate the configuration changes.  If no action is taken, the configuration will roll back after the specified time.  If you are happy with the configurations, you issue the configuration replace commit command to save the changes.


We ran into this same issue testing some aaa authorization commands.  We made a mistake where authentication fell back to local successfully, but the authorization did not fall back, even when no tacacs servers were reachable.  We had to wipe and replace the configuration file, which was more disruptive than we had hoped.


Hope this helps.  Happy hunting.