Cisco 4500X IOS upgrade through ISSU

Question

Hi,
I am having 2 number of cisco 4500x switch and configured with VSS
so one switch is active and another switch is standby.
I am panning to upgrade IOS through ISSU
i read in document that it required auto boot enable in switch.
My switch current Configuration register = 0x2101
do i need to change config register or this will ok. If need to change then what will be auto boot and after IOS upgrade do i need to change it again.
Please help....

Answer 1

Hello Tarun,
Please find below the steps to perform the ISSU:
ISSU Prerequisites
Before one can perform an ISSU, there are a few prerequisites one must verify for a successful ISSU. The following list explains what is initially required.
• Must be using a redundant Cisco Catalyst 4500 switch with symmetric hardware (that is, supervisors, memory, rommon, NFL daughter card, and so on).
• Both new and old Cisco IOS Software images must be preloaded to the file system on both supervisors.
• SSO must be configured and working properly.
• Config register must be configured to autoboot (that is, the value should have a "2" in the lowest byte).
45010R-203# sh bootvar | i register
Configuration register is 0x2102
Standby Configuration register is 0x2102
Several commands are available to verify if SSO is enabled:
4510R-203# sh module | b Redundancy
Mod  Redundancy role     Operating mode      Redundancy status
----+-------------------+-------------------+-------------------
 1   Standby Supervisor   SSO                  Standby hot        
 2   Active Supervisor    SSO                 Active
45010R-203# sh redundancy states 
       my state = 13 -ACTIVE 
     peer state = 8   -STANDBY HOT 
           Mode = Duplex
           Unit = Secondary
        Unit ID = 2
Redundancy Mode (Operational) =  Stateful Switchover
Redundancy Mode (Configured)  =  Stateful Switchover
Redundancy State              =  Stateful Switchover
             <snip>
4507R-ISSU# sh run | b redundancy
redundancy
 mode  sso
As a step prior to the beginning of the ISSU process, the new version of the Cisco IOS Software image needs to be loaded into both the active and standby supervisors' file systems. Both active and standby supervisor need to contain both the new and old images in the file system. In order to store both new and old images, the supervisors should be upgraded to contain sufficient amounts of flash memory prior to the ISSU process.
The new images can be downloaded into both supervisors using commands such as:
copy tftp: bootflash:
copy tftp: slavebootflash: 
The example below illustrates this verification:
4510R-203#dir
Directory of bootflash:/
1  -rwx 13636500 Sep 6 2006 03:18:58 -08:00 cat4500-entservices-mz.122-31.SGA
2  -rwx 13747611 Sep 9 2006 03:19:58 -08:00 cat4500-entservices-mz.122-31.SGA1
4510R-203#dir slavebootflash:
Directory of slavebootflash:/
1  -rwx 13636500 Sep 6 2006 03:18:58 -08:00 cat4500-entservices-mz.122-31.SGA
2  -rwx 13747611 Sep 9 2006 03:19:58 -08:00 cat4500-entservices-mz.122-31.SGA1 
Once this check is verified, one can now proceed with the ISSU process.
The ISSU process is started by typing the "issu loadversion" command on the active supervisor. This command directs the active supervisor to begin the ISSU process. The active supervisor, through intersupervisor communications, checks that the requested image has been downloaded into both the active and standby supervisors' file systems. If the required images are not present, the command is rejected, and an appropriate warning is generated.
If the "issu loadversion" command is successful, the switch transitions into the "Load Version" ISSU state. The standby supervisor will reset and boot with the new version of the Cisco IOS Software image loaded into the file system.
The following actions take place when the command is implemented:
1. The standby supervisor (B) is reset.
2. The standby supervisor (B) is booted with the new Cisco IOS Software image: Release 12.2(31)SGA1.
3. If both Cisco IOS Software images are declared as compatible, the standby supervisor moves into SSO mode and is fully stateful for all compatible clients and applications. Compatibility allows for in-service software upgrade or downgrade between two versions to succeed with minimal service effect.
4. If both Cisco IOS Software images are incompatible, the system moves into RPR mode, and the ISSU process is terminated with an appropriate message to the user. Images are declared incompatible when "required" clients or applications are not interoperable between two Cisco IOS Software releases.
5. Standby "B" reaches the standby HOT state.
6. The user has an option to abort the ISSU process by issuing the "issu abortversion" command.
7. The "issu loadversion" command also supports a "forced" option that allows the operator to force the system into entering RPR mode when incompatibility is detected.
Note: When performing an ISSU, disable manual switchovers. Performing manual switchovers during the issu process is strongly discouraged. The current implementation does not prevent it, but it does display a warning to the user.
An example of the CLI for implementing the issu loadversion command is displayed below.
On the active supervisor, one would issue the following command:
4510R-203#issu loadversion 1 bootflash:cat4500-entservices-mz.122-31.SGA1 2 slavebootflash: cat4500-entservices-mz.122-31.SGA1
Syntax - issu loadversion active-slot active-image-new standby-slot standby-image-new
The second step of the ISSU process is to perform the issu runversion CLI.
The user can issue the " issu runversion" command when:
1. The ISSU state is "Load Version"; this can be verified with the "show issu state detail" CLI.
2. The standby supervisor is running the new version of the software.
3. The standby supervisor has moved into the "Standby Hot " state.
The following actions take place when the " issu runversion" command is executed:
1. A switchover occurs; that is, the standby (B) becomes the new active, and the old active (A) is rebooted and comes up as a standby.
2. A timer called "Rollback Timer" is started with a previously configured value.
3. Move both supervisors to "Run Version" state.
4. If the command "issu acceptversion" is not issued before the "Rollback timer" fires, then the entire ISSU process is aborted via the automatic rollback.
5. If the active supervisor console connectivity is established and the "issu acceptversion" command is issued, then the rollback timer is stopped.
6. The user has an option to abort the ISSU process by issuing the "issu abortversion" command.
An example of the CLI for implementing the issu runversion command is displayed below:
On the active supervisor, one would issue the following command:
4510R-203#issu runversion 2 slavebootflash:cat4500-entservices-mz.122-31.SGA1
Syntax - issu runversion standby-slot [standby-image-new]
Prior to issuing the `issu acceptversion' command the system will be counting down the rollback timer. If `issu acceptversion' is not completed before rollback timer expires an automatic abort will occur. This command stops the "Rollback Timer." This command serves as a feedback mechanism. This is an optional command and can be skipped in the ISSU process with the "issu commitversion" CLI.
If this command is not issued within 45 minutes (default) from the time the standby supervisor moves into the "Standby Hot" state, it is assumed that the new active supervisor is not reachable and the entire ISSU process is rolled back to the previous version of the software. The acceptversion is not intended for long-term network operation. It is also important to note that none of the features available on the new version will work yet.
The following actions take place when the command is implemented:
1. The "Rollback Timer" is terminated. This means that the rollback timer is not looked at anymore. Therefore, the system can run in this state for an extended period.
2. The user has an option to abort the ISSU process by issuing the command "issu abortversion."
Aborting the ISSU process now causes the newly active supervisor (B) to fail over to the standby supervisor (A) running the old image and will also cause the rebooting supervisor (B) to load the original image. The issu acceptversion halts the rollback timer and helps ensure the ISSU process is not automatically aborted during the process.
An example of the CLI for implementing the issu acceptversion command is displayed below:
On the "New" active supervisor, one would issue the following command:
4510R-203#issu acceptversion 2
% Rollback timer stopped. Please issue the commitversion command.
Syntax - issu acceptversion active-slot-number
This is the last stage of the ISSU procedure. Once the user is satisfied with the new version of software, this must be committed by issuing the "issu commitversion" command. This command resets the standby supervisor and boots it with a new version of the software (same as the active supervisor). This concludes the ISSU process, and the new version of software is permanently committed on both supervisors. Since this is the conclusion of the ISSU process, the system can not be reverted back to the previous version of the software from this point onward as a part of this upgrade cycle. However, if for any reason users wish to go back to the previous version of the software, they can do so by starting a new upgrade/downgrade process.
The following actions take place if the command is implemented:
1. The standby supervisor (A) is reset and booted with the new version of Cisco IOS Software image.
2. The standby supervisor (A) moves into the "Standby Hot" state in SSO mode and is fully stateful for all clients/applications that are compatible.
3. Both supervisors are moved into "Final State," which is the same as "Initial State."
4. Users can initiate switchovers from this point onward.
An example of the CLI for implementing the issu commitversion command is displayed below:
4510R-203#issu commitversion 1
Syntax - issu commitversion standby-slot-number
ISSU Process: issu abortversion
One can abort the ISSU process at any stage manually (prior to issuing the issu commitversion command) by issuing the exec-level issu abortversion command. The ISSU process also aborts on its own if the software detects a failure.
If a user aborts the process after issuing the issu loadversion command, then the standby supervisor engine is reset and reloaded with the original software.
If the process is aborted after a user enters 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. The command is accepted only in "Load Version" or "Run Version" states. In "Load Version" state, the active supervisor is running an old image and the standby supervisor is running new image.
Syntax - issu abortversion active-slot [active-image-new]
Let me know if you have any questions.