Have you ever made a configuration mistake and immediately wished you could take it back as you lost access to the remote device you were just configuring?
This is where commit confirmed comes into play. It works just like a normal commit, but if you don’t perform a second commit within the specified timeframe the device automatically rolls back to the previous configuration.
You can specify the number of minutes the commit confirmed should wait before rolling back.
Let’s look at an example where we let it timeout and automatically rollback. First, we see the config for the ge-0/0/3 interface. We delete that config and use commit confirmed, setting the timeout to 2 minutes. After the commit is done, we exit and show the ge-0/0/3 configuration is gone. We then see the automatic rollback and confirm the interface configuration is back.
lab@vMX-1> show configuration interfaces ge-0/0/3
description Super-Important-Interface-Description;
unit 0 {
family inet;
}
lab@vMX-1> configure
Entering configuration mode
[edit]
lab@vMX-1# delete interfaces ge-0/0/3
[edit]
lab@vMX-1# commit confirmed 2
commit confirmed will be automatically rolled back in 2 minutes unless confirmed
commit complete
# commit confirmed will be rolled back in 2 minutes
[edit]
lab@vMX-1# quit
Exiting configuration mode
# commit confirmed will be rolled back in 2 minutes
lab@vMX-1> show configuration interfaces ge-0/0/3
# commit confirmed will be rolled back in 2 minutes
Broadcast Message from root@vMX-1
(no tty) at 5:59 UTC...
Commit was not confirmed; automatic rollback complete.
lab@vMX-1> show configuration interfaces ge-0/0/3
description Super-Important-Interface-Description;
unit 0 {
family inet;
}
lab@vMX-1> Why Is Commit Confirmed So Important?
When starting out in the networking field, it can be hard to see why a command like this is so important. Often we’re used to lab equipment sitting on the desk next to us, or a room down the hall. Maybe you’re used to a campus environment where you can simply walk over to the next building to reset a device or console onto it.
Most network engineers, however, are dealing with devices located around the country or even around the world. Whether that is in a data center overseas or halfway up a hillside, it isn’t practical to simply wander over with a console cable and fix a config mistake.
Commit confirmed is there to help you recover gracefully when you make a mistake and lose access to your device.
How To Use Commit Confirmed Wrong
Something I have often seen is people using commit confirmed like this:
- Make a configuration change
- Use commit confirmed
- Smack enter key to make sure the device is still reachable
- Immediately run a second commit to confirm the change
The gap between the commit confirmed and the second commit is made within a few seconds of the first commit completing.
So what’s wrong with this approach? Clearly, the device is still accessible if we could run the second commit.
The problem is that not everything fails immediately. Some things take time to figure out they’ve been broken, then they cause a problem.
Think about a scenario where a device is managed in-band, and advertises a route for its management address to an upstream router via BGP. You make a change that breaks BGP traffic, but it takes a minute or two for BGP to notice and withdraw the route. By the time access is broken, you’ve already made the second commit.
Now, you could argue that the BGP session would time out faster if it had BFD enabled, but not every session does.
The way to avoid this problem is to make it a practice to always wait a few minutes before confirming a commit, to allow protocols to notice and timeout if you’ve broken them.
Do I Have To Use Commit Confirmed Every Time?
There are two ways of looking at this question.
The first is to say yes because it instills the behavior into the network engineer. It becomes muscle memory to run the commit confirmed command, which makes it more likely to be run in situations of stress. Stressful situations are the ones where mistakes are more likely to be made.
The second is to say no. Some changes you make are so unlikely to cause an issue that commit confirmed isn’t needed. Changing an interface description for example.
In essence, it comes down to deciding whether the change will potentially cut you off from the device or not.
Can I Force People To Use Commit Confirmed?
Based on the quick testing I have done, yes, you can force people to use commit confirmed.
This can be done by setting up a new user class that denies commit commands and allows commit confirmed and commit check commands. In this case, we have given permissions all, while in a real situation, I would be more selective. The user is then assigned our new class. Here is the configuration for user1:
system {
login {
class my-class {
permissions all;
allow-commands "(commit confirmed *)|(commit check)";
deny-commands "commit *";
}
user user1 {
uid 2001;
class my-class;
authentication {
encrypted-password "PASSWORD HASH REMOVED"; ## SECRET-DATA
}
}
}
}The end user then sees this behavior when logged in:
- Show there is no config for ge-0/0/3
- Enter configuration mode and set a description for ge-0/0/3
- Try to run the ‘commit’ command, but that is prevented
- Run a commit confirmed 2 to commit the config
- Run a commit check to confirm the commit. Note that running the commit confirmed again restarts the timer, so we need another commit command for the confirmation.
- Exit configuration mode, wait two minutes, and show that the description for ge-0/0/3 remains.
user1@vMX-1> show configuration interfaces ge-0/0/3
user1@vMX-1> edit
Entering configuration mode
[edit]
user1@vMX-1# ... description Super-Important-Interface
[edit]
user1@vMX-1# show | compare
[edit interfaces]
+ ge-0/0/3 {
+ description Super-Important-Interface;
+ }
[edit]
user1@vMX-1# commit
^
missing argument.
[edit]
user1@vMX-1# commit ?
Possible completions:
check Check correctness of syntax; do not apply changes
confirmed Automatically rollback if not confirmed
[edit]
user1@vMX-1# commit confirmed ?
Possible completions:
<[Enter]> Execute this command
<timeout> Number of minutes until automatic rollback (1..65535)
and-quit Quit configuration mode if commit succeeds
comment Message to write to commit log
no-synchronize Don't synchronize commit
peers-synchronize Synchronize commit on remote peers
synchronize Synchronize commit on both routing engines
| Pipe through a command
[edit]
user1@vMX-1# commit confirmed 2
commit confirmed will be automatically rolled back in 2 minutes unless confirmed
commit complete
# commit confirmed will be rolled back in 2 minutes
[edit]
user1@vMX-1#
# commit confirmed will be rolled back in 2 minutes
[edit]
user1@vMX-1#
# commit confirmed will be rolled back in 2 minutes
[edit]
user1@vMX-1# commit check
configuration check succeeds
[edit]
user1@vMX-1# exit
Exiting configuration mode
user1@vMX-1>
user1@vMX-1> show configuration interfaces ge-0/0/3
description Super-Important-Interface;
user1@vMX-1>An enhancement is to combine this with RADIUS authentication for CLI users, where only a role account and the login class are defined on the device, and the user accounts are authenticated via RADIUS.
Whilst you can force most of your network engineers to use the commit confirmed command, I recommend having at least some users, or a couple of ‘emergency’ accounts that are unrestricted. As always, test this won’t break something in your environment before rolling it out.