Understanding IOS-XR Fundamentals

In Lab 1: Understanding IOS-XR Fundamentals, participants typically focus on gaining foundational knowledge of the Cisco IOS XR operating system. This lab involves tasks such as exploring the modular architecture of IOS XR, understanding the concept of Control and Data planes separation, and navigating the command-line interface (CLI) to execute basic operational commands. Participants may also delve into system management aspects, including user access and roles. The lab aims to provide hands-on experience in comprehending the fundamental aspects of IOS XR, Cisco's highly scalable and resilient operating system designed for carrier-grade networks. Successful completion of NCS Lab 1 equips participants with essential skills in navigating and managing Cisco devices running IOS XR, laying the groundwork for more advanced configuration and troubleshooting tasks in subsequent labs.

Lab:

Task 1: Understanding Placement of IOS-XR

IOS XR was announced along with the CRS-1 in May 2004. The first generally available version was 2.0. The most recent release is version 7.X which was released in March 2019.

Other significant releases include the following.

• 3.2 – first generally available version for the 12000-router series
• 3.9 – first generally available version for the ASR9000 series
• 5.0 (September 20, 2013) – first generally available version for the NCS6000 series, which is based upon a Linux kernel
• 6.1.1 – Introduces support for the 64-bit Linux-based IOS XR operating system on ASR9000 series.

IOS XR aims to provide the following advantages over the earlier IOS trains:

• Improved high availability (largely through support for hardware redundancy and fault containment methods such as protected memory spaces for individual processes and process restart ability)
• Better scalability for large hardware configurations (through a distributed software infrastructure and a two-stage forwarding architecture)
• A package based software distribution model (allowing optional features such as multicast routing and MPLS to be installed and removed while the router is in service)
• The ability to install package upgrades and patches (potentially while the router remains in service)
• A web-based GUI for system management (making use of a generic, XML management interface)

Release numbering

Cisco IOS XR Software releases (X1.X2.X3) are designated by a change to either the first digit (X1) or the second digit (X2) in the release version number (for example, the 7 and the 3 in Cisco IOS XR Software Release 7.3.2). In general, a change to X1 would indicate a larger change compared to a change in X2.

Feature releases are delivered for one or more of the following reasons:

• Introduce significant changes throughout the software, including infrastructure or architectural changes:

Likely to cause a change to X1.

• New functions, features, and enhancements:

Likely to cause a change to X2.

• Bug fixes:

Likely to cause a change to X3.

Understanding Lifecycle of a IOS-XR Operating system.

The entire lifecycle of any feature release is 6.5 years, which includes the 18 months after the FCS date until the end-of-sale date of the feature release, plus 5 years starting from the end-of-sale date until the release end-of-life date. All maintenance releases of a particular feature release will share the same end-of-sale, end-of-maintenance, end-of-maintenance-through-migration, and end-of-life milestones.

As described in the “Maintenance release” section, Cisco provides software maintenance support on a feature release for 24 (FC and SMR) and 36 (EMR) months after an X.X release is introduced. Software maintenance support will provide customers with routine maintenance releases as well as point bug fixes through SMUs

Bug dispositions for each phase follow:

• First Customer Shipment (FCS): The time at which the Cisco IOS XR Software feature release is posted on Cisco.com.
• Announce end of sale: End-of-sale announcements generally occur 12 months after FCS of X.X.1 release. The announcement sets and shows all the significant milestone dates to the software lifecycle and helps customers plan for the eventual phasing out of support.
• End of Sale (EoS): End of sale occurs 18 months after FCS of X.X.1 release. Sales of this particular software release and its subsequent maintenance release should cease.
• Last date to ship: Last date to ship typically is 24 months after FCS of X.X.1 release but may be longer. It is the last date that manufacturing is allowed to ship a system with this release of software.
• End of Maintenance (EoM): End of maintenance occurs 24 or 36 months after FCS of X.X.1 release. Bugs found are evaluated and fixed as soon as possible. If it meets the acceptable criteria for an SMU before the EoM date, an SMU fix will be provided, or else the fix will go into the next available Maintenance and/or Feature release. For a Feature Release (FR) or Standard Maintenance Release (SMR), the EoM date occurs at 24 months. If the release is an Extended Maintenance Release (EMR), then EoM occurs at 36 months.
• End-of-maintenance PSIRT: End-of-maintenance PSIRT occurs 48 months after FCS of X.X.1 release. Bugs found become candidates for following feature releases but an SMU for the current release will not be provided. If the bug is a PSIRT aka security vulnerability in the software, an SMU will be generated if the fix was available before the end-of-maintenance PSIRT date. However, no other SMUs will be generated. Problem resolution is through a different feature release.

Product Security Incident Response Team

• End-of-maintenance PSIRT: End of life is 48 months after FCS of X.X.1 release. Bugs found become candidates for following feature releases. No SMUs will be generated. Problem resolution is through a different feature release.
• End of life: End of life is 60 months after the End-of-Sale (EoS) date. Calls to Cisco TAC will not be addressed for this release. TAC recommendation will be to upgrade to a currently supported release to validate whether the bug still exists.

Task 2: Understand the booting process of IOS-XR

Step 1:

• Power On Self Test (POST)
• RP0/0 takes over control and loads IOS-XR into the memory

Step 2:

• After IOS-XR loading is completed all LC will perform diagonistics
• All LC will start loading IOS-XR into memory till state is XR-RUN

Step 3:

• Once all LC reach XR-RUN, all software modules are initiated.
• All tables are calculated and provided to LC for local storage.

Task 3: Visual Ques for the booting process of IOS-XR

Once Router has finished booting the router will drop down into CLI mode. A prompt will appear as shown below.

RP/0/0/CPU0:ios#

This is monitoring mode. Let us have al look at a few monitoring commands.

Show version : The show version commands will display the following version.

• Operating System version
• Router uptime
• System image name and location
• System chassis
• System memory, Flash and hard drive information.
• Number of physical Interfaces
• Configuration register.

Show Platform: The “show platform” show us information regarding the hardware chassis, RP & Line card and their current status. All Line cards once completed loading of IOS-XR will display their status as XR-RUN. Anything apart from XR-RUN means the line card can not forward any packets in their current state.

Task 4: Understanding Two stage configuration process of IOS-XR

Cisco classis IOS support single-stage model. In single-stage model, each line of configuration that enters in the router takes immediate effect. Example: if you assign IP address to any interface, it will immediately apply as running configuration. This kind of approach doesn’t scale properly ,there could be many potential problems occurs like when you apply configuration from a file or script, It is possible for only part of the user-intended configuration to take effect due to syntax or transport error that can leaves the router configuration in an inconsistent state.

Cisco IOS XR support two–stage model. In two-stage model, first stage is target configuration where user builds his configuration. In this stage, you can address both, command syntax and transport error to ensure your entire target configuration has entered in the router successfully. This target configuration doesn’t affect your router running configuration. Second stage called commit stage. In this stage, your entire target configuration will be committed using “commit” command and it will become part of your running config.

The advantages of two-stage configuration model are what configuration will become your router running config. Also when you apply your bulk configuration on router, this model helps you in doing subsequent operation such as verification, checkpointing and logging.

First, we will see single-stage model of classic IOS. As we discuss earlier, in classic IOS when we configure each line on CLI it will become part of its running config. To demonstrate, we will configure simple IP address on interface and verify its running config.

Before Configuring IP Address on the interface

Router#
Router#sh run int e0/0
Building configuration...
Current configuration : 54 bytes
!
interface Ethernet0/0
no ip address
shutdown
end
Router#

This output shows us that the interface does not have any ip address configured and is currently in shutdown mode.

Let us configure an ip address on this interface and change the status to up state.

Router#configure terminal
Router(config)#interface Ethernet 0/0
Router(config-if)#ip address 10.1.1.1 255.255.255.0
Router(config-if)#no shutdown
\*Nov 24 07:24:45.674: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
\*Nov 24 07:24:46.674: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up

You can see that the interface was immediately transitioned to up state. Let us check the IP Address on the interface.

Router#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
end
Router#

The IP Address was also assigned to the interface immediately.

In the IOS-XR, the 1st stage of the configuration is building configuration known as target configuration. This target configuration will not take effect immediately and will not be visible in the running-configuration. To make this happen, we need to pass the second stage of the configuration called the commit phase. Let us view this effect in the below example.

RP/0/0/CPU0:ios#configure
Tue Jun  8 10:06:29.578 UTC
RP/0/0/CPU0:ios(config)#hostname RSTFORUM
RP/0/0/CPU0:ios(config)

Here you can see that the hostname is still shows up as IOS and the configured hostname of “RSTFORUM” has not been applied yet. To apply it use the “commit” command.

RP/0/0/CPU0:ios(config)#commit
RP/0/0/CPU0:RSTFORUM(config)#

Now the configuration has been applied.

Let us view how this works. Change the hostname to RST. But do not commit the configuration.

RP/0/0/CPU0:RSTFORUM(config)#hostname RST
RP/0/0/CPU0:RSTFORUM(config)#

Now check the running-configuration for the hostname.

RP/0/0/CPU0:RSTFORUM(config)#show running-config | inc hostname
hostname RSTFORUM

The current configuration still shows us a hostname RSTFORUM. To see configuration which is in stage 1 (target configration) but not commited yet use the “show configuration” command.

RP/0/0/CPU0:RSTFORUM(config)#show configuration

hostname RST
end

RP/0/0/CPU0:RSTFORUM(config)#

This shows all configuration waiting to be commited.

To see the configuration after current configration and target configuration is merged, use the “show configuration merged” command.

RP/0/0/CPU0:RSTFORUM(config)#show configuration merge 

Building configuration...
!! IOS XR Configuration 6.0.1
!
hostname RST
interface MgmtEth0/0/CPU0/0
    shutdown
!
interface GigabitEthernet0/0/0/0
    shutdown
!
interface GigabitEthernet0/0/0/1
    shutdown
end

Let us commit the taget configuration.

RP/0/0/CPU0:RSTFORUM(config)#commit
RP/0/0/CPU0:RST(config)#

Now target configration should be empty. Let us verify this.

RP/0/0/CPU0:RST(config)#show configuration 
Building configuration...
!! IOS XR Configuration 6.0.1
end
RP/0/0/CPU0:RST(config)#

Following events take place for every successful commit operation:

1. Before committing, it must first lock configuration session.

2. Save config changes in the commit change database as well create rollback point.

3. Add commit changes entry into configuration history

4. Generate config change notification using syslog

5. Target config integrated into running config

6. Unlock the configuration session.

Every commit is assigned a commit ID. This ID is unique on the platform as is retained even if the configuration is erased. To check the commit ID use the command “show configuration commit list”.

RP/0/0/CPU0:RST#show configuration commit list
Tue Jun  8 10:42:15.731 UTC
SNo.         Label/ID         User          Line                Client              Time Stamp
------       --------------   ----------    ----------------    -----------         ------------------------------
1            1000000002       cisco         con0\_0\_CPU0         CLI                 Tue Jun  8 10:13:50 2021
2            1000000001       cisco         con0\_0\_CPU0         CLI                 Tue Jun  8 10:06:51 2021

To view the changes make in any commit ID, use the command

RP/0/0/CPU0:RST#show configuration commit changes ?
all         Display configurations committed for all commits
last        Changes made in the most recent <n> commits
since       Changes made since (and including) a specific commit
1000000002  Commit ID
1000000001  Commit ID

The "all" parameter displays all commit changes.
The "last" paramter dispalys only changes made during the last commit.
The "since" paramters displays changes from that commit.

RP/0/0/CPU0:RST#show configuration commit  changes 1000000002

hostname RST
end
RP/0/0/CPU0:RST#

To rollback a certain commit ID use the "rollback" command

RP/0/0/CPU0:RST#rollback configuration 1000000002

Loading Rollback Changes.
Loaded Rollback Changes in 1 sec 
Committing.
1 items committed in 1 sec (0)items/sec
Updating.
Updated Commit database in 1 sec 
Configuration successfully rolled back commit '1000000002'.

RP/0/0/CPU0:RSTFORUM#

RP/0/0/CPU0:RSTFORUM#show configuration commit list 
Tue Jun  8 11:55:19.901 UTC
SNo. Label/ID              User      Line                Client      Time Stamp
~~~~ ~~~~~~~~              ~~~~      ~~~~                ~~~~~~      ~~~~~~~~~~
1    1000000003            cisco     con0\_0\_CPU0         Rollback    Tue Jun  8 11:40:04 2021
2    1000000002            cisco     con0\_0\_CPU0         CLI         Tue Jun  8 10:13:50 2021
3    1000000001            cisco     con0\_0\_CPU0         CLI         Tue Jun  8 10:06:51 2021

Even configuration done after a rollback is provided with its own commit ID.

RP/0/0/CPU0:ios#show configuration commit list 
Tue Jun  8 11:55:19.901 UTC
SNo. Label/ID              User      Line                Client      Time Stamp
~~~~ ~~~~~~~~              ~~~~      ~~~~                ~~~~~~      ~~~~~~~~~~
1    1000000003            cisco     con0\_0\_CPU0         Rollback    Tue Jun  8 11:40:04 2021
2    1000000002            cisco     con0\_0\_CPU0         CLI         Tue Jun  8 10:13:50 2021
3    1000000001            cisco     con0\_0\_CPU0         CLI         Tue Jun  8 10:06:51 2021

By default, the label for every commit is numeric. If a customer label is required, the label can be assigned with a label prefix.

Lets change the config again and give it a label.

RP/0/0/CPU0:RSTFORUM#configure                      
RP/0/0/CPU0:RSTFORUM(config)#interface loopback 100
RP/0/0/CPU0:RSTFORUM(config-if)#ip add 100.0.0.1/32
RP/0/0/CPU0:RSTFORUM(config-if)#no shutdown
RP/0/0/CPU0:RSTFORUM(config-if)#commit label LOOPBACK-100-CREATED
RP/0/0/CPU0:ios(config-if)#end

RP/0/0/CPU0:RSTFORUM#show configuration commit list 
Tue Jun  8 12:23:47.384 UTC
SNo. Label/ID              User      Line                Client      Time Stamp
~~~~ ~~~~~~~~              ~~~~      ~~~~                ~~~~~~      ~~~~~~~~~~
1    LOOPBACK-100-CREATED  cisco     con0\_0\_CPU0         CLI         Tue Jun  8 12:03:36 2021
2    1000000003            cisco     con0\_0\_CPU0         Rollback    Tue Jun  8 11:40:04 2021
3    1000000002            cisco     con0\_0\_CPU0         CLI         Tue Jun  8 10:13:50 2021
4    1000000001            cisco     con0\_0\_CPU0         CLI         Tue Jun  8 10:06:51 2021

The label was assigned to the commit ID.

To erase all the configuration from running-config use the command “commit replace”. A confirmation dialouge wil be displayed. Answer with a yes. Use with caution.

RP/0/0/CPU0:RSTFORUM#configure 

RP/0/0/CPU0:RSTFORUM(config)#commit replace 
This commit will replace or remove the entire running configuration. This
operation can be service affecting.
Do you wish to proceed? \[no\]: yes

RP/0/0/CPU0:ios(config)#