Issu
Issu
Note
Starting with Cisco IOS 12.2(31)SGA, ISSU is supported on the Catalyst 4500. All line cards are
supported.
Operating on redundant systems, the In-Service Software Upgrade (ISSU) process allows Cisco IOS
software to be updated or otherwise modified while packet forwarding continues. In most networks,
planned software upgrades are a significant cause of downtime. ISSU allows Cisco IOS software to be
modified while packet forwarding continues. This increases network availability and reduces downtime
caused by planned software upgrades. This document provides information about ISSU concepts and
describes the steps taken to perform ISSU in a system.
This section includes these topics:
Note
For complete syntax and usage information for the switch commands used in this chapter, first look at
the Cisco Catalyst 4500 Series Switch Command Reference and related publications at this location:
http://www.cisco.com/en/US/products//hw/switches/ps4324/index.html
If the command is not found in the Catalyst 4500 Series Switch Command Reference, it will be found in
the larger Cisco IOS library. Refer to the Cisco IOS Command Reference and related publications at this
location:
http://www.cisco.com/en/US/products/ps6350/index.html
5-1
Chapter 5
Note
Image type of the existing and target image must match. For example, you cannot upgrade from an
IP Base image to an Enterprise Services image (and vice versa) without experiencing several
minutes of traffic loss.
The active and the standby supervisor engines must have the same supervisor engine hardware
(same model, same memory, NFL daughter card and so on).
The new and old Cisco IOS software images must be loaded into the file systems (bootflash or
compact flash) of both the active and the standby supervisor engines before you begin the ISSU
process.
The old image should be available either in bootflash or compact flash and the system should have
been booted from one of these locations because the boot variable should not be changed before the
ISSU process unfolds.
Note
Nonstop Forwarding (NSF) must be configured and working properly. If you do not have NSF
enabled, see the Cisco Nonstop Forwarding document for further information on how to enable and
configure NSF.
Before you perform ISSU, ensure that the system is configured for redundancy mode SSO and that
the file system for both the active and the standby supervisor engines contains the new
ISSU-compatible image. The current Cisco IOS version running in the system must also support
ISSU.
You can enter various commands on the Catalyst 4500 series switch or the ISSU application on
Cisco Feature Navigator are to determine supervisor engine versioning and Cisco IOS compatibility.
If you enter the no ip routing command, ISSU falls back from SSO to RPR mode, resulting in traffic
loss.
Autoboot is turned on and the current booted image matches the one specified in the BOOT
environmental variable. For details on how to configure and verify these, please refer to "Modifying
the Boot Field and Using the boot Command, page 3-27.
If you enter the no ip routing command, ISSU falls back from SSO to RPR mode, resulting in traffic
loss.
5-2
OL-25340-01
Chapter 5
About ISSU
Note
5-3
Chapter 5
About ISSU
Figure 5-1
Service
provider
core
layer
Service provider
distribution
layer
Service
provider
access layer
Primary deployment
position for Cisco NSF
with SSO capable-routers
72134
Customers
Additional levels of availability may be gained by deploying Cisco NSF with SSO at other points in the
network where a single point of failure exists. Figure 5-2 illustrates an optional deployment strategy that
applies Cisco NSF with SSO at the enterprise network access layer. In this example, each access point
in the enterprise network represents another single point of failure in the network design. In the event of
a switchover or a planned software upgrade, enterprise customer sessions continue uninterrupted
through the network in this example.
5-4
OL-25340-01
Chapter 5
Figure 5-2
Service provider
distribution
layer
Service
provider
access layer
Primary deployment
position for Cisco NSF
with SSO-capable routers
Enterprise
access
layer
Secondary deployment
position for Cisco NSF
with SSO-capable
or -aware routers
Enterprise
distribution
layer
Enterprise
core
layer
72064
Service
provider
core
layer
NSF Overview
Cisco NSF works with the SSO feature in Cisco IOS software. SSO is a prerequisite of Cisco NSF. NSF
works with SSO to minimize the amount of time a network is unavailable to its users following a
switchover. The main objective of Cisco NSF is to continue forwarding IP packets following a supervisor
engine switchover.
Usually, when a networking device restarts, all routing peers of that device detect that the device went
down and then came back up. This transition results in what is called a routing flap, which could spread
across multiple routing domains. Routing flaps caused by routing restarts create routing instabilities,
which are detrimental to the overall network performance. Cisco NSF helps to suppress routing flaps in
SSO-enabled devices, thus reducing network instability.
Cisco NSF allows for the forwarding of data packets to continue along known routes while the routing
protocol information is being restored following a switchover. With Cisco NSF, peer networking devices
do not experience routing flaps. Data traffic is forwarded while the standby supervisor engine assumes
control from the failed active supervisor engine during a switchover. The ability of physical links to
remain up through a switchover and to be kept current with the Forwarding Information Base (FIB) on
the active supervisor engine is key to Cisco NSF operation.
5-5
Chapter 5
About ISSU
Control
plane
Active
Supervisor
Engine
NSF/SSO
Standby
Supervisor
Engine
Management
plane
Line cards
180230
Data
plane
5-6
OL-25340-01
Chapter 5
An ISSU-capable switch consists of two supervisor engines (active and standby) and one or more line
cards. Before initiating the ISSU process, copy the Cisco IOS software into the file systems of both
supervisor engines (see Figure 5-4).
Note
In the following figure, Cisco IOS 12.x(y)S represents the current version of Cisco IOS.
Figure 5-4
Cisco IOS
12.x(y)S
Cisco IOS
12.x(z)S
Active
NSF/SSO
Supervisor
Engine
Cisco IOS
12.x(y)S
Cisco IOS
12.x(z)S
Standby
Supervisor
Engine
180231
Line cards
5-7
Chapter 5
About ISSU
After you have copied the Cisco IOS software to both file systems, load the new version of Cisco IOS
software onto the standby supervisor engine (see Figure 5-5).
Note
Without the ISSU feature, you cannot have SSO or NSF functioning between the active and standby
supervisor engines when they are running two different versions of Cisco IOS image.
Figure 5-5
Load New Version of Cisco IOS Software on the Standby Supervisor Engine
Cisco IOS
12.x(y)S
Cisco IOS
12.x(z)S
Active
NSF/SSO
Supervisor
Engine
Cisco IOS
12.x(y)S
12.x(z)S
Standby
Supervisor
Engine
180232
Line cards
5-8
OL-25340-01
Chapter 5
After a switchover (NSF or SSO, not RPR), the standby supervisor engine takes over as the new active
supervisor engine (see Figure 5-6).
Figure 5-6
Cisco IOS
12.x(y)S
Old
Active
Supervisor
Engine
Cisco IOS
12.x(y)S
12.x(z)S
New
Active
NSF/SSO Supervisor
Switchover
Engine
180233
Line cards
5-9
Chapter 5
About ISSU
The former active supervisor engine is loaded with an old Cisco IOS image so that if the new active
supervisor engine experiences problems, you can abort and conduct a switchover to the former active,
which is already running the old image. Next, the former active supervisor engine is loaded with the new
version of Cisco IOS software and becomes the new standby supervisor engine (see Figure 5-7).
Figure 5-7
Load New Standby Supervisor Engine with New Cisco IOS Software
Cisco IOS
12.x(y)S
12.x(z)S
Standby
Supervisor
Engine
Cisco IOS
12.x(y)S
12.x(z)S
NSF/SSO
Active
Supervisor
Engine
180234
Line cards
5-10
OL-25340-01
Chapter 5
Figure 5-8
1
Standby
Old
Active
Old
Loadversion
5
Active
New
Standby
New
Commitversion
Abortversion
2
Standby
New
Active
Old
Abortversion
4
Active
New
Switchover
3
Active
New
Standby
Old
Standby
Old
Runversion
Commitversion
Commitversion
180235
*Acceptversion
Note
To use the issu changeversion command, both old and new IOS versions must support issu
changeversion functionary.
5-11
Chapter 5
About ISSU
Changeversion Process
The issu changeversion command launches a single-step complete ISSU upgrade cycle. It performs the
logic for all four of the standard commands (issu loadversion, issu runversion, issu acceptversion, and
issu commitversion) without user intervention, streamlining the upgrade through a single CLI step.
Additionally, issu changeversion allows the upgrade process to be scheduled for a future time. This
enables you to stage a number of systems to perform upgrades sequentially when a potential disruption
would be least harmful.
After the standby supervisor engine initializes and the system reaches a terminal state (RPR/SSO), the
upgrade process is complete and the BOOT variable is permanently written with the new IOS software
software image. Hence, a reset on any RP will keep the system booting the new software image. Console
and syslog messages will be generated to notify anyone monitoring the upgrade that the state transition
has occurred.
Similar to the normal ISSU upgrade procedure, the in-progress upgrade procedure initiated by the
issu changeversion command can be aborted with the issu abortversion command. If the system
detects any problems or detects an unhealthy system during an upgrade, the upgrade might be
automatically aborted.
When the issu runversion command is entered during the four step manual upgrade process, if any
incompatible ISSU clients exist, the upgrade process reports them and their side effects, and allows the
user to abort the upgrade. While performing a single-step upgrade process, when the process reaches the
runversion state, it will either automatically continue with the upgrade provided the base clients are
compatible, or automatically abort because of client incompatibility. If the user wants to continue the
upgrade procedure in RPR mode, the user must use the normal ISSU command set and specify the force
option when entering the issu loadversion command.
5-12
OL-25340-01
Chapter 5
Even with ISSU, it is recommended that upgrades be performed during a maintenance window.
The new features should not be enabled (if they require change of configuration) during the ISSU
process.
Note
Enabling them will cause the system to enter RPR mode because commands are only supported
on the new version.
In a downgrade scenario, if any feature is not available in the downgrade revision of the Cisco IOS
software handle, that feature should be disabled prior to initiating the ISSU process.
Note
The operating mode of the system in a redundant HA configuration is determined by exchanging version
strings when the standby supervisor engine registers with the active supervisor engine.
The system entered SSO mode only if the versions running on the both supervisor engines were the same.
If not, the redundancy mode changes to RPR. With ISSU capability, the implementation allows two
different but compatible release levels of Cisco IOS images to interoperate in SSO mode and enables
software upgrades while packet forwarding continues. Version checking done before ISSU capability
was introduced is no longer sufficient to allow the system to determine the operating mode.
5-13
Chapter 5
About ISSU
Compatibility Matrix
You can perform the ISSU process when the Cisco IOS software on both the active and the standby
supervisor engine is capable of ISSU and the old and new images are compatible. The compatibility
matrix information stores the compatibility among releases as follows:
CompatibleThe base-level system infrastructure and all optional HA-aware subsystems are
compatible. An in-service upgrade or downgrade between these versions succeeds with minimal
service impact. The matrix entry designates the images to be compatible (C).
IncompatibleA core set of system infrastructure exists in Cisco IOS that must be able to
interoperate in a stateful manner for SSO to function correctly. If any of these required features or
subsystems is not interoperable, then the two versions of the Cisco IOS software images are declared
to be incompatible. An in-service upgrade or downgrade between these versions is not possible. The
matrix entry designates the images to be incompatible (I). The system operates in RPR mode during
the period when the versions of Cisco IOS at the active and standby supervisor engines are
incompatible.
If you attempt to perform ISSU with a peer that does not support ISSU, the system automatically
uses RPR instead.
The compatibility matrix represents the compatibility relationship a Cisco IOS software image has with
all of the other Cisco IOS software versions within the designated support window (for example, all of
those software versions the image knows about) and is populated and released with every image. The
matrix stores compatibility information between its own release and prior releases. It is always the
newest release that contains the latest information about compatibility with existing releases in the field.
The compatibility matrix is available within the Cisco IOS software image and on Cisco.com so that
users can determine in advance whether an upgrade can be done using the ISSU process.
To display the compatibility matrix data between two software versions on a given system, enter the
show issu comp-matrix stored command.
Note
This command is useful only for verification purposes because it is available only after the ISSU process
has started. You might want to check the compatibility matrix prior to starting ISSU. Use the Feature
Navigator to obtain the needed information:
http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp
5-14
OL-25340-01
Chapter 5
Compare two images and understand the compatibility level of the images (that is, compatible,
base-level compatible, and incompatible)
Compare two images and see the client compatibility for each ISSU client
Note
For an illustration of the process flow for ISSU, refer to Figure 5-8 on page 5-11.
This section includes the following topics:
Loading New Cisco IOS Software on the Standby Supervisor Engine, page 5-18 (required)
Loading New Cisco IOS Software on the New Standby Supervisor Engine, page 5-24
Configuring the Rollback Timer to Safeguard Against Upgrade Issues, page 5-32
5-15
Chapter 5
Disabled stateThe state for the standby supervisor engine while this engine is resetting.
Init stateThe initial state is two supervisor engines, one active and one standby, before the ISSU
process is started. It is also the final state after the ISSU process completes.
Load version (LV) stateThe standby supervisor engine is loaded with the new version of Cisco
IOS software.
Run version (RV) stateThe issu runversion command forces the switchover of the supervisor
engines. The newly active supervisor engine now runs the new Cisco IOS software image.
System reset (SR) stateThis state occurs either when you enter the issu abortversion command
before the Init state is reached, or if the rollback timer expires before you execute the
issu acceptversion command.
You can verify the ISSU software installation by entering show commands, as follows:
Step 1
Command or Action
Purpose
Switch> enable
Step 2
Step 3
This example shows how to display the state and the current status of the supervisor engine during the
ISSU process:
Switch> enable
Switch# show issu state
Switch# show redundancy
5-16
OL-25340-01
Chapter 5
=
=
=
=
=
240000 milliseconds
9000 milliseconds
0
18
0x0
=
=
=
=
1 minute
0
0
none
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
Stateful Switchover
Stateful Switchover
Disabled
Up
5-17
Chapter 5
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
Init
bootflash:old_image,1;
Stateful Switchover
N/A
N/A
bootflash:old_image
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
2
Standby
Init
bootflash:old_image,1;
Stateful Switchover
N/A
N/A
bootflash:old_image
The new version of the Cisco IOS software must be present on both of the supervisor engines. The
directory information displayed for each of the supervisor engines (or supervisor engines) shows that the
new version is present.
Switch# dir bootflash:
Directory of bootflash:/
5
6
-rwx
-rwx
13636500
13636500
old_image
new_image
-rwx
-rwx
13636500
13636500
old_image
new_image
Prerequisites
Ensure that the new version of Cisco IOS software image is already present in the file system of both
the active and standby supervisor engines. Also ensure that appropriate boot parameters (BOOT
string and config-register) are set for the standby supervisor engine.
Note
The switch must boot with the BOOT string setting before the ISSU procedure is attempted.
Note
Optionally, perform additional tests and commands to determine the current state of peers and
interfaces for later comparison.
5-18
OL-25340-01
Chapter 5
Ensure the system (both active and standby supervisor engines) is in SSO redundancy mode. If the
system is in RPR mode rather than SSO mode, you can still upgrade the system using the ISSU CLI
commands, but the system experiences extended packet loss during the upgrade.
Refer to the Stateful Switchover document for more details on how to configure SSO mode on
supervisor engines.
For ISSU to function, the image names on the active and standby supervisor engines must match.
Step 1
Command or Action
Purpose
Switch> enable
Step 2
Step 3
Step 4
This example shows how to start the ISSU process, boot the standby supervisor engine in the Standby
Hot state, and load the standby supervisor engine slot (2) with the new image:
Switch> enable
Switch# issu loadversion 1 bootflash:new_image 2 slavebootflash:new_image
Switch# show issu state detail
Slot = 1
RP State = Active
ISSU State = Load Version
Boot Variable = bootflash:old_image,12
Operating Mode = Stateful Switchover
Primary Version = bootflash:old_image
Secondary Version = bootflash:new_image
Current Version = bootflash:old_image
5-19
Chapter 5
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
2
Standby
Load Version
bootflash:new_image,12;bootflash:old_image,12
Stateful Switchover
bootflash:old_image
bootflash:new_image
bootflash:new_image
=
=
=
=
=
240000 milliseconds
9000 milliseconds
1
18
0x0
The following example shows how the forced option places the system in RPR mode:
Switch> enable
Switch# issu loadversion 1 bootflash:new_image 2 slavebootflash:new_image forced
Switch# show issu state detail
Slot = 1
RP State = Active
ISSU State = Load Version
Boot Variable = bootflash:old_image,12
Operating Mode = RPR
Primary Version = bootflash:old_image
Secondary Version = bootflash:new_image
Current Version = bootflash:old_image
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
2
Standby
Load Version
bootflash:new_image,12;bootflash:old_image,12
RPR
bootflash:old_image
bootflash:new_image
bootflash:new_image
5-20
OL-25340-01
Chapter 5
=
=
=
=
=
240000 milliseconds
9000 milliseconds
1
18
0x0
Step 1
Command or Action
Purpose
Switch> enable
Step 2
Step 3
Step 4
This example shows how to cause a switchover to the former standby supervisor engine (slot 2), reset
the former active supervisor engine and reload it with the old image so it becomes the standby supervisor
engine:
Switch> enable
Switch# issu runversion 2 slavebootflash:new_image
This command will reload the Active unit. Proceed ? [confirm]
5-21
Chapter 5
A switchover occurs at this point. At the new active supervisor engine, after old active supervisor engine
comes up as the standby engine, do the following:
Note
=
=
=
=
=
=
=
=
2
Active
Run Version
bootflash:new_image,12;bootflash:old_image,12
Stateful Switchover
bootflash:new_image
bootflash:old_image
bootflash:new_image
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
1
Standby
Run Version
bootflash:old_image,12
Stateful Switchover
bootflash:new_image
bootflash:old_image
bootflash:old_image
The new active supervisor engine is now running the new version of software, and the standby supervisor
engine is running the old version of software and is in the standby hot state.
Switch# show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary
Unit ID = 2
=
=
=
=
=
240000 milliseconds
9000 milliseconds
1
18
0x0
Once runversion command completes, the new active supervisor engine is running the new version of
software and the previously active supervisor engine now becomes the standby supervisor engine. The
standby is reset and reloaded, but remains on the previous version of software and come back online in
standbyhot status. The following example shows how to verify these conditions:
Switch# show redundancy
Redundant System Information :
-----------------------------Available system uptime
Switchovers system experienced
Standby failures
Last switchover reason
=
=
=
=
23 minutes
1
0
user forced
5-22
OL-25340-01
Chapter 5
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
Stateful Switchover
Stateful Switchover
Disabled
Up
Note
If you want to retain your switch in this state for an extended period, you need to stop the rollback
timer (then validate and run the acceptversion command directly).
If you want to proceed to the following step (running commitversion) within the rollback timer
window of 45 minutes, you do not need to stop the rollback timer.
The issu acceptversion command can be optionally executed after the issu runversion command.
5-23
Chapter 5
Step 1
Command or Action
Purpose
Switch> enable
Step 2
Halts the rollback timer and ensures the new Cisco IOS
ISSU process is not automatically aborted during the ISSU
process.
Enter the issu acceptversion command within the time
period specified by the rollback timer to acknowledge that
the supervisor engine has achieved connectivity to the
outside world; otherwise, the ISSU process is terminated,
and the system reverts to the previous version of Cisco IOS
software by switching to the standby supervisor engine.
Step 3
This example displays the timer before you stop it. In the following example, the Automatic Rollback
Time information indicates the amount of time remaining before an automatic rollback occurs.
Switch> enable
Switch# show issu rollback-timer
Rollback Process State = In progress
Configured Rollback Time = 45:00
Automatic Rollback Time = 38:30
Switch# issu acceptversion 2 bootflash:new_image
% Rollback timer stopped. Please issue the commitversion command.
Switch# show issu rollback-timer
Rollback Process State = Not in progress
Configured Rollback Time = 45:00
Loading New Cisco IOS Software on the New Standby Supervisor Engine
This task explains how to load new version of Cisco IOS software to the new standby supervisor engine.
Perform this task at the active supervisor engine:
Step 1
Command or Action
Purpose
Switch> enable
Step 2
Step 3
Step 4
5-24
OL-25340-01
Chapter 5
This example shows how to reset and reload the current standby supervisor engine (slot 1) with the new
Cisco IOS software version. After entering the commitversion command, the standby supervisor engine
boots in the Standby Hot state.
Switch> enable
Switch# issu commitversion 1 slavebootflash:new_image
Wait till standby supervisor is reloaded with the new image. Then apply the following:
Switch# show redundancy states
00:17:12: %RF-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary
Unit ID = 2
=
=
=
=
=
240000 milliseconds
9000 milliseconds
0
18
0x0
=
=
=
=
41 minutes
1
1
user forced
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
Stateful Switchover
Stateful Switchover
Disabled
Up
5-25
Chapter 5
=
=
=
=
=
=
=
=
2
Active
Init
bootflash:new_image,12;bootflash:old_image,1;
Stateful Switchover
N/A
N/A
bootflash:new_image
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
1
Standby
Init
bootflash:new_image,12;bootflash:old_image,1;
Stateful Switchover
N/A
N/A
bootflash:new_image
The ISSU process has been completed. At this stage, any further Cisco IOS software version upgrade or
downgrade requires that a new ISSU process be invoked.
Prerequisites
Ensure that the new version of Cisco IOS software image is already present in the file system of both
the active and standby supervisor engines. Also ensure that appropriate boot parameters (BOOT
string and config-register) are set for the active and standby supervisor engines
Optionally, perform additional tests and commands to determine the current state of peers and
interfaces for later comparison.
Ensure the system (both active and standby supervisor engines) is in SSO redundancy mode. If the
system is in RPR mode, you can still upgrade the system using the ISSU CLI commands, but the
system will experience extended packet loss during the upgrade.'
Refer to the Stateful Switchover document for more details on how to configure SSO mode on
supervisor engines (refer to Chapter 9, Configuring Supervisor Engine Redundancy Using RPR
and SSO on Supervisor Engine 6-E and Supervisor Engine 6L-E).
For ISSU to function, the IOS XE software image file names on the active and standby supervisor
engines must match.
5-26
OL-25340-01
Chapter 5
Step 1
Command or Action
Purpose
Switch> enable
Step 2
Step 4
This example shows how to initiate an ISSU upgrade process using the issu changeversion command on
slot number 5, the slot for the current active supervisor engine. The show issu state detail and show
redundancy command output is included to show the supervisor state before and after the upgrade
procedure.
Note
The success messages included in the output below is displayed after some delay because the ISSU
upgrade procedure progresses through the ISSU states.
Switch> enable
Switch# show issu state detail
Slot
RP State
ISSU State
Operating Mode
Current Image
Pre-ISSU (Original) Image
Post-ISSU (Targeted) Image
=
=
=
=
=
=
=
5
Active
Init
Stateful Switchover
bootflash:x.bin
N/A
N/A
5-27
Chapter 5
Slot
RP State
ISSU State
Operating Mode
Current Image
Pre-ISSU (Original) Image
Post-ISSU (Targeted) Image
=
=
=
=
=
=
=
6
Standby
Init
Stateful Switchover
bootflash:x.bin
N/A
N/A
=
=
=
=
12 minutes
0
0
none
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
Stateful Switchover
Stateful Switchover
Disabled
Up
Note
.....
.....
*Feb 25 20:41:00.479: %INSTALLER-7-ISSU_OP_SUCC:
'issu runversion'
5-28
OL-25340-01
Chapter 5
Switchover occurs.
Note
......
......
Note
The new standby supervisor reloads with target image; changeversion is successful upon SSO
terminal state is reached.
=
=
=
=
=
=
=
6
Active
Init
Stateful Switchover
bootflash:y.bin
N/A
N/A
Slot
RP State
ISSU State
Operating Mode
Current Image
Pre-ISSU (Original) Image
Post-ISSU (Targeted) Image
=
=
=
=
=
=
=
5
Standby
Init
Stateful Switchover
bootflash:y.bin
N/A
N/A
=
=
=
=
12 minutes
0
0
none
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
Stateful Switchover
Stateful Switchover
Disabled
Up
5-29
Chapter 5
This example shows how to use issu changeversion with the at command option to schedule an ISSU
upgrade procedure to automatically start at the specified time. This example specifies that the ISSU
upgrade should be started at 16:30 (24 hour format). The show issu state detail and show redundancy
command output is included to show the supervisor state before and after the issu changeversion
command was entered.
Switch> enable
Switch# show issu state detail
Slot
RP State
ISSU State
Operating Mode
Current Image
Pre-ISSU (Original) Image
Post-ISSU (Targeted) Image
=
=
=
=
=
=
=
5
Active
Init
Stateful Switchover
bootflash:x.bin
N/A
N/A
Slot
RP State
ISSU State
Operating Mode
Current Image
Pre-ISSU (Original) Image
Post-ISSU (Targeted) Image
=
=
=
=
=
=
=
6
Standby
Init
Stateful Switchover
bootflash:x.bin
N/A
N/A
=
=
=
=
12 minutes
0
0
none
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
Stateful Switchover
Stateful Switchover
Disabled
Up
5-30
OL-25340-01
Chapter 5
5
Active
Init
= TRUE
Stateful Switchover
bootflash:x.bin
N/A
N/A
Slot =
RP State =
ISSU State =
Changeversion
Operating Mode =
Current Image =
Pre-ISSU (Original) Image =
Post-ISSU (Targeted) Image =
6
Standby
Init
= TRUE
Stateful Switchover
bootflash:x.bin
N/A
N/A
Note
If you enter the issu abortversion command before the standby supervisor engine becomes hot, the
traffic might be disrupted.
5-31
Chapter 5
If you abort the process after you enter the issu loadversion command, the standby supervisor engine is
reset and reloaded with the original software.
If the process is aborted after you enter either the issu runversion or issu acceptversion command, then
a second switchover is performed to the new standby supervisor engine that is still running the original
software version. The supervisor engine that had been running the new software is reset and reloaded
with the original software version.
Note
Ensure that the standby supervisor engine is fully booted before entering the abortversion command on
an active supervisor engine.
The following task describes how to abort the ISSU process before you complete the ISSU process with
the issu commitversion command.
Perform the following task on the active supervisor engine:
Command or Action
Purpose
Step 1
Switch> enable
Step 2
This example shows how to abort the ISSU process on slot number 2, the slot for the current active
supervisor engine:
Switch> enable
Switch# issu abortversion 2
Note
The valid timer value range is from 0 to 7200 seconds (two hours). A value of 0 seconds disables the
rollback timer.
Once you are satisfied that the ISSU process has been successful and you want to remain in the current
state, you must indicate acceptance by entering the issu acceptversion command, which stops the
rollback timer. Entering the issu acceptversion command is extremely important in advancing the ISSU
process.
5-32
OL-25340-01
Chapter 5
Entering the issu commitversion command at this stage is equal to entering both the issu acceptversion
and the issu commitversion commands. Use the issu commitversion command if you do not intend to
run in the current state now and are satisfied with the new software version.
Note
The rollback timer can be configured only in the ISSU Init state.
Perform this task to configure the rollback timer:
Step 1
Command or Action
Purpose
Switch> enable
Step 2
Step 3
Step 4
Switch(config)# exit
Step 5
This example shows how to set the rollback timer to 3600 seconds:
Switch> enable
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# issu set rollback-timer 3600
% Rollback timer value set to [ 3600 ] seconds
Switch(config)# exit
Switch# show issu rollback-timer
Rollback Process State = Not in progress
Configured Rollback Time = 60:00
The rollback timer cannot be set in LV state, as the following example illustrates:
Switch# show issu state detail
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
1
Active
Load Version
bootflash:old_image,12
RPR
bootflash:old_image
bootflash:new_image
bootflash:old_image
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
2
Standby
Load Version
bootflash:new_image,12;bootflash:old_image,12
RPR
bootflash:old_image
bootflash:new_image
bootflash:new_image
5-33
Chapter 5
Step 1
Command or Action
Purpose
Switch> enable
Step 2
This example shows how to display negotiated information regarding the compatibility matrix:
Switch> enable
Switch# show issu comp-matrix negotiated
CardType: WS-C4507R(112), Uid: 2,
Image Name: cat4500-ENTSERVICES-M
Cid
Eid
Sid
pSid
pUid
Compatibility
=======================================================
2
1
262151 3
1
COMPATIBLE
3
1
262160 5
1
COMPATIBLE
4
1
262163 9
1
COMPATIBLE
5
1
262186 25
1
COMPATIBLE
7
1
262156 10
1
COMPATIBLE
8
1
262148 7
1
COMPATIBLE
9
1
262155 1
1
COMPATIBLE
10
1
262158 2
1
COMPATIBLE
11
1
262172 6
1
COMPATIBLE
100
1
262166 13
1
COMPATIBLE
110
113
262159 14
1
COMPATIBLE
200
1
262167 24
1
COMPATIBLE
2002
1
UNAVAILABLE
2003
1
262185 23
1
COMPATIBLE
2004
1
262175 16
1
COMPATIBLE
2008
1
262147 26
1
COMPATIBLE
2008
1
262168 27
1
COMPATIBLE
5-34
OL-25340-01
Chapter 5
2010
2012
2021
2022
2023
2024
2025
2026
2027
2028
2054
2058
2059
2067
2068
2070
2071
2072
2073
2077
2078
2079
2081
2082
2083
2084
4001
4002
4003
4004
4005
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
101
201
301
401
1
262171
262180
262170
262152
262169
262154
262179
262153
196638
262145
262178
262162
262177
262165
196637
262176
262150
262161
262184
262183
262181
262164
262182
262146
262149
32
31
41
42
8
29
30
12
40
21
11
28
33
35
34
36
37
39
20
38
17
18
19
22
4
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
UNAVAILABLE
UNAVAILABLE
UNAVAILABLE
UNAVAILABLE
UNAVAILABLE
UNAVAILABLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
negotiate
negotiate
negotiate
negotiate
negotiate
negotiate
negotiate
5-35
Chapter 5
2059
2067
2068
2070
2071
2072
2073
2077
2078
2079
2081
2082
2083
2084
4001
4002
4003
4004
4005
1
1
1
1
1
1
1
1
1
1
1
1
1
1
101
201
301
401
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
262179
262153
196638
262145
262178
262162
262177
262165
196637
262176
262150
262161
262184
262183
262181
262164
262182
262146
262149
30
12
40
21
11
28
33
35
34
36
37
39
20
38
17
18
19
22
4
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
List of Clients:
Cid
Client Name
Base/Non-Base
================================================
2
ISSU Proto client
Base
3
ISSU RF
Base
4
ISSU CF client
Base
5
ISSU Network RF client
Base
7
ISSU CONFIG SYNC
Base
8
ISSU ifIndex sync
Base
9
ISSU IPC client
Base
10
ISSU IPC Server client
Base
11
ISSU Red Mode Client
Base
100
ISSU rfs client
Base
110
ISSU ifs client
Base
200
ISSU Event Manager clientBase
2002
CEF Push ISSU client
Base
2003
ISSU XDR client
Base
2004
ISSU SNMP client
Non-Base
2008
ISSU Tableid Client
Base
2010
ARP HA
Base
2012
ISSU HSRP Client
Non-Base
2021
XDR Int Priority ISSU cliBase
2022
XDR Proc Priority ISSU clBase
2023
FIB HWIDB ISSU client
Base
2024
FIB IDB ISSU client
Base
2025
FIB HW subblock ISSU clieBase
2026
FIB SW subblock ISSU clieBase
2027
Adjacency ISSU client
Base
2028
FIB IPV4 ISSU client
Base
2054
ISSU process client
Base
2058
ISIS ISSU RTR client
Non-Base
2059
ISIS ISSU UPD client
Non-Base
2067
ISSU PM Client
Base
2068
ISSU PAGP_SWITCH Client Non-Base
2070
ISSU Port Security clientNon-Base
2071
ISSU Switch VLAN client Non-Base
2072
ISSU dot1x client
Non-Base
2073
ISSU STP
Non-Base
2077
ISSU STP MSTP
Non-Base
2078
ISSU STP IEEE
Non-Base
2079
ISSU STP RSTP
Non-Base
2081
ISSU DHCP Snooping clientNon-Base
2082
ISSU IP Host client
Non-Base
2083
ISSU Inline Power client Non-Base
5-36
OL-25340-01
Chapter 5
2084
4001
4002
4003
4004
4005
ISSU
ISSU
ISSU
ISSU
ISSU
ISSU
This example shows how to display stored information regarding the compatibility matrix:
Switch# show issu comp-matrix stored
Number of Matrices in Table = 1
(1) Matrix for cat4500-ENTSERVICES-M(112) - cat4500-ENTSERVICES-M(112)
==========================================
Start Flag (0xDEADBABE)
My Image ver:
Peer Version
-----------12.2(31)SGA5
12.2(44)SG
12.2(31)SGA6
12.2(31)SGA7
12.2(46)SG
12.2(44)SG1
12.2(31)SGA8
12.2(50)SG
12.2(31)SGA9
12.2(50)SG1
12.2(50)SG2
12.2(52)SG
12.2(31)SGA10
12.2(50)SG3
12.2(53)SG
12.2(53)SG
Compatibility
------------Base(2)
Base(2)
Base(2)
Base(2)
Base(2)
Base(2)
Base(2)
Dynamic(0)
Base(2)
Dynamic(0)
Dynamic(0)
Dynamic(0)
Base(2)
Dynamic(0)
Comp(3)
Dynamic(0) was introduced in Cisco IOS Release 12.2(50)SG with the Dynamic Image Version
Compatibility (DIVC) feature. With DIVC, Dynamic(0) is stored instead of Incomp(1), Base(2), or
Comp(3). Compatibility is determined during runtime when two different DIVC-capable images are
running in the active and standby supervisor engines during ISSU.
For Catalyst 4500 switches, a value of Dynamic(0) in the stored compatibility-matrix normally results
in Base(2) or Comp(3) upon rollback negotiation between the two images. You never observe Incomp(1)
as long as the other image name is present in the stored compatibility matrix.
5-37
Chapter 5
Command or Action
Purpose
Step 1
Switch> enable
Step 2
Note
Step 3
This example shows how to display negotiated information regarding the compatibility matrix:
Switch> enable
Switch# show issu comp-matrix negotiated
CardType: WS-C4507R-E(182), Uid: 4,
Image Name: cat4500e-UNIVERSALK9-M
Cid
Eid
Sid
pSid
pUid
Compatibility
=======================================================
2
1
131078 3
3
COMPATIBLE
3
1
131100 5
3
COMPATIBLE
4
1
131123 9
3
COMPATIBLE
.....
.....
Message group summary:
Cid
Eid
GrpId
Sid
pSid
pUid
Nego Result
=============================================================
2
1
1
131078 3
3
Y
3
1
1
131100 5
3
Y
4
1
1
131123 9
3
Y
.....
.....
List of Clients:
Cid
Client Name
Base/Non-Base
================================================
2
ISSU Proto client
Base
3
ISSU RF
Base
4
ISSU CF client
Base
.....
.....
5-38
OL-25340-01
Chapter 5
This example shows how to display stored information regarding the compatibility matrix:
Switch# show issu comp-matrix stored
Number of Matrices in Table = 1
(1) Matrix for cat4500e-ENTSERVICESK9-M(182) - cat4500ex-ENTSERVICESK9-M(182)
==========================================
Start Flag (0xDEADBABE)
My Image ver:
Peer Version
-----------03.01.00.SG
03.01.00.SG
Compatibility
------------Comp(3)
Switch#
With Dynamic Image Version Compatibility (DIVC), Dynamic(0) is stored instead of Incomp(1),
Base(2), or Comp(3). Compatibility is determined during runtime when two different DIVC-capable
images are running in the active and standby supervisor engines during ISSU.
For Catalyst 4500 switches, a value of Dynamic(0) in the stored compatibility-matrix normally results
in Base(2) or Comp(3) upon run-time negotiation between the two software images. You never observe
Incomp(1) as long as the other image name is present in the stored compatibility matrix.
This example shows how to display negotiated information regarding non-IOSd clients:
Switch# show package compatibility
PackageName
PeerPackageName
ModuleName
------------------------- -------------------------------rp_base
rp_base
aaa
rp_base
rp_base
aaacommon
rp_base
rp_base
access_policy
rp_base
rp_base
app_sess
rp_base
rp_base
app_sess_ios
rp_base
rp_base
auth_mgr
......
......
Compatibility
------------COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
COMPATIBLE
Related Documents
Related Topic
Document Title
Performing ISSU
Stateful Switchover
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/sso120s.
html
5-39
Chapter 5
Related Documents
5-40
OL-25340-01