Upgrading and Managing Cisco IOS XR Software

The Cisco IOS XR software is divided into software packages so that you can select which features run on your router. This chapter describes the concepts and tasks necessary to add feature packages, upgrade the active set of packages, roll back to a previously active set of packages, and perform other related package management tasks.

Contents

Overview of Cisco IOS XR Software Packages

The Cisco IOS XR software is divided into software packages so that you can select which features run on your router. Each package contains the components to perform a specific set of router functions, such as routing, security, or Modular Services card support. Bundles are groups of packages that can be downloaded as a set. For example, the Unicast Routing Core Bundle provides six packages for use on every router.

Adding a package to the router does not affect the operation of the router: it only copies the package files to a local storage device on the router, known as the boot device. (such as the internal flash disk0: on a Cisco CRS-1, or the compact flash drive on a Cisco XR 12000 Series Router). To make the package functional on the router, you must activateit for one or more cards.

To upgrade a package, you activate a newer version of the package. Once the automatic compatibility checks have passed, the new version will be activated, and the old version will be deactivated.

To downgrade a package, you activate an older version of the package. Once the automatic compatibility checks have passed, the older version will be activated, and the newer version will be deactivated.

Package Installation Envelopes (PIE Files)

Package Installation Envelopes (PIE), are nonbootable files that can be used to upgrade or add software packages to the router. A PIE file may contain a single package or a set of packages (called a composite package or bundle). Because the files are nonbootable, they must be added and activated on a running router. PIE files have a pie extension. When a PIE file contains software for a specific bug fix, it is called a Software Maintenance Update (SMU).

Note Files with the vm extension are bootable installation files used only to replace all current Cisco IOS XR software. These files are installed from ROM Monitor mode, which causes significant router downtime. Cisco Systems recommends installing or upgrading software packages only using PIE files as described in this document. For more information on vm files, see Cisco IOS XR ROM Monitor Guide.

If the manageability PIE is installed, the entire SONET MIB history is available. If needed, you must configure SNMP and enable the SONET trap.

Summary of Cisco IOS XR Software Packages

Every router includes a basic set of required packages contained in the Cisco IOS XR Unicast Routing Core Bundle. Additional optional packages can be added and activated on the router to provide specific features. This section includes the following information:

Software Maintenance Updates

An SMU is a PIE file that contains fixes for a specific defect. A composite SMU is a PIE file that contains SMUs for more than one package. SMUs are added and activated using the same procedures as other PIE files. SMUs are created to respond to immediate issues and do not include new features. Typically, SMUs do not have a large impact on router operations. SMU versions are synchronized to the package major, minor, and maintenance versions they upgrade.

SMUs are not an alternative to maintenance releases. They provide quick resolution of immediate issues. All bugs fixed by SMUs are integrated into the maintenance releases. For information on available SMUs, contact the TAC, as described in the "Obtaining Technical Assistance" section.

Summary of Cisco IOS XR Software Bundles

The Cisco IOS XR Software packages are provided in the feature bundles listed in Table 7-3. These packages are described in the sections that follow.

PIE Filenames and Version Numbers

PIE filenames have two formats: one for composite-package PIEs and one for single-package PIEs. A composite-package file is a PIE file that contains multiple packages.

Note Hyphens in the filename are part of the filename.

Table 7-4 and Table 7-4 show the filenames in Cisco CRS-1 and Cisco XR 12000 Series Routers.

Table 7-4 PIE Filenames for Cisco CRS-1 Routers

Software delivery type

Cisco CRS-1 Router filename

Example

Composite (Bundle) PIE

comp-platform-composite_name.pie-major.minor.maintenance

comp-hfr-mini.pie-3.3.30

Single package PIE

platform-package_type.-p.pie-major.minor.maintenance

hfr-mgbl-p.pie-3.3.30

Composite SMU

comp-platform-composite_name.ddts.pie

comp-hfr-001.CSCec98xxx.pie

Single package SMU

platform-package_type-major.minor.maintenance.ddts.pie

hfr-base-3.3.30.CSCei4xxx.pi e

Note *A SMU composite name usually is "001," which means the SMU is the first SMU for that DDTS. In rare cases in which the same DDTS requires multiple composite SMUs, a second composite version number is released as "002." In the previous example, a second composite SMU "comp-002.CSCec98766" would be created for DDTS CSCec98766.

Table 7-5 PIE Filenames for Cisco XR 12000 Series Routers

Software delivery type

Cisco XR 12000 Series Router filename

Example

Composite (Bundle) PIE

platform-composite_name.pie-major.minor.maintenance

c12k-mini.pie-3.3.30

Single package PIE

platform-package_type.pie-major.minor.maintenance

c12k-mpls.pie-3.3.30

Composite SMU*

comp-platform-composite_name.ddts.pie

comp-c12k-001.CSCec98xxx.pie

Single package SMU

platform-package_type-major.minor.maintenance.ddts.pie

c12k-base-3.3.30.CSCei45xxx.pi e

Note *A SMU composite name usually is "001," which means the SMU is the first SMU for that DDTS. In rare cases in which the same DDTS requires multiple composite SMUs, a second composite version number is released as "002." In the previous example, a second composite SMU "comp-002.CSCec98766" would be created for DDTS CSCec98766.

•A major release occurs when there is a major architectural change to the product (for example, a major new capability is introduced).

•All packages operating on the router must be at the same major release level.

•A major release is the least frequent release and may require a router reboot.

minor

Identifies the minor release of this package.

•A minor release contains one or more of the following:

–New features

–Bug fixes

•The minor release version does not have to be identical for all software packages operating on the router, but the operating packages must be certified by Cisco as compatible with each other.

•A minor release may require a router reboot.

maintenance

Identifies the maintenance release of this package.

•A maintenance release contains a collection of bug fixes for a package.

•The maintenance release version does not have to be identical for all software packages operating on the router, but the major and minor versions of the maintenance release must match those of the package being updated.

•A maintenance release does not usually require a router reboot.

ddts

SMUs only. Identifies a Distributed Defect Tracking System (DDTS) number that describes the problem this SMU addresses.

DDTS is the method used to track known bugs and the resolutions or workarounds for those issues.

Information About Package Management

This section describes the following concepts for managing Cisco IOS XR software packages:

When you are adding an optional package, upgrading a package, or downgrading a package and the package version you want to use is not available on the router, you must copy the appropriate PIE file to the router or a network file server to which the router has access.

You can place the files on the router by inserting a flash disk with the appropriate files in the slot for flash disk1, or you can copy files to the router using one of several file transfer protocols. Although you can transfer PIE files to flash disk1 or flash disk0, the recommended approach is to store PIE files on flash disk1. By default, flash disk1 serves as the archive for PIE files that are no longer in use or have yet to be added. Flash disk0 serves as the storage location for all files that are ready for activation.

Tip Before copying PIE files to the router, check to see if the required PIE files are on flash disk1.

When the required PIE file is on the router or on an accessible network file server, the next step is to use the install add command to unpack the PIE file and move the package software to flash disk0. On routers with primary and standby RPs, the package is also added to the standby RP so that the standby RP is prepared to take over if the primary RP fails. The add process produces package software that is ready for activation.

Note The disk that holds the unpacked software files is also known as the boot device. By default, Cisco CRS-1 routers and Cisco XR 12000 Series Routers use flash disk0 as the boot device. To use an alternate storage device, such as flash disk1, refer to the "Router Recovery with ROM Monitor" chapter of the Cisco IOS XR ROM Monitor Guide. Remember that all RPs in a system must use the same boot device. If the boot device on the primary RP is flash disk0, then the standby RP must also have a flash disk0.

When you activate a software package with the install activate command, the router starts using the package version you have activated. If you are activating an optional package that has not been previously activated, the package is activated on all cards. If you are activating a newer (upgrade) or an older (downgrade) version of a previously activated package, you can choose to activate the package on all cards or on specific cards. When a package is activated during an upgrade or a downgrade, the previously active package version is deactivated.

The final step in adding, upgrading, or downgrading a package is to commit the current set of packages to the router configuration. When a router is reloaded, it loads the last committed set of packages. If different packages have been activated and not committed, those packages are not loaded. To ensure that recently activated packages become part of the committed package set, enter the install commit command.

Although the term commit sounds final, the Cisco IOS XR software provides the flexibility to roll back the selected package set to previously saved package sets. Each time a package is activated or deactivated, a rollback point is created that defines the package set that is active after the package activation or deactivation. The software also creates a rollback point for the last committed package set. If you find that you prefer a previous package set over the currently active package set, you can use the install rollback command to make a previously active package set active again.

Managing Software Packages in a Multishelf System

Adding and activating Cisco IOS XR software packages in a multishelf system is the same as in a single-shelf system. Software packages and related configurations are synchronized throughout a multishelf system by the DSC using the Ethernet control network, as shown in Figure 7-2. The DSC maintains an inventory of the packages, versions, and configurations for each node in the system.

Whenever a chassis comes on line, the DSC verifies that the software configuration for that chassis is correct and downloads any required packages and configurations. The active RP in each chassis then distributes and manages the software and configurations for the cards and equipment in that chassis.

Figure 7-2 DSC in a CRS-1/M-F1 Multishelf System

Managing Software Packages in Secure Domain Routers (SDRs)

Software packages are added to the boot device (usually disk0) of the DSC. Once added, a package can be activated for all SDRs in the system, or for a specific SDR.

Note In Release 3.3, SDR-specific activation is supported for specific packages and upgrades, such as optional packages and SMUs. Packages that do not support SDR-specific activation can only be activated for all SDRs in the system. See the release notes for the software package release for more information. See also the "Software Package Management Commands on Cisco IOS XR Software" module of Cisco IOS XR System Management Command Reference and the "Configuring Secure Domain Routers on Cisco IOS XR Software" module of Cisco IOS XR System Management Configuration Guide.

•To access install commands, you must be a member of the root-systemuser group with access to the Administration EXEC mode.

•Most show install commands can be used in the EXEC mode of an SDR to view the details of the active packages for that SDR.

Default Software Profile for SDRs

When a new non-owner SDR is created, the nodes assigned to that SDR are activated with the default software profile. In Release 3.3, the default profile is defined by the last install operation that did not specify an SDR.

To view the default software profile, use the show install active summary command in Administration EXEC mode. Any new nodes that are configured to become a part of an SDR will boot with the default software profile listed in the output of this command.

RP/0/0/CPU0:router(admin)# show install active summary

Default Profile:

SDRs:

Owner

sdr1

Active Packages:

disk0:c12k-sbc-3.3.0

disk0:c12k-diags-3.3.0

disk0:c12k-mgbl-3.3.0

disk0:c12k-mcast-3.3.0

disk0:c12k-mpls-3.3.0

disk0:c12k-k9sec-3.3.0

disk0:c12k-mini-3.3.0

Upgrading Packages

To upgrade a package that is currently active on the router, add and activate a newer version of the same package (see Figure 7-3). The older version of the software package is deactivated automatically. These actions are permitted only after the package compatibility checks and API version compatibility checks have passed.

Caution Upgrading or downgrading a software package can cause a process to restart or a new process to start. Use the
test option to preview the impact of the package activation.

Figure 7-3 Example of a Maintenance Release Package Upgrade

Downgrading Packages

To downgrade a software package, activate an older version on one or more cards for which that package is already active. The newer version of the same software package is deactivated automatically. These actions are performed only after the package compatibility checks and API version compatibility checks have passed.

Impact of Package Version Changes

Each package upgrade has a different impact on the operation of the router, depending on the type of package and whether the upgrade is for a major, minor, or maintenance release. The following resources can provide more information on the impact of a package version change:

•For specific information regarding the impact of an upgrade, consult the release notes for the package release, and test the impact of the package activation by adding the test option to the install activate command.

Impact of Package Activation and Deactivation

Activation or deactivation of a package can have an immediate impact on the system. The system can be affected in the following ways:

•When a new package is activated, any new CLI commands for the package are added to the SDRs impacted by the new software. The router need not be restarted or reloaded.

•When a package is deactivated, the commands associated with the features being deactivated are removed from any SDR impacted by the operation. The commands are no longer available to the user.

•During a software package deactivation, upgrade, or downgrade, any incompatible configurations are removed from the running configuration of any SDR impacted by the operation, and saved to a file. Incompatible configurations are those configurations that are not supported by the new version of the software package.

Note You must address any issues that result from the revised configuration and reapply the configuration, if necessary.

•New processes may be started.

•Running processes may be stopped or restarted.

•All processes in the cards may be restarted. Restarting processes in the cards is equivalent to a soft reset.

•The cards may reload.

•No impact: no processes in the card are affected.

Tip When activating and deactivating packages, use the test option to test the effects of a command without impacting the running system. After the activation or deactivation process completes, enter the show install log command to display the process results.

Controlling install Command Operations

The install command is used in different forms to perform many package management tasks, such as adding and activating packages. Only one install command can run at a time.

Delaying the return of the CLI prompt

By default, the CLI prompt is returned to the screen before the installation operation is complete, which allows you to enter other noninstall commands. If additional installation requests are attempted before the first operation is complete, they are not executed.

To delay the return of the CLI prompt until an installation operation is complete, enter the install command with the synchronous option. For example:

install add disk1:pie-file synchronous

install activate disk0:package synchronous

To determine if an install command is currently running, enter the show install request command.

Displaying Installation Log Information

The install log provides information on the history of the install operations. Each time an install operation is run, a number is assigned to that operation. Table 0-1 summarizes the commands used to view the install log.

•Use the show install log command to display information about both successful and failed install operations.

•The show install log command with no arguments displays a summary of all installation operations. Specify the request-id argument to display details for a specific operation.

•Use the detail or verbose keywords to display detailed information, including file changes, nodes that could be reloaded, impact to processes, and impact to dynamic link libraries (DLL).

Tip By default, the install log stores up to fifty (50) entries. Use the install log-history size command to reset the number of entries to any value from 0-255.

Examples

Display install log Entries

The following example displays information for the install requests. Use the verbose keyword to display detailed information, including files changes, impact to processes, and impact to dynamic link libraries (DLL).

Activation and Deactivation Prerequisites

The following prerequisites must be met for a package to be activated or deactivated.

•All cards should be installed and operating properly. For example, you should not activate or deactivate packages while cards are booting, while cards are being upgraded or replaced, or when you anticipate an automatic switchover activity.

•If a ROM Monitor upgrade is required for the software package, the upgrade must be completed before the package is activated. For ROM Monitor upgrade information and procedures, see Cisco IOS XR ROM Monitor Guide.

•Although more than one version of a software package can be added to a storage device, only one version of a package can be active for any card.

•Some packages require the activation or deactivation of other packages.

•The package being activated must be compatible with the current active software set.

•In Release 3.3, SDR-specific activation is supported for specific packages and upgrades, such as optional packages and SMUs. Packages that do not support SDR-specific activation can only be activated for all SDRs in the system. For detailed instructions, see the "Managing Cisco IOS XR Software Packages" module of the Cisco IOS XR Getting Started Guide.

While a software package is being activated, other requests are not allowed to execute on the system. Each CLI install request is assigned a requestID, which can be used later to review the events. Package activation is completed when a message similar to the following appears:

Activation is performed only after the package compatibility checks and API version compatibility checks have passed. If a conflict is found, an on-screen error message is displayed.

Obtaining and Placing Cisco IOS XR Software

This section contains information to locate the available software packages, and transfer them to either a local storage device or network server. Once this is done, the package or packages can be added and activated on the router.

There are two primary ways to obtain Cisco IOS XR software packages.

•Request the software from Cisco on a flash disk that you can insert into the removable flash disk slot (usually flash disk1). Flash disk1 is optional on Cisco CRS-1 routers and on Cisco XR 12000 Series Routers. When it is installed, flash disk1 can be used to store PIE files, which can then be used to add new software to the boot device (usually flash disk0).

•Download the Cisco IOS XR software packages to a local storage device of the DSC, such as flash disk1, or to a remote server, such as a tftp or rcp server.

The boot device is the local disk on the DSC where Cisco IOS XR software is added and activated. PIE files should not be stored on this boot device.

•The default boot device on a Cisco CRS-1 router is disk0. All PIE files should be stored on flash disk1.

•On the Cisco XR 12000 Series Router, the supported boot devices are disk1 and compact flash.

Locating and Downloading Cisco IOS XR Software

The Cisco IOS XR Software Selector tool allows you to browse for your software upgrade from a single interface. You can display and select software by package or bundle name, release, and platform. The tool also includes XML schemas. Choosing a platform, release, or software feature automatically limits the choices based on your selection, until you arrive at your preferred software.

After you select the package or bundle you want, platform, and release number, follow the instructions on the web page to download the software you have selected.

Unpacking Software Bundles (tar Files)

If the software you downloaded is in a tar file (which is denoted by a tar filename extension), you must unpack the file before the PIE files can be added to the router. Third-party software programs can unpack tar files and place the Cisco IOS XR software files in a folder you select. For more information on unpacking tar files, see the documentation for the third-party program.

Transferring Installation Files from a Network File Server to a Local Storage Device

If the Cisco IOS XR software pie files are located on a remote TFTP, FTP, SFTP, or rcp server, you can copy the files to a local storage device such as disk1. Once the pie files are located on a local storage device, the software packages can be added and activated on the router from that storage device. Table 7-7 describes the supported server protocols, and the CLI syntax used copy files from each server type to the local storage device.

Tip Cisco IOS XR software pie files can also be added to the router boot device directly from the remote server. See Adding and Activating Packages for more information.

Note Consult your system administrator for the location and availability of your network server.

Table 7-7 Download Protocols Supported by Cisco IOS XR Software

Name

Description

Trivial File Transfer Protocol

TFTP is a simplified version of FTP that allows files to be transferred from one computer to another over a network, usually without the use of client authentication (for example, username and password).

Note Some Cisco IOS XR images may be larger than 32 MB, and the TFTP services provided by some vendors may not support a file this large. If you do not have access to a TFTP server that supports files larger than 32 MB, download the software image using FTP or rcp.

File Transfer Protocol

FTP is part of the TCP/IP protocol stack and requires a username and password.

Remote Copy Protocol

The rcp protocol uses TCP to ensure the reliable delivery of data, and rcp downloads require a usernames.

SSH File Transfer Protocol

SFTP is part of the SSHv2 feature in the Security package and provides for secure file transfers. For more information, see the Cisco IOS XR System Security Configuration Guide.

The router commands listed in Table 7-8 show how to copy package files to the router using three types of file transfer protocols.

Required for FTP and rcp only and must be a valid username on the FTP or rcp server.

password

Required for FTP only. If a password is not provided, the networking device accepts anonymous FTP.

directory-path

The specified directory should be a directory under the home directory of the user. In the rcp and FTP examples in Table 7-8, the file being downloaded is in a subdirectory called "images" in the home directory of the user "john."

Note For FTP and rcp services, directory-path is the directory relative to the username home directory. If you want to specify an absolute path for the directory, you must add a "/" following the server address.

When the installation files have been transferred to a network file server or the router, you are ready to activate or upgrade the software.

Note Files with the vm extension are bootable installation files used only to replace all current Cisco IOS XR software. These files are installed from ROMMON and cause significant router downtime. We recommend installing or upgrading software packages using only PIE files, as described in this chapter. See Cisco IOS XR ROM Monitor Guide for information on installing from vm files.

Prepare for Software install Operations

Before adding or activating Cisco IOS XR software:

•Update the ROM Monitor software, if necessary.

•Determine if a software change is required.

•Verify that the new package is supported on your system. Some software packages require that other packages or package versions be activated on a router or SDR, and some packages only support specific cards.

•Always review the release notes for important information related to that release and to help determine the package compatibility with your router configuration.

•Verify that the system is stable and prepared for the software changes.

Caution The ROM Monitor software must be upgraded to version 1.40 or higher on all RPs before a Cisco CRS-1 system is upgraded to Cisco IOS XR Software Release 3.3.1 or higher release. If the router is brought up with an incompatible version of the ROM Monitor software, then the standby RP may fail to boot. For instructions to overcome a boot block in the standby RP in a single chassis system, see
Cisco IOS XR ROM Monitor Guide. If a boot block occurs in a multishelf system, contact your Cisco Systems support representative for assistance. See
Obtaining Technical Assistance.

In addition, Cisco CRS-1 Multishelf systems should be upgraded to ROMMON release 1.40 before being upgraded to IOS XR Release 3.3.1 to ensure RPs are assigned the correct rack numbers during system boot.

For more information, see
Cisco IOS XR ROM Monitor Guide.

This section includes instructions to prepare for software install operations.

Note Activation is performed only after the automatic package compatibility and API version compatibility checks have passed. If a conflict is found, an on-screen error message is displayed.

SUMMARY STEPS

1. Verify that the ROM Monitor version is correct:

a. admin

b. showdiag

c. Update the ROM Monitor software, if necessary.

2. Display the currently active software packages and determine if a change is necessary:

DETAILED STEPS

Command or Action

Purpose

Step 1

Verify that the ROM Monitor version is correct:

admin

show diag

Example:

RP/0/RP0/CPU0:router# admin

RP/0/RP0/CPU0:router(admin)# show diag

•Enters Administration EXEC mode.

•In Administration EXEC mode, the show diag command displays the ROM Monitor (ROMMON) software version for all cards in the system. Verify that the correct ROM Monitor software version is installed before upgrading Cisco IOS XR software packages.

•Displays the active software for an SDR or for all SDRs. Use this command to determine what software should be added, upgraded or downgraded on the router, and to compare to the active software report after install operations are complete.

–To display the active software for all SDRs on the router, enter this command in Administration EXEC mode.

–To display the active packages for a specific SDR from Administration EXEC mode, use the sdrsdr-name keyword and argument.

–Enter this command in EXEC mode when logged in to a specific SDR to display information for that SDR only.

Note You can also display the active packages for a specific node, and view results in detailed or summary mode. See "Software Package Management Commands on Cisco IOS XR Software" module of the Cisco IOS XR System Management Command Reference for more information.

•verbose: displays information from the detail display and sub-component information.

Note Always review the release notes for the software package for important information related to that release and to help determine the package compatibility with your router configuration.

Step 4

Verify that there are no corrupted software files.

install verify [sdrsdr-name]

Example:

RP/0/RP0/CPU0:router(admin)# install verify

Verifies the consistency of a previously installed software set with the package file from which it originated. This command can be used as a debugging tool to verify the validity of the files that constitute the packages to determine if there are any corrupted files. This command is particularly useful when issued after the activation of a package or upgrading the Cisco IOS XR software to a major release.

To perform the command for a specific secure domain router (SDR), use the install verify command with the sdr keyword and sdr-name argument.

Note The install verify command can take up to two minutes per package to process.

Step 5

exit

Example:

RP/0/RP0/CPU0:router(admin)# exit

Exits Administration EXEC mode and returns to EXEC mode.

Step 6

Verify the system is stable:

show system verify start

show system verify [detail|report]

Example:

RP/0/RP0/CPU0:router# show system verify start

RP/0/RP0/CPU0:router# show system verify

Displays a variety of information including the memory and CPU usage, process status, protocol status, and other status information.

•To initiate the system status check, enter the show system verify start command.

•Enter the show system verify or show system verify detail command display system status information.

–The report keyword displays the same information as the default show system verify command

Note While most of the output should display the status "OK", some processes may show other output, such as "Warning". This does not specifically indicate a problem. Contact your Cisco technical support representative for more information on the output of this command.

Step 7

show clock

Example:

RP/0/RP0/CPU0:router# show clock

Verifies that the system clock is correct. Software operations use certificates based on router clock times.

Display the active software for all SDRs or for a specific SDR

The following example displays the active packages for all SDRs in the system. Use this information to determine if a software change is required:

RP/0/RP1/CPU0:router(admin)#show install active summary

Default Profile:

SDRs:

Owner

CE1b

Active Packages:

disk0:hfr-diags-3.3.30

disk0:hfr-mgbl-3.3.30

disk0:hfr-k9sec-3.3.30

disk0:comp-hfr-mini-3.3.30

The following example displays a summary of active packages for a specific SDR:

RP/0/RP1/CPU0:router(admin)# show install active summary sdr owner

Active Packages:

disk0:hfr-diags-3.3.30

disk0:hfr-mgbl-3.3.30

disk0:hfr-k9sec-3.3.30

disk0:comp-hfr-mini-3.3.30

Display information about the contents of a PIE file

In the following example, information is displayed about the Multicast PIE. This command displays the expiry date of the package, the cards supported by the package, and other details. Use this information to verify the compatibility of the package with your system and other software packages.

Note A software activation is performed only after the automatic package compatibility and API version compatibility checks have passed. If a conflict is found, an on-screen error message is displayed.

Verify the current system status

The following example shows output from running the show system verify command:

Note While most of the output should display the status "OK", some processes may show other output, such as "Warning". This does not specifically indicate a problem. Contact your Cisco technical support representative for more information on the output of this command.

RP/0/RP1/CPU0:router# show system verify

Getting current router status ...

System Verification Report

==========================

- Verifying Memory Usage

- Verified Memory Usage : [OK]

- Verifying CPU Usage

- Verified CPU Usage : [OK]

- Verifying Blocked Processes

- Verified Blocked Processes : [OK]

- Verifying Aborted Processes

- Verified Aborted Processes : [OK]

- Verifying Crashed Processes

- Verified Crashed Processes : [OK]

- Verifying LC Status

- Verified LC Status : [OK]

- Verifying QNET Status

Unable to get current LC status info

- Verified QNET Status : [FAIL]

- Verifying GSP Fabric Status

- Verified GSP Fabric Status : [OK]

- Verifying GSP Ethernet Status

gsp WARNING messages for router

Current set of gsp ping nodes does not match initial set of nodes

- Verified GSP Ethernet Status : [WARNING]

- Verifying POS interface Status

- Verified POS interface Status : [OK]

- Verifying TenGigE interface Status

- Verified TenGigE interface Status : [OK]

- Verifying TCP statistics

- Verified TCP statistics : [OK]

- Verifying UDP statistics

tcp_udp_raw WARNING messages for router

UDP Packets sent has not increased during this period.

- Verified UDP statistics : [WARNING]

- Verifying RAW statistics

- Verified RAW statistics : [OK]

- Verifying RIB Status

- Verified RIB Status : [OK]

- Verifying CEF Status

- Verified CEF Status : [OK]

- Verifying CEF Consistency Status

- Verified CEF Consistency Status : [OK]

- Verifying BGP Status

- Verified BGP Status : [OK]

- Verifying ISIS Status

- Verified ISIS Status : [OK]

- Verifying OSPF Status

- Verified OSPF Status : [OK]

- Verifying Syslog Messages

- Verified Syslog Messages : [OK]

System may not be stable. Please look into WARNING messages.

Verify that the system clock is correct

The following example displays the current system clock setting:

RP/0/RP1/CPU0:router#show clock

17:30:47.718 UTC Sat Apr 15 2006

Adding and Activating Packages

The procedure in this section describes how to upgrade or add Cisco IOS XR software PIE files that are stored on a local storage device, such as flash disk1, or on a remote TFTP, FTP, SFTP, or rcp server. The PIE software file can include any of the following:

These instructions are also used to downgrade software packages. See Downgrading Packages for more information.

Note By default, install operations are performed asynchronously: the CLI prompt is returned before the operation is complete, allowing the operator to continue work while the installation is completed in the background. Use the synchronous keyword at the end of install commands to delay the return of the CLI prompt until an installation operation is complete. See Controlling install Command Operations for more information.

Prerequisites

Before upgrading or adding packages from flash disk1, verify that the following prerequisites have been met:

•Verify that the ROM Monitor version is correct. For instructions on upgrading ROM Monitor, see Cisco IOS XR ROM Monitor Guide.

Unpacks a pie file from local storage device or network server and add the package files to the boot device of the router. The boot device is located on the DSC.

•Replace pie-file with the name of the PIE file you want to add.

•The activate option automatically activates the software package after it is successfully added.

Note Multiple versions of a software package can be added to the storage device without impacting the running configuration, but only one version of a package can be activated for a card.

The following arguments are used when adding a package from a pie file located on a network server.

•Replace hostname_or_ipaddress with the host name or IP address of the network file server.

•Replace directory-path with the network file server path that leads to the PIE file to be added.

•Replace pie-file with the name of the PIE file you want to add.

•Replace username with a username that has access privileges to the directory in which the PIE file is stored.

•Replace password with the password associated with the username that has access privileges to the directory in which the PIE file is stored.

•The activate option automatically activates the software package after it is successfully added.

Note Multiple versions of a software package can be added to the storage device without impacting the running configuration, but only one version of a package can be activated for a card.

Step 5

show install inactive summary [locationnodeID]

Example:

RP/0/RP0/CPU0:router# show install inactive summary

(Optional) Displays the inactive packages on the router. Verify that the package added in the previous step appears in the display.

To display the inactive packages for a specific card (node), use the location option and specify the node ID.

Step 6

install activate device:package [sdrsdr-name] [locationnodeID] [test]

Example:

RP/0/RP0/CPU0:router(admin)# install activate disk0:c12k-mgbl-3.3.30

Activates a package that was added to the router boot device.

•Skip this step if the package was activated earlier with the install add command.

•Replace device:package with the name of the boot device and inactive package, which can be displayed as described in the previous step.

•Press ? after a partial package name to display all possible matches available for activation. If there is only one match, press [TAB] to fill in the rest of the package name.

•By default, packages are activated for all cards supported by that package.

•To activate a package for a specific card (node), use the location option and specify the node ID. To display a list of node IDs for the entire system, enter the show platform command in Administration EXEC mode. A package cannot be activated on a single node unless some version of the package being activated is already active on all nodes.

•The package being activated must be compatible with the currently active software to operate. When an activation is attempted, the system runs an automatic compatibility check to ensure the package is compatible with the other active software on the router. The activation is permitted only after all compatibility checks have passed.

Tip When activating packages, use the
test option to test the effects of a command without impacting the running system. After the activation process completes, enter the
show install log command to display the process results.

Step 7

Repeat Steps 4 through 6 until all packages are activated.

Activates additional packages as required for your router.

Step 8

show install active

Example:

RP/0/RP0/CPU0:router# show install active

(Optional) Displays all active packages.

•Use this display to determine if the correct packages are active.

Step 9

Verify that there are no corrupted software files.

install verify [sdrsdr-name]

Example:

RP/0/RP0/CPU0:router(admin)# install verify

(Optional) Verifies the consistency of a installed software set with the package file from which it originated. This command can be used as a debugging tool to verify the validity of the files that constitute the packages to determine if there are any corrupted files. This command is particularly useful when issued after the activation of a package or upgrading the Cisco IOS XR software to a major release.

To perform the command for a specific secure domain router (SDR), use the install verify command with the sdr keyword and sdr-name argument.

Note The install verify command can take up to two minutes per package to process.

Step 10

exit

Example:

RP/0/RP0/CPU0:router(admin)# exit

(Optional) Exits Administration EXEC mode and returns to EXEC mode.

Use this command only if you run the show system verify commands, which are entered in EXEC mode.

Step 11

Verify the system is stable:

show system verify start

show system verify [detail|report]

Example:

RP/0/RP0/CPU0:router# show system verify start

RP/0/RP0/CPU0:router# show system verify

(Optional) Displays a variety of information including the memory and CPU usage, process status, protocol status, and other status information. Use this information to verify that the system is stable.

•To initiate the system status check, enter the show system verify start command.

•Enter the show system verify or show system verify detail command display system status information.

–The report keyword displays the same information as the default show system verify command

Note While most of the output should display the status "OK", some processes may show other output, such as "Warning". This does not specifically indicate a problem. Contact your Cisco technical support representative for more information on the output of this command.

Step 12

admin

install commit

Example:

RP/0/RP0/CPU0:router(admin)# install commit

(Optional) Commits the current set of packages so that these packages are used if the router is restarted.

Whenever a Cisco IOS XR software image is released that supports SPAs and SIPs, a companion SPA or SIP FPD image is bundled with the Cisco IOS XR software release. However, the FPD image is not automatically upgraded. You must manually upgrade the FPD image running on the SPA or SIP when you upgrade the Cisco IOS XR software image. FPD versions must be compatible with the Cisco IOS XR software that is running on the router.

Examples

Adding a Package

The following example shows how to add the contents of a PIE file on disk1 to the boot device on the DSC. Because the software package is added to the boot device by default, it is not necessary to specify the device in the CLI.

Adding and Activating a Package from an FTP File Server with One Command

To add and activate a package with a single command, enter the install add command with the activate keyword. In the following example, the Manageability PIE located on disk1 is verified, unpacked, and added to the boot device disk0. The package is also activated for all SDRs in the system.

Displaying the Active Packages

The following example displays a summary of the active packages on a router. By default, the active packages for all SDRs are displayed.

RP/0/RP0/CPU0:router(admin)#show install active summary

Default Profile:

SDRs:

Owner

CE1b

Active Packages:

disk0:hfr-diags-3.3.30

disk0:hfr-mgbl-3.3.30

disk0:hfr-k9sec-3.3.30

disk0:comp-hfr-mini-3.3.30

You can also display the active packages for a specific SDR, or for a specific node. To display the packages contained in the Cisco IOS XR Unicast Routing Core Bundle, enter the showinstallactive command without the summary keyword:

RP/0/RP0/CPU0:router(admin)# show install active SDR Owner

RP/0/RP0/CPU0:router(admin)#s how install active sdr owner

Node 0/1/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/sp/mbihfr-sp.vm

Active Packages:

disk0:hfr-diags-3.3.30

disk0:comp-hfr-mini-3.3.30

Node 0/1/CPU0 [LC] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/lc/mbihfr-lc.vm

Active Packages:

disk0:hfr-diags-3.3.30

disk0:comp-hfr-mini-3.3.30

Node 0/6/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/sp/mbihfr-sp.vm

Active Packages:

disk0:hfr-diags-3.3.30

disk0:comp-hfr-mini-3.3.30

Node 0/6/CPU0 [LC] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/lc/mbihfr-lc.vm

Active Packages:

disk0:hfr-diags-3.3.30

disk0:comp-hfr-mini-3.3.30

Node 0/RP0/CPU0 [RP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/mbihfr-rp.vm

Active Packages:

disk0:hfr-diags-3.3.30

disk0:hfr-mgbl-3.3.30

disk0:hfr-k9sec-3.3.30

disk0:comp-hfr-mini-3.3.30

--More--

Committing the Active Package Set

Committed packages are the active packages that are persistent across router reloads. If you add and activate a package, it remains active until the next system reload. If you commit a package set, all packages in that set remain active across router reloads until the package set is replaced with another committed package set.

Before committing a package set, verify that the system is operating correctly and that the router is forwarding packets as expected.

To make the current active package set persistent across router reloads, enter the install commit command in Administration EXEC mode. In the following example, the active software packages are committed on a Cisco CRS-1 router:

Note Enter the show install committed command in Administration EXEC mode to display information for the entire system. Use the sdrsdr-name keyword and argument to display information for a specific SDR. Enter the show install committed command in EXEC mode of an SDR to display information for that SDR. For more information on the command options, see Cisco IOS XR System Management Command Reference.

In the following example, the committed packages are shown:

RP/0/RP0/CPU0:router# show install committed

Secure Domain Router: Owner

Node 0/1/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/sp/mbihfr-sp.vm

Committed Packages:

disk0:hfr-diags-3.3.30

disk0:comp-hfr-mini-3.3.30

Node 0/1/CPU0 [LC] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/lc/mbihfr-lc.vm

Committed Packages:

disk0:hfr-diags-3.3.30

disk0:comp-hfr-mini-3.3.30

Node 0/6/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/sp/mbihfr-sp.vm

Committed Packages:

disk0:hfr-diags-3.3.30

disk0:comp-hfr-mini-3.3.30

Node 0/6/CPU0 [LC] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.30/lc/mbihfr-lc.vm

Committed Packages:

--More--

As with the show install active command, the show install committed command may display a composite package that represents all packages in the Cisco IOS XR Unicast Routing Core Bundle.

Deactivating and Removing Cisco IOS XR Software Packages

When a package is deactivated, it is no longer active on the router, but the package files remain on the router. The package files can be reactivated later, or they can be removed from the router.

A package is deactivated using the following methods:

•When a newer version of a package is activated, the earlier version of the package is automatically deactivated. See Adding and Activating Packages for instructions.

•To downgrade a package, activate the older version. The newer package version will be deactivated automatically. See Adding and Activating Packages for instructions.

•Use the install deactivate command to deactivate a package. This command to turn off the package features for a card or card type.

Restrictions

•Packages can be removed only if they are deactivated from all cards in all SDRs.

•A package cannot be deactivated if that package is required by another active package. When a deactivation is attempted, the system runs an automatic check to ensure that the package is not required by other active packages. The deactivation is permitted only after all compatibility checks have passed.

•Router reloads: If the deactivation requires a router reload, a confirmation prompt appears. Use the install deactivate command with the noprompt keyword to automatically ignore any reload confirmation prompts and proceed with the package deactivation. The router reloads if required.

•Node reloads: If a software operation requires a node reload, the configuration register for that node should be set to autoboot. If the config-register for the node is not set to autoboot, then the system automatically changes the setting and the node reloads. A message describing the change is displayed.

•FPD versions must be compatible with the Cisco IOS XR software that is running on the router; if an incompatibility exists between an FPD version and the Cisco IOS XR software, the device with the FPGA may not operate properly until the incompatibility is resolved. For information on FRDs, including instructions to upgrade FRD images, refer to the "Upgrading FPD Cisco IOS XR Software" chapter of Cisco IOS XR Interface and Hardware Component Configuration Guide.

Press ? after a partial package name to display all possible matches available for deactivation. If there is only one match, press [TAB] to fill in the rest of the package name.

To deactivate a package only for a specific SDR, use the SDR keyword and sdr-name argument. When a package is deactivate for an SDR, a notification message appears on the console for that SDR with information on the impact of the deactivation.

Use the locationnode-id keyword and argument to deactivate the package for a specific node, if supported.

Step 3

show install inactive summary

Example:

RP/0/RP1/CPU0:router(admin)# show install inactive summary

(Optional) Displays a summary of the inactive packages.

Step 4

Verify that there are no corrupted software files.

install verify [sdrsdr-name]

Example:

RP/0/RP1/CPU0:router(admin)# install verify

(Optional) Verifies the consistency of a installed software set with the package file from which it originated. This command can be used as a debugging tool to verify the validity of the files that constitute the packages to determine if there are any corrupted files. This command is particularly useful when issued after the activation of a package or upgrading the Cisco IOS XR software to a major release.

To perform the command for a specific secure domain router (SDR), use the install verify command with the sdr keyword and sdr-name argument.

Note The install verify command can take up to two minutes per package to process.

Step 5

exit

Example:

RP/0/RP1/CPU0:router(admin)# exit

(Optional) Exits Administration EXEC mode and returns to EXEC mode.

Use this command only if you run the show system verify commands, which are entered in EXEC mode.

Step 6

Verify the system is stable:

show system verify start

show system verify [detail|report]

Example:

RP/0/RP1/CPU0:router# show system verify start

RP/0/RP1/CPU0:router# show system verify

(Optional) Displays a variety of information including the memory and CPU usage, process status, protocol status, and other status information. Use this information to verify that the system is stable.

•To initiate the system status check, enter the show system verify start command.

•Enter the show system verify or show system verify detail command display system status information.

–The report keyword displays the same information as the default show system verify command

Note While most of the output should display the status "OK", some processes may show other output, such as "Warning". This does not specifically indicate a problem. Contact your Cisco technical support representative for more information on the output of this command.

Step 7

admin

install commit

Example:

RP/0/RP1/CPU0:router(admin)# install commit

(Optional) Commits the current set of packages so that these packages are used if the router is restarted. Packages can only be removed if the deactivation operation is committed.

Displaying Rollback Points

A rollback point is created every time a software package set is committed. Beginning with Release 3.3, you can roll back the router to previously committed rollback points. For example, if you committed a package set and later committed a different package set, you can roll back the software to use the previously committed package set.

Note Rollback operations are performed for the entire router, not a specific SDR. This command can only be run from Administration EXEC mode.

To display the eligible rollback points, enter the show install rollback ? command as follows:

RP/0/RP1/CPU0:router(admin)# show install rollback ?

RP/0/RP0/CPU0:router(admin)#show install rollback ?

0 ID of the rollback point to show package information for

2 ID of the rollback point to show package information for

In this example, the rollback points are 0 and 2.

Display the Package Versions Associated With a Rollback Point

To display the package versions associated with one of these rollback points, enter the show install rollback command using the following syntax:

show install rollback rollbackPoint[detail] [location nodeID]

Note For more information on the command options, see Cisco IOS XR System Management Command Reference.

The following example shows how to display the packages that would become active if the software was rolled back to rollback point 2:

RP/0/RP0/CPU0:router(admin)# show install rollback 2

Secure Domain Router: Owner

Node 0/1/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.84/sp/mbihfr-sp.vm

Rollback Packages:

disk0:hfr-diags-3.3.84

disk0:comp-hfr-mini-3.3.84

Node 0/1/CPU0 [LC] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.84/lc/mbihfr-lc.vm

Rollback Packages:

disk0:hfr-diags-3.3.84

disk0:comp-hfr-mini-3.3.84

Node 0/RP0/CPU0 [RP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.84/mbihfr-rp.vm

Rollback Packages:

disk0:hfr-diags-3.3.84

disk0:hfr-mgbl-3.3.84

disk0:hfr-k9sec-3.3.84

disk0:comp-hfr-mini-3.3.84

Node 0/RP1/CPU0 [RP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.84/mbihfr-rp.vm

Rollback Packages:

disk0:hfr-diags-3.3.84

disk0:hfr-mgbl-3.3.84

disk0:hfr-k9sec-3.3.84

disk0:comp-hfr-mini-3.3.84

Node 0/SM0/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.84/sp/mbihfr-sp.vm

Rollback Packages:

disk0:hfr-diags-3.3.84

disk0:comp-hfr-mini-3.3.84

Node 0/SM1/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.84/sp/mbihfr-sp.vm

Rollback Packages:

disk0:hfr-diags-3.3.84

disk0:comp-hfr-mini-3.3.84

Node 0/SM2/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.84/sp/mbihfr-sp.vm

Rollback Packages:

disk0:hfr-diags-3.3.84

disk0:comp-hfr-mini-3.3.84

Node 0/SM3/SP [SP] [SDR: Owner]

Boot Image: /disk0/hfr-os-mbi-3.3.84/sp/mbihfr-sp.vm

Rollback Packages:

disk0:hfr-diags-3.3.84

disk0:comp-hfr-mini-3.3.84

Rolling Back to the Last Committed Package Set

To roll back to the last committed package set, enter the install rollback to committed command in Administration EXEC mode.

Tip To display the committed package versions, enter the show install committed command.

In the following example, the system is rolled back to the last committed package set:

RP/0/RP1/CPU0:router(admin)# install rollback to committed

Install operation 27 'install rollback to committed' started by user 'cisco' at

16:41:38 UTC Sat Nov 19 2005.

Info: The rollback to committed software will require a reload of impacted

Info: nodes because it is over multiple activation & deactivation

Info: operations.

Info: This operation will reload the following node:

Info: 0/RP1/CPU0 (RP) (SDR: Owner)

Info: This operation will reload all RPs in the Owner SDR, and thereby

Rolling Back to a Specific Rollback Point

The following rules apply when rolling back to an uncommitted rollback point:

•If you roll back to the most recent noncommitted rollback point (with the highest number), you do not need to reload the router.

•You can repeat the rollback process one rollback point at a time without reloading if you always choose the most recent rollback point.

•If you choose a rollback point that is older than the most recent point, the impacted nodes reload, interrupting data traffic on those nodes. Before the reload occurs, you are prompted to confirm the install rollback operation.

Tip To display the rollback points, enter the show install rollback ? command.

In the following example, the system is rolled back to noncommitted rollback point 8:

RP/0/RP0/CPU0:router(admin)# install rollback to 8

Install operation 10 'install rollback to 8' started by user 'cisco' at 07:49:26

UTC Mon Nov 14 2005.

The install operation will continue asynchronously.

RP/0/RP0/CPU0:router(admin)#Info: The changes made to software configurations will not
be persistent

Info: across system reloads. Use the command 'admin install commit' to make

Info: changes persistent.

Info: Please verify that the system is consistent following the software

MPLS Package Features

The Multiprotocol Label Switching (MPLS) package supports the following features:

•MPLS forwarding and load balancing

•MPLS traffic engineering (MPLS TE)

•Label distribution protocol (LDP)

–LDP core (RFC 3036) (including link and targeted neighbors)

–LDP graceful restart (draft-ieft-mpls-ldp-graceful-restart02.txt)

–LDP high availability (HA) (restart automatic switchover)

–LDP MIBs (draft-ieft-mpls-ldp0mib-08.txt)

–LDP support for Layer 3 load balancing

–LDP support on Packet-over-SONET/SDH (POS) interfaces

•Resource Reservation Protocol (RSVP)

–RSVP authentication, authorization, and accounting (AAA) CLI

–RSVP core

–RSVP extensions for OUNI

–RSVP graceful restart and hellos

–RSVP HA—nonstop forwarding (NSF) and hitless software upgrade

–RSVP refresh reduction

•UNI

–UNI-C AAA CLI

–UNI-C core

–UNI-C HA—NSF and hitless software upgrade

–UNI-C hierarchical SONET alarms suppression

–UNI-C line protocol state control

–UNI-C local path restoration

–UNI-C node recovery support

•LMP—static configuration

•Fast reroute (FRR) with link, node, and bandwidth protection

•XML schema support, configuration, and operation

Multicast Package Features

The Multicast package supports the following features:

•Auto-RP and Bootstrap Router (BSR)

•Bidirectional Protocol Independent Multicast (PIM)

•Dynamic registration using Internet Group Management Protocol (IGMP)

•Explicit tracking of hosts, groups, and channels for IGMPv3

•MBGP

•MSDP

•Multicast NSF

•Multicast Reverse Path Forwarding (RPF)—loose mode

•Out-of-resource handling

•PIM-SM

•PIM-SSM

•Source Specific Multicast with IGMP v3

Diagnostics Package

Cisco IOS XR online diagnostics allow you to test and verify hardware functionality while connected to a live network. Scheduled diagnostics help ensure system high availability (HA). If a problem is detected, online diagnostics help isolate the location of the problem, allowing you to identify and replace the hardware. Online diagnostics are also used for system acceptance when receiving new hardware.

The online diagnostics contain tests that check different hardware components and verify the data path and control signals. Nondisruptive online diagnostic tests provide background health monitoring and can be scheduled or run on demand. On-demand diagnostics run from the command-line interface (CLI); scheduled diagnostics run at user-designated intervals or specified times when the system is connected to a live network.

Integrated Field Diagnostics (IFDs) are provided to allow the loading and unloading of offline diagnostic images. Loading a diagnostic image places the specified location out of service. When an offline diagnostic image is loaded, the diagnostic start and diagnostic stop commands are used to control test execution, and the show diagnostic content and show diagnostic results commands are used to show the test list and results.

The integrated field diagnostics detect problems in hardware components, including memory (failures that occur over time).

For more general information on diagnostics, see Cisco IOS XR Diagnostics. See Cisco IOS XR Interface and Hardware Component Command Reference for diagnostic command information.