Transaction based CLI on Ethernet Switches

Question

I am familiar with CLI on managed Ethernet switches. However, recently I came across a term 'transaction based CLI' on switches. I am not exactly sure what is that and purpose of having it in switches. Is it similar to database transactions where you can unroll the entire commands before committing them?

Edit:

As requested:

RX5000 Data Sheet

Checkpoint CLI transactions

Answer 1

I am familiar with CLI on managed Ethernet switches. However, recently I came across a term 'transaction based CLI' on switches. I am not exactly sure what is that and purpose of having it in switches. Is it similar to database transactions where you can unroll the entire commands before committing them?

• The RX5000 is speaking of the ability to revert changes incrementally, like you can in a database.
• The Checkpoint link you mentioned alludes to the same thing, but they specify that discrete configuration commands can be grouped together into a single "commit" action.

Cisco CLI transactions with config archive, and rollback

These capabilities are very similar to what you find elsewhere in the industry... for instance on a Cisco router, you can commit changes in reversible transactions, if you have archive enabled in the Cisco's running configuration.

SW1#sh runn | b archive
archive
 path bootflash:$h_config
!
SW1#term exec prompt time
SW1#archive config

SW1#dir bootflash:
Directory of bootflash:/

   21  -rw-       52770   Nov 3 2013 12:48:04 -06:00  SW1_config-Nov--3-12-48-02-CST-1
   20  -rw-       52770   Nov 3 2013 12:45:02 -06:00  SW1_config-Nov--3-12-45-00-CST-0
   22  -rw-       52762   Nov 3 2013 12:52:22 -06:00  SW1_config-Nov--3-12-52-20-CST-0
   23  -rw-       52762   Nov 3 2013 14:38:44 -06:00  SW1_config-Nov--3-14-38-41-CST-1
   26  -rw-       66622  Jan 31 2014 13:17:46 -06:00  SW1_configJan-31-13-17-42-CST-2  <---

131436544 bytes total (95956992 bytes free)
SW1#

There isn't a Loopback100 configured right now...

SW1#sh runn int lo100
                  ^
% Invalid input detected at '^' marker.

SW1#

Example CLI transaction configure and confirm

Let's configure Loopback100 with a 10-minute rollback timer, look at our changes since the config snapshot, confirm the changes, and then roll back. If the rollback timer expires without confirming the config, it will automatically revert to our last config archive (which also happens when you perform config terminal revert).

These transactions are valuable, because if you completely hose your router's config to the point that it's unreachable, it will automatically roll back to your saved snapshot... it also helps if you can manage the router but need to rollback to a known-good config in a hurry.

SW1#configure terminal revert timer 10
Rollback Confirmed Change: Backing up current running config 
 to bootflash:SW1_configJan-31-13-20-21-CST-3

Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#
SW1(config)#int loopback 100
SW1(config-if)#ip address 1.2.3.4 255.255.255.255
SW1(config-if)#end
SW1#

We can see that Looback100 exists...

SW1#sh runn int lo100
Load for five secs: 28%/0%; one minute: 24%; five minutes: 24%
Time source is NTP, 13:21:25.243 CST Fri Jan 31 2014

Building configuration...

Current configuration : 65 bytes
!
interface Loopback100
 ip address 1.2.3.4 255.255.255.255
end

SW1#

We can see the diffs required to rollback to the last config archive...

SW1#sh archive config differences bootflash:SW1_configJan-31-13-17-42-CST-2
Load for five secs: 17%/0%; one minute: 24%; five minutes: 23%
Time source is NTP, 13:25:55.832 CST Fri Jan 31 2014
!
!Contextual Config Diffs:
-interface Loopback100
 -ip address 1.2.3.4 255.255.255.255

SW1#

Now we can confirm the commit... this means we don't automatically rollback if the 10-minute timer expires.

SW1#configure confirm
SW1#sh runn int loo100
Load for five secs: 25%/0%; one minute: 25%; five minutes: 24%
Time source is NTP, 13:30:17.269 CST Fri Jan 31 2014

Building configuration...

Current configuration : 65 bytes
!
interface Loopback100
 ip address 1.2.3.4 255.255.255.255
end

SW1#

CLI Transaction Rollback

Suppose we find a problem after config confirm. Let's rollback to the old config we archived...

SW1#configure replace bootflash:SW1_configJan-31-13-17-42-CST-2
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: yes
Total number of passes: 1
Rollback Done

SW1#

Now Loopback100 doesn't exist in the running configuration. The configuration is exactly the way it was when we took our first snapshot.

SW1#sh runn int lo100
                  ^
% Invalid input detected at '^' marker.

SW1#

When a rollback occurs, the configuration is locked from any other config activity. In case of a bug, or some unpredictable event it's a good idea to have configuration mode exclusive auto expire [timeout-in-seconds] in your config when using this feature. I like the max timeout value of 600 seconds... this means the maximum time the configuration can be locked is 10 minutes.

Historical note

Originally, Juniper was the first major vendor to deploy config rollback features. I worked for Cisco at the time, and our sales accounts were screaming for this feature in Cisco IOS. I still remember internal edicts from significant players in the company, who said "it's impossible in Cisco IOS".

Of course, with enough persistence (and a couple of years in the middle) we have it in IOS... the point is, don't assume the first "no, we can't do that" really is correct.

Answer 2

Your assumption is correct. In both these cases, you can rollback configuration commands to a known point if they don't work as expected.