Comparing Cisco and Juniper – Why doesn’t Cisco do this?

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).

Advertisements

2 thoughts on “Comparing Cisco and Juniper – Why doesn’t Cisco do this?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s