Lab 1: Understanding IOS-XR Fundamentals
Lab 1: Understanding IOS-XR Fundamentals
Task 1: Understanding Placement of IOS-XR
|Operating System||Placement||Code||Device Series|
|IOS (Internetwork Operating System)||Enterprise Devices||Monolithic||ISR, Catalyst, Aironet|
|IOS-XE (eXecution Environment)||Enterprise & SP devices||Linux + Monolithic code||ISR, Catalyst, ASR, NCS Series|
|IOS-XR||Enterprise , SP, DataCenters||QNX (unix) + Packages Wind River + Packages (6.0+)||GSR, ASR, NCS Series|
|NX-OS (Nexus)||Datacenters||Linux + Packages||Nexus Series|
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)
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
- Power On Self Test (POST)
- RP0/0 takes over control and loads IOS-XR into the memory
- 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
- 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.
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.
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.
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#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 18.104.22.168/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)#