How many times have you locked yourself out of your device? In my professional career, this happened to me several times when I was either configuring AAA or making any routing related changes. Usually, the reason for this is the human error associated with invalid configuration. Some vendors offer a commit model that allows you to apply the configuration and then save it to the system by committing the change. As we know not all vendors offer the commit model approach and when a change is introduced in the system, such a change is pushed immediately. This approach means that sometimes, as a result of an erroneous change, we may lose access to the device, create loops, shutdown the interface we didn’t want, etc. In such a situation, we often have to use the console to gain access back to the device, if we have one, in the worst case, if the configuration has not been saved to the device, we can ask someone who has physical access to the device to reboot the device.

If the wrong configuration of a given device has a big impact on the network environment, there is usually a lot of pressure from business to bring the environment back to its previous state as soon as possible. We know that sometimes this is not possible because of losing an access. Errors happen to everyone, and this is a natural thing but what can we do to minimize such errors, and even if it happens, what can we do to quickly restore device configurations to the state before the change was made?

What if the committed change causes a problem and for example we lost access to the device? Arista offers additional functionality that allows you to control commit change using commit timer, which requires the user to commit the change within a specific time. If the change is not confirmed within a specified time by issuing the commit command, the change will be rolled back and the previous configuration will be restored automatically. This approach gives us additional security against human error and the ability to verify the network state after the committed change. If change is successfully, the user has to commit the change, otherwise it will be reverse.

Let’s take a look at the Arista switch configuration session. This feature provides really cool stuff. Below I showed how to create a configuration session. In this example, I am going to put the management interface to its default configuration and then run show session-config diffs to see what exactly will be removed when the change will be committed. This command compares the running configuration with the configuration session template and displays the differences.

As you can see all config entries with- sign will be removed as soon as committed the change. In this example, only the IP address will be removed.

eaf1-dc1(config)#configure session TEST
leaf1-dc1(config-s-TEST)#default interface management 1
leaf1-dc1(config-s-TEST)#show session-config diffs 
--- system:/running-config
+++ session:/TEST-session-config
@@ -147,7 +147,6 @@
    ip address 11.11.11.111/32
 !
 interface Management1
-   ip address 10.10.1.203/24
 !
 interface Vlan100
    vrf forwarding A

leaf1-dc1(config-s-TEST)#

Before making the change, let’s see some details about the configuration session. We can see that only the TEST session is configured and is in a pending state, which means that it has not yet been committed.

leaf1-dc1(config-s-TEST)#show configuration sessions detail
Maximum number of completed sessions: 1
Maximum number of pending sessions: 5

  Name   State        User       Terminal       PID    Commit Time Left 
  ---- ------------ ---------- ------------- --------- ---------------- 
* TEST   pending      admin      con0          2928                     

Now commit the change with the commit timer 00:00:15, so if I don’t run an explicit commit command within 10 seconds, the change will be rolled back. In addition, I intend to run ICMP to the IP management address to show what will happen when the configuration is applied and rollback occurs after a certain time.

leaf1-dc1(config-s-TEST)#commit timer 00:00:15

Checking the configuration of management interface you can see its in default config and IP address was removed.

leaf1-dc1#sh run int management 1
interface Management1
leaf1-dc1#

Running ICMP at the same time shows that I lost management access to the switch.

However because I did not applied commit command explicitly this change was rollback after 15 second which is indicated by system log shown below and I gain access to the switch again.

leaf1-dc1#Feb 29 11:36:45 leaf1-dc1 ConfigAgent: %SYS-3-CONFIG_SESSION_COMMIT_TIMER_TIMEDOUT: The commit timer on session TEST has expired.The system configuration will be rolled back.

leaf1-dc1#

If I were happy with that change outcome and it met my expectation I would have to applied commit command within 15 seconds. In real life scenario probably you will allocate more time for rollback to perform more sanity checks if required.

This feature is unusually cool, and I appreciate it because is straightforward to use and can miraculously prevent a potential headache. If you are, carry out an extensive modification that can naturally produce a significant impact on the environment, you ought to consider using the commit timer functionality. This notable feature can allocate a proper time to promptly examine the state of the network after implementing the change. If something went amiss and there is a problem that affects your environment, in a convenient way it can automatically reverse the change. This is extremely valuable if you have to made change to dozens or hundreds of devices at the same time.