Take the 2-minute tour ×
Network Engineering Stack Exchange is a question and answer site for network engineers. It's 100% free, no registration required.

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

share|improve this question

2 Answers 2

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.

share|improve this answer
    
Thanks for the example. One thing was not clear to me...Does the changes (in this case the loopback) get activated immediately as soon as you type the commands or do they get activated once you confirm the transactions (configure confirm). –  modest Jan 31 at 21:48
    
@modest, Cisco applies the commands immediately; when you do a config confirm, you're just telling the router that you do not want to roll those changes back automatically. Of course, it's entirely possible to make changes without timed rollback. Either way, the commands are immediately active. –  Mike Pennington Jan 31 at 21:52

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

share|improve this answer
    
Understood. However, you can achieve the effect by simply loading the previous configuration file (assuming you save it before you start making changes) in case if things go bad. Am I missing something here? –  modest Jan 31 at 19:41
    
@modest Reloading the previous config will not remove commands that require "no <cmd>". For example, if you apply an access list to an interface with the command "ip access-group 100 in" and then type "copy start run" to reload the config, that will not remove the access list. –  Ron Jan 31 at 20:00
    
The other thing this feature does (at least on Cisco and Juniper) is allow you to set a rollback timer. When the timer expires, the configuration will roll back by itself. This is useful if you've made some change that causes you to lose commectivity to the device. Not that I've ever done that :( –  Ron Jan 31 at 20:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.