For most of us, working with Cisco means Cisco IOS. A syntax and CLI we are familiar with, a way of configuring we have learnt from the majority of books and materials. But when you start looking at Cisco ASR and NCS platforms, and especially if you are in an ISP or carrier environment, you will undoubtedly be exposed to Cisco ISO-XR.
Starting from this post, I aim to document the basic steps to help get familiar with the syntax, and gradually extend to more advanced topics.
For the following section, it is assumed that the XR device is booted and ready for operation.
Checking the software image.
With IOS-XR, we don’t just upload a Software image, but packages called PIEs (Package Installation Envelope). Each PIE is for a specific protocol or function.
Looking at the output, we can see the active image version is 7.1.3 and some of the PIEs uploaded are for multicast (asr9k-mcast-x64-2.0.0.0-r713) and MPLS (asr9k-mpls-x64-2.0.0.0-r713).
You will also notices some packages which have a different file name (asr9k-iosxr-os-64-2.0.0.1-r713.CSCvx80028). These are Software Maintenance Updates or SMUs and are bug patches. In this instance, the bug ID is CSCvx80028.
With IOS -XR, we often do not have to upgrade to a whole new release, but instead patch the existing S/W image. Some of these SMUs will cause a reload, and some don’t. This information will be available for each SMU.
“sh install inactive summary” will show PIEs installed, but not active. The reason is, either they are the list of PIEs for next target image to upgrade to, or old deactivated ones, following an upgrade.
Configuration
With IOS configuration, the moment you enter a command, it is part of the running config, and thus taking effect. For IOS-XR, when configuring a node, you are working on a target config. This config must be committed before taking effect.
On above example, you can notice few options available for the commit command. These are some of the options I typically use in production:
- “commit“, where I simply commit and enter. This makes the target configuration, running configuration.
- “confirmed” is my favourite, as I can set a timer in either seconds or minutes, before the config rolls back. This is a safety measure in case the change triggers an issue.
- “label” is for good documentation and is essential a description of the config purpose.
Configuration logs
Each time you commit a config, a log is kept with details of who committed the config, when and what was added. To view these details, use “show config commit list“, then “show config commit changes ” as per below example.
You also have the option to rollback to previous config state by using “rollback config” commands with its different choices. You can roll back to a specific label or the last set of labels.
Leave A Comment