Hello my friend,
I’ll step aside for a moment from discussing the configuration of the technologies in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR and will talk about the process of configuration itself. Recently my colleague Greg Hankins has posted information about candidate config in Nokia (Alcatel-Lucent) SR OS. I want to show you how this feature works and outline one interesting fact about it.
What is candidate config about?
When you configure router, it’s obvious that you change some parameters. Sometimes you can change something that may lead to undesirable result, like locking yourself from console or even breaking the overall operation of the router in production network. In order to avoid such problem you might want to review the configuration before applying it to the device. That’s what the candidate config is:
- you configure the device with the all necessary commands with correct syntax;
- this configuration is saved in the memory and you can review it (alternatively, you can save it to file on flash/HDD at your router);
- after verification you just commit the configuration and only then it’s applied;
- there is also possibility to make config commit for a certain amount of time, so that if you don’t commit it again, it will revert back after the timer is expired;
- if you for some reason need to revert back configuration to any point in past, you just make rollback to any previous committed configuration;
In some literature it’s also called a two-stage config, where the first stage is the preparing the configuration and the second stage is its reviewing and applying. You can say me “Hey, Anton, I can prepare the config in lab or just in notepad and then paste it”. Well, that’s the option. But your prepared config from lab you can process as a candidate config in order to make possibility to see how it fits into original one. Relating to notepad “blind” config (when you type without context help and parser), it’s very easy to make a typo somewhere. And as you config is applied simultaneously line by line as you enter it, typo in the beginning can lead to false processing of the whole prepared configuration.
Let’s see with the examples, how it works.
Topology
Physical topology for our lab doesn’t changes, but as I always I provide it for your references:
In fact we don’t need three routers for this article. One Nokia (Alcatel-Lucent) VSR (SR 7750) and one Cisco IOS XRv (ASR 9000) would be enough, as we just configure single back-to-back link for inter-router connectivity:
We don’t have any initial configuration file as we’ll configure everything from the very beginning.
“Ordinary” configuration mode in Nokia (Alcatel-Lucent) SR OS
Usually in all trainings from Nokia (Alactel-Lucent) SRC program you will see this type of the configuration. Here the commands are applied and effective since you have pressed enter after it. Just a simple example:
|
A:vRR# configure |
You see the asterisk just after you have created interface. Asterisk mean that you have altered configuration since last save. As configuration is applied instantly, you must be very careful. Any your mistake in IPv4/IPv6 addressing, access-lists, route policies and so on might broke the operation of the production network.
In Cisco world you have the same configuration mode in Cisco IOS, IOS XE and NX-OS (if you don’t use VPC with configuration synchronization).
Candidate config in Nokia (Alcatel-Lucent) SR OS
More advanced and errorless approach for configuration implies using of candidate configuration. Let’s remove the configuration file from the part above and reload the router so that we have router with virgin config:
|
Login: admin |
First of all we need to configure the directory, where rollback points will be saved:
|
A:vRR# configure system rollback rollback-location cf3:/checkpoint_db |
Now let’s save config and jump into candidate config mode:
|
*A:vRR# admin save |
You see the “edit-cfg” text in the CLI, what means that you are preparing candidate configuration now. Let’s make the same configuration as we’ve done above:
|
A:vRR>edit-cfg# configure card 1 card-type “iom3-xp-b” |
You can spot that we don’t have asterisk as the first character in the string. It means that we don’t have altered configuration. If you try to see the configuration, it tells you that it’s impossible:
|
A:vRR>edit-cfg# admin display-config |
Probably you might think that configuration is already applied, but it isn’t:
|
A:vRR>edit-cfg# show router interface |
What you have now is ready candidate configuration that is awaiting your review and applying. You can review it using the following command:
|
A:vRR>edit-cfg# candidate view |
Using this command you can carefully check your configuration, before you apply it. By the way, here the full list of actions that you might want to apply to the candidate configuration:
|
A:vRR>edit-cfg# candidate |
Let’s assume we have checked everything and we are ready to implement these changes. The only thing we have to do is to commit the config:
|
A:vRR>edit-cfg# candidate commit |
You can issue “candidate commit timeout X”, where X is the amount of minutes, after which the configuration will be automatically reverted back.
Only now your configuration is effective, so you can check it:
|
*A:vRR# show router interface |
Don’t forget to save your configuration! After the commit only the active (running) configuration is changed.
The information about possible rollbacks can be displayed by the following command:
|
*A:vRR# show system rollback |
Here the list of the actions that you can perform with the config:
|
*A:vRR# admin rollback |
The explanation is very straightforward. To show them let’s create new checkpoint with the new hostname:
|
*A:vRR>edit-cfg# candidate view |
Now we can configure the changes between the new configuration and the previous one:
|
*A:SR1# admin rollback compare latest-rb to 1 |
To revert the configuration back, use the following command:
|
A:SR1# admin rollback revert 1 |
Candidate config in Cisco IOS XR
As I’ve mentioned above, previously (before IOS XR) Cisco had the same “ordinary” or one-stage configuration mode as one of the option at Nokia (Alcatel-Lucent) SR OS. On the other hand Cisco IOS XR has only configuration candidate mode. Let’s configure interface at XR1 in the direction of SR1:
|
RP/0/0/CPU0:ios#conf t |
As you might have guessed, in the example above we have prepared candidate config. The actual (running) configuration in Cisco IOS XR is displayed by mean of the following command:
|
RP/0/0/CPU0:ios(config)#do show ipv4 interface brief |
In the same time, the candidate config is shown by another command:
|
RP/0/0/CPU0:ios(config)#show configuration |
In almost all my articles you can see that I provide you in the configuration section for Cisco IOS XR output of the latter command.
In order to apply the configuration to the running-config, you should commit just in the very same way, as we’ve done it in Nokia (Alcatel-Lucent) SR OS earlier.
|
RP/0/0/CPU0:ios(config)#commit |
Now you created configuration is operational and you can ping Nokia (Alcatel-Lucent) SR OS router SR1, what was configured before:
|
RP/0/0/CPU0:ios#ping 10.0.0.1 |
In Cisco IOS XR you have almost the same toolset regarding configuration check-points, like comparison of active configuration to previous one, performing rollback and so on:
|
RP/0/0/CPU0:ios(config)#show conf |
Comparing to Nokia (Alcatel-Lucent) SR OS, you don’t have to save configuration in Cisco IOS XR. It’s saved automatically after each commit.
Lessons learned
Frankly speaking I was unaware of candidate config mode in Nokia (Alcatel-Lucent) SR OS. Just after Greg Hankins shared this information I’ve got such wonderful possibility to use 2-stage config during my articles. Of particular importance is the feature of rollback: I don’t have to manually remove some string from config. Instead of it I just make rollback, change config and apply it again.
Conclusion
Just in the beginning I’ve told that I want to outline one interesting fact. Coming back to one of the first articles in this series, where I was comparing overall configuration of Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR (link), you can easily spot that candidate config mode makes these two wonderful operation systems even more similar. This fact eases the operation of multi-vendor network for engineers. The same goal (ease of operation) is a key driver for candidate config feature itself. The possibility to review the configuration and modify it before actual applying to the router has already saved a lot of nerves for networkers across the globe and will definitely save yours. Take care and good bye.
Support us
BR,
Anton Karneliuk