In Cisco land, we have all learned that when making changes to a remote router, you have to be ready for anything. Most admins that I know start any changes with the command:
Reload in X ( x=time in minutes to make and test changes)
The idea being that if a command is made incorrectly, and the remote router stops responding, it will reload itself in X minutes, and become accessible again since the changes would not have been saved. It’s a good idea to do this, and it’s saved my butt a few times.
However, it’s not the most elegant solution. If the router is a production level router, and the change that made the terminal unresponsive hasn’t affected it’s ability to route, it’s still going to reboot. Clients will figure out that you screwed up while they wait for the router to post, load, rebuild routing tables, etc. Darn those fat fingers, and enter key muscle memory.
Enter Juniper’s Commit Confirmed X command.
As some of you may know, changes in JunOS aren’t applied to the running config until they have been committed. (ANOTHER great idea.) Thus, it is easy to check, and recheck your changes without losing your session because the commands have yet to be applied. Once they are committed, they are all applied at once.
Now, I know what you are thinking. If you are able to cue all of your changes, review those changes for errors, and then apply them all at once, you shouldn’t ever need to rollback those changes, right? *Clears throat* Right.
BUT, if you did, somehow miss an important command, or maybe that subnet should have been a /22 instead of a /30, that’s where the Confirmed part of the command comes in. If the router stops responding, the changes are rolled back in X minutes to the previous config. No reloads, no angry emails, no voicemail, and no meetings.
To stop the router from rolling back those changes, simply commit the changes a second time after it is clear everything is working (and before X expires).