Rollback in Cisco IOS XR

Anyone who has ever encountered the need to make changes to the configuration of Cisco equipment running IOS XR knows that, unlike the usual IOS, IOS-XR requires a commit to apply the configuration. But how to commit the config, I think that everyone who has experienced the iOS XR at least once in their lives knows. But how to roll back the config? On JunOS, everything is easy and understandable, which cannot be said about iOS XR. Until a certain time, I did not know this, but one night I had only 5 minutes to learn this, roll back the config and not get an accident. I didn’t find anything in the network except for the manual of Ziska itself in English, so I decided to write a small educational program on this topic, maybe someone could use it.

So let's go ...

Note: although the article is intended for novice engineers, it may be useful for engineers, who are familiar with iOS XR. As they say, live and learn.

To begin with - as an introduction - I will briefly describe the process of applying the configuration on IOS XR to those who are not familiar with it (IOS XR). Suppose that we want to add a descriptor to the config:

RP/0/0/CPU0:RZN-PE4(config)#interface gigabitEthernet 0/0/0/5 description "link to RZN-CE4-SW5" RP/0/0/CPU0:RZN-PE4(config)#show Sun Dec 11 17:11:11.950 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/5 description "link to RZN-CE4-SW5" ! end 

On an ordinary IOS, everything is simple - they added something to the config - the changes were immediately applied. On iOS XR, until we make a commit, the changes will not apply:
')

 RP/0/0/CPU0:RZN-PE4(config)#do sh run int gi0/0/0/5 description Sun Dec 11 17:12:09.346 UTC % No such configuration item(s) 

Make a commit:

 RP/0/0/CPU0:RZN-PE4(config)#commit comment add desc int ge0/0/0/5 Sun Dec 11 17:12:43.443 UTC 

Now everything is in order, the configuration changes have been applied:

 RP/0/0/CPU0:RZN-PE4(config)#do sh run int gi0/0/0/5 description Sun Dec 11 17:12:48.353 UTC interface GigabitEthernet0/0/0/5 description "link to RZN-CE4-SW5" ! end 

As you can see from the above conclusions, I made a comment on the commit. This is very helpful when searching for a configuration to roll back to.

Now let's go directly to the rollbacks themselves. To roll back the configuration, you can use the following command:

 RP/0/0/CPU0:RZN-PE4#rollback configuration ? last Rollback last <n> commits made to Rollback up to (and including) a specific commit to-exclude Rollback up to (and excluding) a specific commit 1000000037 Commit ID 1000000036 Commit ID 1000000035 Commit ID 1000000034 Commit ID 1000000033 Commit ID 1000000032 Commit ID 1000000031 Commit ID 1000000030 Commit ID 1000000029 Commit ID 1000000028 Commit ID 1000000027 Commit ID 1000000026 Commit ID 1000000025 Commit ID 1000000024 Commit ID 1000000023 Commit ID 1000000022 Commit ID 1000000021 Commit ID 1000000020 Commit ID 1000000019 Commit ID 1000000018 Commit ID 

As you can see, the router dumped us a bunch of Commit ID. Unlike Juniper, in which the list of commits starts from 0 and zero commit is the current config, on the IOS XR the commit ID increases with each commit, and the current commit is the one that has the highest ID from the list presented. In our case, 1000000037 is the current configuration. Compared to JunOS, this is a commit with ID 0.

If we need to roll back just one commit - that is, the configuration with ID 1000000036, then everything is simple, you can do this:

 RP/0/0/CPU0:RZN-PE4#rollback configuration last 1 

And in the end we will roll back to the configuration with ID 1000000036.

But if you made more than one commit, or you need to roll back to a specific configuration during the work. How to be here? To do this, you need to look at who commits and when and find the right one:

 RP/0/0/CPU0:RZN-PE4#sh configuration commit list 10 Sun Dec 11 17:17:39.113 UTC SNo. Label/ID User Line Client Time Stamp ~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~ 1 1000000037 bormoglot con0_0_CPU0 CLI Sun Dec 11 17:12:43 2016 2 1000000036 bormoglot con0_0_CPU0 CLI Sun Dec 11 16:55:22 2016 3 1000000035 bormoglot con0_0_CPU0 CLI Sun Dec 11 16:55:07 2016 4 1000000034 bormoglot con0_0_CPU0 CLI Sun Dec 11 16:54:56 2016 5 1000000033 bormoglot con0_0_CPU0 Rollback Sun Dec 11 16:34:08 2016 6 1000000032 bormoglot con0_0_CPU0 CLI Sun Dec 11 16:23:18 2016 7 1000000031 bormoglot con0_0_CPU0 Rollback Sun Dec 11 15:48:11 2016 8 1000000030 bormoglot con0_0_CPU0 CLI Sun Dec 11 15:43:43 2016 9 1000000029 bormoglot con0_0_CPU0 CLI Sun Dec 11 15:32:44 2016 10 1000000028 bormoglot con0_0_CPU0 CLI Sun Dec 11 09:26:59 2016 

Note: the number 10 means how many commits to display, otherwise Tsisk will dump you all commits, which will be redundant information (you are unlikely to make 40-50 commits at a time, although who knows ...). Unlike JunOS, iOS XR saves the last 100 commits.

But in my case, the above output did not really help in finding the desired commit. Not only did I commit only, it’s still impossible to navigate in time to which commit I need to return. And here comments to commits will help us:

 RP/0/0/CPU0:RZN-PE4#sh configuration commit list 5 detail Sun Dec 11 17:20:19.682 UTC 1) CommitId: 1000000037 Label: NONE UserId: bormoglotx Line: con0_0_CPU0 Client: CLI Time: Sun Dec 11 17:12:43 2016 Comment: add desc int ge0/0/0/5 2) CommitId: 1000000036 Label: NONE UserId: bormoglotx Line: con0_0_CPU0 Client: CLI Time: Sun Dec 11 16:55:22 2016 Comment: "descr gi0/0/0/4" 3) CommitId: 1000000035 Label: NONE UserId: bormoglotx Line: con0_0_CPU0 Client: CLI Time: Sun Dec 11 16:55:07 2016 Comment: "descr gi0/0/0/3" 4) CommitId: 1000000034 Label: NONE UserId: bormoglotx Line: con0_0_CPU0 Client: CLI Time: Sun Dec 11 16:54:56 2016 Comment: "descr gi0/0/0/2" 5) CommitId: 1000000033 Label: NONE UserId: bormoglotx Line: con0_0_CPU0 Client: Rollback Time: Sun Dec 11 16:34:08 2016 Comment: no evi2 

Now it's easier, I see my comments on commits and I can understand something about what I added in each of the commits. But the comment does not always reflect all changes in the configuration. And if it is not written by you, then it is generally incomprehensible what is hidden under the described descriptor. To understand what exactly has changed in the config, you need to use the following command:

 RP/0/0/CPU0:RZN-PE4#show configuration commit changes 1000000037 Sun Dec 11 17:22:05.485 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/5 description "link to RZN-CE4-SW5" ! end 

This command displays what exactly was added or removed to the configuration in the specified commit.

Note: in addition to the commit ID, there is a commit number in the order specified in the detailed output:

  1) CommitId: 1000000037 Label: NONE UserId: bormoglotx Line: con0_0_CPU0 Client: CLI Time: Sun Dec 11 17:12:43 2016 Comment: add desc int ge0/0/0/5 

1 is the commit number, and 10,000,00037 is its ID. You can also watch configuration changes or roll back by the commit number, for example:

 RP/0/0/CPU0:RZN-PE4#show configuration commit changes last 1 Sun Dec 11 17:24:19.616 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/5 description "link to RZN-CE4-SW5" ! end 

After last, specify the number of commits to the desired one (the number is equal to the number of the commit). Unlike ID, the commit number is constantly changing (I think it is clear that the commit number is incremented with each commit run)

But the peculiarity of this command is that it shows us exactly the changes that were applied in the specified commit. For example, let's see what has changed in the configuration when working on a commit 1000000036:

 RP/0/0/CPU0:RZN-PE4# RP/0/0/CPU0:RZN-PE4#show configuration commit changes 1000000036 Sun Dec 11 17:25:21.772 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/4 description "link to RZN-CE4-SW4" ! end 

In essence, this conclusion shows us what has changed in commit 1000000036 compared with the previous commit 1000000035. That is, in the JunOS world, the analogue of the show system rollback 2 compare 3 command (the first digit is the configuration that will be displayed, the second digit is the configuration, with which the comparison will be made). The following command works in the same way, but it displays information so to speak “from its bell tower”:

 RP/0/0/CPU0:RZN-PE4#show configuration rollback changes 1000000036 Sun Dec 11 17:27:34.912 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/4 no description "link to RZN-CE4-SW4" ! end 

The command shows that we will cancel if we make a rollback for this commit, but it shows changes within only the specified commit, and not the configuration as a whole. For example, we made 5 commits and now roll back to all 5 commits. This command will show us not the resultant changes when there is a rollback for 5 commits, then only those changes that will be reversed within the specified commit ID, without taking into account all intermediate commits. But after all, the result of applying rolback will be the cancellation not only of the specified commit, but also of all intermediate changes, that is, we need to see a comparison of the current configuration with the configuration that was at the time of the commit specified in the command. That is, if we again draw an analogy with the JunOS world, we need the output of the show system rollback 5 compare 0 command. To do this, use the show configuration commit changes command but with the to or to-exclude keyword:

 RP/0/0/CPU0:RZN-PE4#show configuration rollback changes ? last Changes for rolling back last <n> commits to Changes up to (and including) a specific commit to-exclude Changes up to (and excluding) a specific commit 

Note: the to-exclude keyword appeared in the 5th branch of IOS XR, and then not on all versions. In any case, there is no such command on version 5.1.3, and already in 5.3.3.

With the to keyword, the command will bring you all the changes that will be made to the config as a result of applying the rollback, including the commit specified in the command and all intermediate configuration changes. We look how it works:

 RP/0/0/CPU0:RZN-PE4#show configuration rollback changes to 1000000035 Sun Dec 11 17:32:21.933 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/3 no description "link to RZN-CE4-SW3" ! interface GigabitEthernet0/0/0/4 no description "link to RZN-CE4-SW4" ! interface GigabitEthernet0/0/0/5 no description "link to RZN-CE4-SW5" ! end 

That is, if we apply this rollback, then all changes including changes applied in commit 1000000035 are canceled. In essence, we roll back to the configuration that was before applying the 1000000035 commit, that is, to the configuration with commit ID 1000000034. This becomes clear after viewing Configuration changes made to commit 1000000035:

 RP/0/0/CPU0:RZN-PE4#show configuration commit changes 1000000035 Sun Dec 11 17:34:23.184 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/3 description "link to RZN-CE4-SW3" ! end 

In this commit, a handle was added to the interface GigabitEthernet0 / 0/0/3. The output of the show configuration rollback changes to 1000000035 command shows that this descriptor will be deleted and we will roll back to the configuration that was added by the commit 1000000034. Yes, this is a little different from the JunOS commit. In JunOS, we jump to the configuration we specified, but on IOS XR, using the specified command, we jump to the configuration that was before applying the specified commit, canceling and changing the commit specified in the command. Please note that in versions up to 5.3.X there is only such a command.

When using the command with the to-exclude keyword, the work of the command will be similar to the rollback in JunOS — the configuration that was applied in the specified commit will be rolled back:

 RP/0/0/CPU0:RZN-PE4#show configuration rollback changes to-exclude 1000000035 Sun Dec 11 17:37:17.183 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/4 no description "link to RZN-CE4-SW4" ! interface GigabitEthernet0/0/0/5 no description "link to RZN-CE4-SW5" ! end 

If you compare with the output that was presented when parsing the command with the to keyword, you will see differences - the changes that were made during the execution of commit 1000000035 are not reversed. I personally prefer this method, but, as I wrote earlier, this command is available only from version 5.3.x.

Note: the show configuration commit changes command can also show all changes that have been made from the current configuration to the specified commit (taking into account all intermediate configuration changes). To do this, use the since keyword and specify the commit ID or the last keyword and specify the serial number of the commit:

 RP/0/0/CPU0:RZN-PE4#sh configuration commit changes 1000000035 Sun Dec 11 18:01:33.533 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/3 description "link to RZN-CE4-SW3" ! end 

 RP/0/0/CPU0:RZN-PE4#sh configuration commit changes since 1000000035 Sun Dec 11 18:01:38.212 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/3 description "link to RZN-CE4-SW3" ! interface GigabitEthernet0/0/0/4 description "link to RZN-CE4-SW4" ! interface GigabitEthernet0/0/0/5 description "link to RZN-CE4-SW5" ! end 

But again, do not forget that this command shows everything that has been added to the configuration starting from the specified commit and ending with the current one, and you will roll back all these changes with your rollerback!

After JunOS, it's a little hard to understand the first rollback version. But we move on.

Unlike JunOS, Cisco does not just load the configuration when rolling back, but immediately applies it without even asking the administrator. This is a very significant difference, especially after JunOS, which loads the configuration, allows it to be edited (if necessary), checked and committed. But not everything is so bad, IOS XR also knows how to load a config without an automatic commit, but more on that later.

You can see what will change in the configuration with rolback in addition to the above commands in another way that JunOS lovers will like. It is necessary to use the previously mentioned commands but with the keyword diff . Here is an example of the output of configuration changes in the usual form:

 RP/0/0/CPU0:RZN-PE4#show configuration rollback changes to 1000000025 Sun Dec 11 17:42:44.450 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/1 shutdown ! interface GigabitEthernet0/0/0/1.777 l2transport ! interface GigabitEthernet0/0/0/2 no description "link to RZN-CE4-SW2" ! interface GigabitEthernet0/0/0/3 no description "link to RZN-CE4-SW3" ! interface GigabitEthernet0/0/0/4 no description "link to RZN-CE4-SW4" ! interface GigabitEthernet0/0/0/5 no description "link to RZN-CE4-SW5" ! no interface BVI777 interface BVI777 ipv4 address 10.0.0.254 255.255.255.0 no mac-address 200.0.4777 mac-address 200.0.4777 ! router bgp 6262 vrf VRF_EVPN no address-family ipv4 unicast ! ! evpn ! end 

But using the diff keyword. I think that the output below is easier to read, since it is indicated what is being added and what is being removed from the configuration:

 RP/0/0/CPU0:RZN-PE4#show configuration rollback changes to 1000000025 diff Sun Dec 11 17:42:50.580 UTC Building configuration... !! IOS XR Configuration 5.3.3 # interface GigabitEthernet0/0/0/1 + shutdown + ! # interface GigabitEthernet0/0/0/1.777 l2transport # ! - interface GigabitEthernet0/0/0/2 - description "link to RZN-CE4-SW2" - ! - interface GigabitEthernet0/0/0/3 - description "link to RZN-CE4-SW3" - ! - interface GigabitEthernet0/0/0/4 - description "link to RZN-CE4-SW4" - ! - interface GigabitEthernet0/0/0/5 - description "link to RZN-CE4-SW5" - ! - interface BVI777 + interface BVI777 - vrf VRF_EVPN - ipv4 address 10.0.0.254 255.255.255.0 + ipv4 address 10.0.0.254 255.255.255.0 - mac-address 200.0.4777 + mac-address 200.0.4777 + ! # router bgp 6262 # vrf VRF_EVPN - address-family ipv4 unicast - label mode per-vrf - redistribute connected - redistribute static - ! - ! - ! # evpn # ! end 

The truth is that configuration changes are somewhat strange, for example, these lines are useless:

 - ipv4 address 10.0.0.254 255.255.255.0 + ipv4 address 10.0.0.254 255.255.255.0 - mac-address 200.0.4777 + mac-address 200.0.4777 

Why this is done is not clear to me. But you have to put up with it.

Now consider another very useful feature - this is loading the configuration without its automatic commit. This is already done from the configuration mode. Here all actions are the same as described above and the same rules apply (to and to-exclude), but the configuration is not committed automatically. Consider an example:

If we make a rollback, then this part of the configuration will be removed:

 RP/0/0/CPU0:RZN-PE4#show configuration rollback changes to 1000000035 Sun Dec 11 17:50:53.187 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/3 no description "link to RZN-CE4-SW3" ! interface GigabitEthernet0/0/0/4 no description "link to RZN-CE4-SW4" ! interface GigabitEthernet0/0/0/5 no description "link to RZN-CE4-SW5" ! end 

Go to configuration mode and download the changes:

 RP/0/0/CPU0:RZN-PE4(config)#load rollback changes to 1000000035 Building configuration... Loading. 254 bytes parsed in 1 sec (249)bytes/sec 

Note: The output specifies the to keyword, so not only the changes applied to the specified commit are loaded, but also all intermediate commits. If the command were without to: load rollback changes 1000000035 , only the changes that were made with this commit would be loaded, and with the to-exclude keyword all changes would be loaded to commit 1000000035, not including the changes applied in commit 1000000035 itself.

With a simple rollback, the configuration would automatically commit and we would have removed the descriptors from three interfaces. In our case, all descriptors are in place:

 RP/0/0/CPU0:RZN-PE4(config)#do show int description | i 0/0/0/[3-5] Sun Dec 11 17:49:31.632 UTC Gi0/0/0/3 admin-down admin-down "link to RZN-CE4-SW3" Gi0/0/0/4 admin-down admin-down "link to RZN-CE4-SW4" Gi0/0/0/5 admin-down admin-down "link to RZN-CE4-SW5" 

But if you look at the configuration, we see that the changes are uploaded, but not applied - you can change them (although it’s not so easy, because part of the config will be deleted - as you can see, the no description command is indicated instead of the descript) and commit:

 RP/0/0/CPU0:RZN-PE4(config)#show Sun Dec 11 17:49:33.962 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/3 no description ! interface GigabitEthernet0/0/0/4 no description ! interface GigabitEthernet0/0/0/5 no description ! end 

If you change your mind to commit, the easiest way to use the following command

 RP/0/0/CPU0:RZN-PE4(config)#abort RP/0/0/CPU0:RZN-PE4# 

You will simply be thrown out of the configuration mode and all non-committed changes will be deleted. If you type end or exit, Cisco will ask what you want to do with the configuration:

 RP/0/0/CPU0:RZN-PE-4(config)#end Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:n RP/0/0/CPU0:RZN-PE-4# 

 RP/0/0/CPU0:RZN-PE-4(config)#exit Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:n RP/0/0/CPU0:RZN-PE-4# 

Adding a label to a commit or rolback can be added to one of the very useful functions:

 RP/0/0/CPU0:RZN-PE-4#rollback configuration to 1000000003 label bormoglotx RP/0/0/CPU0:RZN-PE-4#show configuration commit list Sun Dec 11 18:42:50.333 UTC SNo. Label/ID User Line Client Time Stamp ~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~ 1 bormoglotx bormoglot con0_0_CPU0 Rollback Sun Dec 11 18:42:40 2016 2 1000000004 bormoglot con0_0_CPU0 Rollback Sun Dec 11 18:33:34 2016 3 1000000003 bormoglot con0_0_CPU0 CLI Sun Dec 11 18:31:38 2016 4 1000000002 bormoglot con0_0_CPU0 CLI Sun Dec 11 18:31:25 2016 5 1000000001 bormoglot con0_0_CPU0 CLI Sun Dec 11 18:30:57 2016 

Now, instead of the ID indicated what you write.

Note: the ID itself is still assigned and indicated either in the detailed output or when selecting the commit ID:

 RP/0/0/CPU0:RZN-PE-4#show configuration rollback changes ? bormoglotx 1000000005 bormoglotx-1 1000000006 

In my opinion it is convenient. Two identical tags can not be specified, get the following error:

 RP/0/0/CPU0:RZN-PE-4#rollback configuration to 1000000004 label bormoglotx Sun Dec 11 18:47:24.214 UTC Loading Rollback Changes. Loaded Rollback Changes in 1 sec Committing. Rollback operation failed due to - 'CfgMgr' detected the 'warning' condition 'The specified label already exists in commit database.' Running configuration has not been modified. 

Another useful command would be show-error commit , which immediately indicates an error (as JunOS does). For example, a commit that will result in an error:

 RP/0/0/CPU0:RZN-PE-4(config)#commit Sun Dec 11 18:58:40.048 UTC % Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors 

Now we need to give the show configuration failed command to see the problem in the config. But you can immediately give the commit show-error command and if Jisk does not like the config, then an error message will immediately appear in the console:

 RP/0/0/CPU0:RZN-PE-4(config)#commit show-error Sun Dec 11 18:59:44.254 UTC % Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. !! SEMANTIC ERRORS: This configuration was rejected by !! the system due to semantic errors. The individual !! errors with each failed configuration command can be !! found below. interface BVI777 vrf VRF-TEST !!% 'RSI' detected the 'fatal' condition 'The interface's numbered and unnumbered IPv4/IPv6 addresses must be removed prior to changing or deleting the VRF' ! end RP/0/0/CPU0:RZN-PE-4(config)# 

The output immediately shows a piece of the config with an error.

I also wanted to draw attention to the commit commit best-effort function. This keyword for commit will apply all the lines that are correct, but the invalid ones will be ignored. Perhaps someone will need this function. Personally, I have never used it.

If necessary, the entire commit sheet can be cleared (for example, when swapping or re-using equipment as a new node). To do this, use the following command:

 RP/0/0/CPU0:RZN-PE-4#clear configuration commits oldest 43 Sun Dec 11 18:26:58.078 UTC Deleting 43 rollback points '1000000001' to '1000000043' 48 KB of disk space will be freed. Continue with deletion?[confirm] RP/0/0/CPU0:RZN-PE-4#show configuration commit list Sun Dec 11 18:27:18.977 UTC The commit database is empty. 

True information about all commits will still be saved, though in another place:

 RP/0/0/CPU0:RZN-PE-4#show configuration history Sun Dec 11 22:15:04.042 UTC Sno. Event Info Time Stamp ~~~~ ~~~~~ ~~~~ ~~~~~~~~~~ 1 startup configuration applied Sun Dec 11 07:00:27 2016 2 commit id 1000000001 Sun Dec 11 07:01:28 2016 3 commit id 1000000002 Sun Dec 11 07:07:19 2016 4 commit id 1000000003 Sun Dec 11 07:17:26 2016 

But the IDs indicated in this conclusion cannot be guided, since when resetting, the numbering begins again, for example, after 43 it goes again 1:

 RP/0/0/CPU0:RZN-PE-4#show configuration history | b ^52 Sun Dec 11 22:16:57.924 UTC 52 commit id 1000000043 Sun Dec 11 18:24:28 2016 53 commit id 1000000001 Sun Dec 11 18:28:53 2016 54 commit id 1000000001 Sun Dec 11 18:30:57 2016 

Well, do not forget about such an important and useful team as a commit confirmed , can significantly simplify life and save a lot of nerves. I think that there is no point in presenting it.

In conclusion, I wanted to describe the rake, which I once stepped on. You need to be careful with the rollback command, if instead of rollback configuration to 1000000020 you specify rollback configuration 1000000020 , then changes in the current configuration will be limited to those changes that were made in the commit ID you specified. I will show it on an example.

I make three commits in succession, adding one descriptor each. First commit:

 RP/0/0/CPU0:RZN-PE-4(config)#interface gigabitEthernet 0/0/0/3 description 111111 RP/0/0/CPU0:RZN-PE-4(config)#commit comment add 11111 Tue Dec 13 08:21:15.328 UTC RP/0/0/CPU0:RZN-PE-4(config)# 

Second commit:

 RP/0/0/CPU0:RZN-PE-4(config)#interface gigabitEthernet 0/0/0/4 description 22222 RP/0/0/CPU0:RZN-PE-4(config)#commit comment add 22222 Tue Dec 13 08:21:33.627 UTC RP/0/0/CPU0:RZN-PE-4(config)# 

Third commit:

 RP/0/0/CPU0:RZN-PE-4(config)#interface gigabitEthernet 0/0/0/5 description 33333 RP/0/0/CPU0:RZN-PE-4(config)#commit comment add 33333 Tue Dec 13 08:21:54.856 UTC RP/0/0/CPU0:RZN-PE-4(config)# 

Look at the ID of our commits:

 RP/0/0/CPU0:RZN-PE-4#show configuration commit list 5 Tue Dec 13 08:22:04.915 UTC SNo. Label/ID User Line Client Time Stamp ~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~ 1 1000000022 bormoglot con0_0_CPU0 CLI Tue Dec 13 08:21:54 2016 2 1000000021 bormoglot con0_0_CPU0 CLI Tue Dec 13 08:21:33 2016 3 1000000020 bormoglot con0_0_CPU0 CLI Tue Dec 13 08:21:15 2016 4 1000000019 bormoglot con0_0_CPU0 Rollback Tue Dec 13 08:20:20 2016 5 1000000018 bormoglot con0_0_CPU0 CLI Tue Dec 13 08:16:26 2016 

Now let's see what changes were made to commits (are these really our commits).

First rollback:

 RP/0/0/CPU0:RZN-PE-4#show configuration rollback changes 1000000022 Tue Dec 13 08:22:23.474 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/5 no description 33333 ! end 

Second rollback:

 RP/0/0/CPU0:RZN-PE-4#show configuration rollback changes 1000000021 Tue Dec 13 08:22:27.184 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/4 no description 22222 ! end 

And the third rollback:

 RP/0/0/CPU0:RZN-PE-4#show configuration rollback changes 1000000020 Tue Dec 13 08:22:30.373 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/3 no description 111111 ! end 

Suppose that I need to roll back all the changes and return to the configuration that was at commit 1000000019. We are looking at what will change when rollerback:

 RP/0/0/CPU0:RZN-PE-4#show configuration rollback changes to 1000000020 Tue Dec 13 08:22:34.553 UTC Building configuration... !! IOS XR Configuration 5.3.3 interface GigabitEthernet0/0/0/3 no description 111111 ! interface GigabitEthernet0/0/0/4 no description 22222 ! interface GigabitEthernet0/0/0/5 no description 33333 ! end 

And now making rollback, we make a mistake by skipping the to keyword:

 RP/0/0/CPU0:RZN-PE-4#rollback configuration 1000000020 Tue Dec 13 08:22:49.342 UTC Loading Rollback Changes. Loaded Rollback Changes in 1 sec Committing. 2 items committed in 1 sec (1)items/sec Updating. Updated Commit database in 1 sec Configuration successfully rolled back commit '1000000020'. 

Config rolled back, everything seems fine. But the result is not what we expected. We look at the config:

 RP/0/0/CPU0:RZN-PE-4#show running-config Tue Dec 13 08:22:56.432 UTC Building configuration... !! IOS XR Configuration 5.3.3 !! Last configuration change at Tue Dec 13 08:22:50 2016 by bormoglotx ! hostname RZN-PE-4 interface MgmtEth0/0/CPU0/0 shutdown ! interface GigabitEthernet0/0/0/0 description link to core ! interface GigabitEthernet0/0/0/1 description link to SW1 ! interface GigabitEthernet0/0/0/2 shutdown ! interface GigabitEthernet0/0/0/3 shutdown ! interface GigabitEthernet0/0/0/4 description 22222 shutdown ! interface GigabitEthernet0/0/0/5 description 33333 shutdown ! #       

Only the descrip- tion from the interface GigabitEthernet0 / 0/0/3 interface, which I hung out, committing 10,000,00020, was removed, and the changes that were in commits 10,000,00021 and 10,000,00022 were not canceled. So don’t skip to or to-exclude when config is rolled back more than 1 commit.

I hope the above will be useful to someone. Thanks for attention.