Rollback in Cisco IOS XR
Everyone who has ever encountered the need to make changes to the configuration of Cisco equipment running IOS XR knows that, unlike regular IOS, IOS-XR requires a commit to apply the configuration. But how to commit the config, I think that everyone who at least once in his life felt for IOS XR knows. But how to roll back the config? On JunOS, everything is easy and understandable, which can not be said about IOS XR. Until a certain time, I did not know this, but one of the nights I had only 5 minutes to learn how to do this, to roll back the config and not get an accident. I did not find anything on the network except the manual of Tsiska in English, so I decided to write a small educational program on this topic, maybe someone will come in handy.
So let's go ...
Note: although the article is intended for beginner engineers, it can also be useful for engineers who have first-hand knowledge of IOS XR. As the saying goes, live and learn.
To begin with - as an introduction - I will briefly describe the process of applying the configuration on IOS XR for those who are not familiar with it (IOS XR). Suppose we want to add descriptor to the config, for example:
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 ordinary IOS, everything is simple - they added something to the config - the changes were immediately applied. On iOS XR, until we 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, 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 can be seen from the above conclusions, I made a comment on the commit. This helps a lot when looking for a configuration to roll back to.
Now let's go directly to the rollbacks themselves. To rollback the configuration, you can use the following command:
RP/0/0/CPU0:RZN-PE4#rollback configuration ?
last Rollback last 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 IDs. Unlike Juniper, in which the list of commits starts at 0 and the zero commit is the current config, on IOS XR the commit ID is incremented with each commit, and the current commit is the one that has the largest ID from the list. In our case, 1000000037 is the current configuration. Compared with JunOS, this is a commit with ID 0.
If we need to roll back just one commit - that is, to a 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 made the commits and when and find the one you need:
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 Tsiska will dump all the commits to you, which will be redundant information (it is unlikely that you made 40-50 commits at a time, although who knows ...). Unlike JunOS, iOS XR saves the last 100 commits.
But in my case, the above conclusion did not really help in finding the right commit. Not only did I make commits, it’s still impossible to figure out what time I need to return to. 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 roughly understand 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 not at all clear what is hiding under the described description. To understand what exactly 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 also the commit number in order, which is indicated 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 number of the commit, and 1000000037 is its ID. You can 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’s clear that the commit number is incremented with each execution of the commit)
But the peculiarity of this team is that it shows us exactly the changes that were applied in the specified commit. For example, let's see what changed in the configuration when the 1000000036 commit was made:
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 the commit 1000000036 compared to the previous commit 1000000035. That is, in the JunOS world, the analogue of this command is show system rollback 2 compare 3 (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 exactly the same way, but displays information, so to speak, “from your own 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 to this commit, but shows the changes within only the specified commit, and not the entire configuration as a whole. For example, we made 5 commits and now roll back to all 5 commits. This command will show us non-resulting changes when rolling back up to 5 commits, then only those changes that will be canceled within the specified commit ID, without taking into account all the intermediate commits. But the result of applying the rollback will be the cancellation of not only the specified commit, but also all intermediate changes, that is, we need to see a comparison of the current configuration with the configuration that was at the time the commit specified in the command was executed. That is, if we again draw an analogy with the JunOS world, then we need the output of the show system rollback 5 compare 0 command.
RP/0/0/CPU0:RZN-PE4#show configuration rollback changes ?
last Changes for rolling back last 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 IOS XR branch, and even then not on all versions. In any case, there is no such command on version 5.1.3, but already in 5.3.3.
With the to keyword, the command will display all the changes that will be made to the config as a result of applying the backback, 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 are canceled, including the changes applied in the commit 1000000035. In fact, we will 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 10,000,00035 configuration changes made in the commit:
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, descriptor was added to the GigabitEthernet0 / 0/0/3 interface. The output of the show configuration rollback changes to 1000000035 command shows that this description will be deleted and we will roll back to the configuration that was added with the 1000000034 commit. Yes, this is slightly different from the JunOS commit. In JunOS, we jump to the configuration we specified, but on IOS XR, when using the specified command, we jump to the configuration that was before the specified commit was applied, canceling changes to the commit specified in the command. Please note that in versions prior to 5.3.X there is only such a command.
When using the command with the to-exclude keyword, the command will look like a rollback in JunOS - it will roll back to the configuration that was applied in the specified commit:
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 the differences - those changes that were made when executing the 1000000035 commit are not canceled. Personally, I 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 were 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 rollback!
After JunOS, it’s a little tricky to understand the first rollback option. But move on.
Unlike JunOS, Cisco doesn’t 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 you to edit it (if necessary), check and commit. But not everything is so bad, IOS XR also knows how to load a config without an automatic commit, but more on that later.
In addition to the above commands, you can see what will change in the configuration during the rollback in a different way, which will appeal to JunOS fans. It is necessary to use the above commands but with the diff keyword. 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 because it indicates what is added and what is 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
True, the configuration changes are displayed 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 let's look at another very useful function - this is loading the configuration without automatically committing it. This is already done from the configuration mode. Here all the actions are the same as described above and the same rules apply (to and to-exclude), but the configuration is not committed automatically. Let
's look at an example: If we make a rollback, then this part of the configuration will be deleted:
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
We go into configuration mode and load 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 indicates the keyword to, so not only the changes applied in the specified commit are loaded, but also all the intermediate commits. If the command would be without to: load rollback changes 1000000035, then only the changes that were made with this commit would be loaded, and with the keyword to-exclude all changes would be loaded before the 1000000035 commit, not including the changes applied in the 1000000035 commit itself.
With a simple rollback, the configuration would automatically be commited and descriptions from three interfaces would be deleted from us. In our case, all the descriptions 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 this is not so simple, because part of the config will be deleted - as you see, no description is specified instead of descriptive) 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 about committing, the easiest way is 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 configuration mode and all non-committed changes will be deleted. If you enter end or exit, then Cisco will ask you what you want to do with the uncommitted 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#
One of the very useful functions is adding a label to a commit or rollback:
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 ID is 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’s convenient. Two identical labels cannot be specified, get this 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 commit show-error, 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 issue the commit command show-error, and if Tsiske doesn’t like the config, then an error indication will immediately drop out into 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 pay attention to the commit commit best-effort function. This commit word will apply all lines that are true when committing, and invalid lines 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 reusing the 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 output cannot be oriented, since when resetting, the numbering starts 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 commit confirmed, it can greatly simplify life and save a bunch of nerves. I think that it makes no sense to represent her.
In conclusion, I wanted to describe the rake that I once stepped on. You need to be careful with the rollback command, if instead of the rollback configuration to 1000000020 you specify the rollback configuration 1000000020, then the changes in the current configuration will be limited to those changes that were made in the commit ID you specified. I will demonstrate this with an example.
I make three commits in succession, adding one descriptive 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)#
We 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 with commit 1000000019. We look at what will change with the rollback:
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 a 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'.
The config rolled back, everything seems to be 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
!
#остальная часть конфига удалена для сокращения статьи
I only deleted the descriptor from the interface interface GigabitEthernet0 / 0/0/3, which I hung by committing 1000000020, but the changes that were made in the commits 1000000021 and 1000000022 were not canceled. So do not skip to or to-exclude when rolling back the config, more than 1 commit.
I hope the above will be useful to someone. Thanks for attention.