Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Cat9600 standalone chassis with redundant SUP-1 supervisor modules will experience ISSU failure, if there is an FPGA upgrade triggered during the initial bootup with the new IOS-XE release. The original STANDBY supervisor will boot up with the new IOS-XE release and reach SSO state again. The switchover occurs, and the original ACTIVE supervisor boots up with the new IOS-XE release, but it never reaches the SSO state again. It will stay in the "in progress to standby cold-config" state for ~10 minutes with the Current client in progression pointing to "NGMOD HMS RF client (10101)" the entire time. This can be checked with the "show redundancy states" command. Switch#show redundancy states my state = 13 -ACTIVE peer state = in progress to standby cold-config Mode = Duplex Unit = Secondary Unit ID = 4 Redundancy Mode (Operational) = sso Redundancy Mode (Configured) = sso Redundancy State = sso Maintenance Mode = Disabled Manual Swact = disabled (peer unit not yet in terminal standby state) Communications = Up client count = 118 client_notification_TMR = 30000 milliseconds RF debug mask = 0x41 Current client in progression = NGMOD HMS RF client (10101) Time since client was sent progression (ms) = 560119 History for this client progression = RF_PROG_STANDBY_CONFIG, rc 0 Switch# The other symptom of this issue is that the slot containing the affected standby supervisor will report the idle PSM state instead of the ready state. This can be checked with the "show platform software iomd redundancy" command, and the same can be confirmed by reviewing IOSRP binary traces. Switch#show platform software iomd redundancy Configured Redundancy Mode = sso Operating Redundancy Mode = sso Local RF state = ACTIVE Peer RF state = STANDBY COLD-CONFIG slot PSM STATE SPA INTF HA_STATE HA_ACTIVE 1 ready started ready 00:05:23 2 ready started ready 00:05:23 3 idle 4 ready started ready 00:05:17 ***active RP 5 ready started ready 00:05:23 6 ready started ready 00:05:23 Switch# After the 10-minute timeout, the standby supervisor will get reloaded with the following messages: %RF-5-RF_RELOAD: Peer reload. Reason: NGMOD HMS RF client timeout %CMRP-3-RP_RESET: R0/0: cmand: RP is resetting : remote RP requested reset of this RP %IOSXE_OIR-6-OFFLINECARD: Card (rp) offline in slot R0 %REDUNDANCY-3-STANDBY_LOST: Standby processor fault (PEER_NOT_PRESENT) %REDUNDANCY-3-STANDBY_LOST: Standby processor fault (PEER_DOWN) %REDUNDANCY-3-STANDBY_LOST: Standby processor fault (PEER_REDUNDANCY_STATE_CHANGE) %RF-5-RF_RELOAD: Peer reload. Reason: EHSA standby down The standby supervisor will not be able to reach SSO/STANDBY HOT state and will reload again, and after 5 unsuccessful boots, it will stay in ROMMON mode.
C9606R standalone chassis with redundant C9600-SUP-1 supervisor modules ISSU upgrade between releases that involve an FPGA upgrade Please note -- This issue is applicable and seen only on standalone C9600 chassis with dual/redundant C9600-SUP-1 supervisor modules only & this issue is not applicable and not seen on C9600 chassis operating in stackwise-virtual and quad sup topologies
Workaround ==================== For ISSU upgrade from 17.3.1, 17.3.2, 17.3.3, or 17.3.4 to 17.6.x in standalone chassis with dual supervisor or high availability setup, you must perform an ISSU upgrade to 17.3.5 and then perform ISSU upgrade to the final target release version. ISSU upgrade to 17.9.1 might fail in standalone chassis with dual supervisor or high availability setup. If you want to upgrade to 17.9.1, follow the non-ISSU upgrade procedure in install mode. Recovery ==================== Interrupt the unsuccessful ISSU upgrade configure terminal service internal end clear install state This might be a disruptive action potentially involving reload of the ACTIVE supervisor, and there is no STANDBY supervisor in SSO/STANDBY HOT state to take over. Subsequent ISSU upgrades will be successful as long as no further FPGA upgrades are needed.
This problem will be seen when performing the ISSU upgrade from a release bundling the old FPGA version to a release bundling the new FPGA version for the first time, such as 17.3.x to 17.6.x or 17.3.x to 17.9.x or 17.6.x to 17.9.x