Your Cisco chassis comes preinstalled with IOS XR software. You either upgrade the software release to use new features and
software fixes, or you downgrade the software. To leverage new features that are added or software fixes that are provided,
it is important that you upgrade your software to a current version.
To help you select a Cisco IOS XR software release that aligns with Cisco-certified upgrade and downgrade paths, this feature
provides answers to the following questions:
-
What upgrade or downgrade releases are supported for the current release?
-
I plan to upgrade from Release X to Release Y. Does my chassis support upgrade to Release Y?
-
Are there any bridging SMUs that must be installed before I upgrade the software?
This feature provides a mechanism to determine whether the current release supports an upgrade to a target release. This task
is run at the start of a software upgrade or downgrade through the install replace command. If the validation fails, the software upgrade is blocked, and the system notifies the reason for the failure. This
feature allows you to proactively examine whether you can upgrade or downgrade to a certain release, saving time and effort
involved in planning and upgrading the software.
The feature provides the following information to help you understand the prerequisites or limitations related to the specific
software upgrade or downgrade:
You can overwrite the automatic validation using the force keyword in the install replace command. With this option, the system displays warning messages when the upgrade fails but does not block the software upgrade.
Use the force ? keyword to understand any other impact to system functionalities apart from the disabling of this process that determines
the supported releases for software upgrade or downgrade.
You can view the support information using the following show commands or through the operational data.
Command
|
Description
|
show install upgrade-matrix running
|
Displays all supported software upgrades from the current version according to the support data installed on the running system
|
show install upgrade-matrix iso
path-to-ISO
|
Displays details about the software upgrade from the current version to the version of the target ISO according to the support
data in both the running system and the ISO image
|
show install upgrade-matrix iso
path-to-ISO
all
|
Displays all supported software upgrades from any version according to the support data in the target ISO image
|
show install upgrade-matrix iso
path-to-ISO
from-running
|
Displays details about the software upgrade from the current version to the version of ISO according to the support matrices
in both the running system and the target ISO image
|
View All Supported Software Upgrade from Running Version
The following example shows all supported releases for upgrade from the current version 24.1.1 on the chassis:
RP/0/RP0/CPU0:ios#show install upgrade-matrix running
Fri Mar 15 12:53:23.715 IST
Matrix: XR version: 24.1.1, File version: 1.0, Version: N/A
The upgrade matrix indicates that the following system upgrades are supported from the current XR version:
From To Restrictions
---------- ---------- ------------
24.1.1 7.11.1 -
Add the from and to versions to the end of the CLI command, for data on versions with additional restrictions
For example, to display restrictions for the 24.1.1->7.11.1 upgrade, use
'show install upgrade-matrix running 24.1.1 7.11.1'
Pre and Post-Upgrade Installation Health Checks
This section describes about of the pre and postupgrade Installation health check for routers.
Existing client-server framework notifies the subscribed clients to perform the precheck functionality.
The System health check infrastructure that is plugged to the install pre and postchecks phase of the system upgrade. This
includes other existing install pre or postchecks.
Upgrade precheck:
-
If single command upgrade is triggered either with a force option or is configured to skip checks, then health check is bypassed
and a syslog entry added.
-
When single command upgrade is triggered, install infra performs install specific prechecks. If the install prechecks pass,
the system health check infra plug-in is invoked to check the overall system health.
-
The health check infrastructure returns the health status during the installation.
-
Single command upgrade continues on if the prechecks completes with no errors.
-
If any errors are detected, then single command upgrade continues or terminates depending on the option that is selected for
abort-on-precheck-failure.
-
Single command upgrade postchecks before autocommit triggers based on the user selected level information.
Upgrade post check:
-
Post checks are bypassed if force or config option is selected for single command upgrade.
-
If install specific postchecks are completed sucessfully, then the system health check infra plug-in is invoked. If no errors
are reported then the autocommit triggers.
-
If any errors are detected, the abort-on option that is saved before the upgrade reload is used to either abort the single
command upgrade or continue. This depends on the severity of the errors that are detected during post check.
-
Summary of the pre and posthealth check is appended to the single command upgrade operation log.
Installation Profile Creation
Installation Profile is created to choose and alternate installation behavior. One default profile is created involving pre
and postchecks. You can edit the install behavior to choose cases like terminate installation if precheck fails or revert
after post installation check. You can also choose to continue installation despite failure in pre checks.
You can configure “enable or disable” options to run pre or post installation checks or “abort-on-failure” for pre checks,
or "warn-on-failure" and “restore-to-v1” on post checks. To configure the Install profile, use the following commands:
config
install profile
profile_name
pre-checkmetric-name
[enable | disable] [abort-on-failure | continue-on-failure | revert-on-failure]
end
Following is a sample to display metric settings in the install profile.
RP/0/RP0/CPU0:ios#show install profile default
Fri Mar 15 11:29:35.381 IST
Profile Name : default
State : Enabled
Prechecks : Enabled
communication-timeout : Enabled [ warn-on-failure ]
config-inconsistency : Enabled [ error-on-failure ]
process-resource : Enabled [ warn-on-failure ]
process-status : Enabled [ warn-on-failure ]
system-clock : Enabled [ warn-on-failure ]
hw-monitoring : Enabled [ warn-on-failure ]
lc-monitoring : Enabled [ warn-on-failure ]
pci-monitoring : Enabled [ warn-on-failure ]
wd-monitoring : Enabled [ warn-on-failure ]
disk-space : Enabled [ error-on-failure ]
upgrade_matrix : Enabled [ error-on-failure ]
core-cleanup : Disabled [ NA ]
file-cleanup : Disabled [ NA ]
Postchecks : Enabled
communication-timeout : Enabled [ error-on-failure ]
config-inconsistency : Enabled [ error-on-failure ]
process-resource : Enabled [ error-on-failure ]
process-status : Enabled [ error-on-failure ]
system-clock : Enabled [ error-on-failure ]
hw-monitoring : Enabled [ error-on-failure ]
lc-monitoring : Enabled [ error-on-failure ]
pci-monitoring : Enabled [ error-on-failure ]
wd-monitoring : Enabled [ error-on-failure ]
Use the following configuration to report health check:
config
grpc local-connection
Netconf-yang agent
commit
The following is a sample to display health check states:
RP/0/RP0/CPU0:ios#show healthcheck internal states
Fri Mar 15 12:55:54.739 IST
Internal Structure INFO
Current state: Disabled
Reason: Success
Netconf Config State: Enabled
Grpc Config State: Disabled
Nosi state: Not ready
Appmgr conn state: Invalid
Nosi lib state: Not ready
Nosi client: Valid client