Showing results for 
Search instead for 
Did you mean: 

4507 Sup 6-E Upgrade SSO vs RPR

Level 1
Level 1


I have a 4507 with dual sups 6-E. The chassis is configured for SSO. I upgraded from 15.2(2)E5 to 15.2(2)E8 by doing the following:

1-Loaded the new IOS in the bootflash & slavebootflash

2-Edited the boot system so it's pointing to the new IOS

3-Issued a redundancy reload peer to upgrade the standby Sup. 

4-After this, I received the following message: %C4K_REDUNDANCY-2-IOS_VERSION_CHECK_FAIL: IOS version mismatch. Active supervisor version is 15.2(2)E5 (cat4500e-ENTSERVICESK9-M). Standby supervisor version is 15.2(2)E8 (cat4500e-ENTSERVICESK9-M). Redundancy feature may not work as expected.

5-Redundandy mode went from SSO to RPR. So I decided to issue a redundancy force-switchover which of course caused a 2 min outage due to the RPR mode. 


Am I missing something as to why SSO mode is not maintained. Or is there a different process where I can reduce the downtime? I'm doing this in a maintenance window but I was under the impression SSO would keep its normal state.


7 Replies 7

Reza Sharifi
Hall of Fame
Hall of Fame


If you followed the procedure as it is outlined in this document, it should have worked with no issues.


Hi Reza,

I am not doing these steps:

Switch(config)# redundancy

Switch(config-red)# main-cpu

Switch(config-r-mc)# auto-syn standard

So far I've tried on 3 chassis and even though they are configured for SSO, I get the IOS mismatch log and then it stays in RPR. Before reloading the standby supervisor, I have checked that the bootvar is set up the same on both active & standby:

BOOT variable = bootflash:cat4500e-entservicesk9-mz.152-2.E8.bin,1;
CONFIG_FILE variable does not exist
BOOTLDR variable does not exist
Configuration register is 0x2102

Standby BOOT variable = bootflash:cat4500e-entservicesk9-mz.152-2.E8.bin,1;
Standby CONFIG_FILE variable does not exist
Standby BOOTLDR variable does not exist
Standby Configuration register is 0x2102


Can you add the first 3 commands for the next chassis and test again?


Supervisor Engine Redundancy Guidelines and Restrictions

The following guidelines and restrictions apply to supervisor engine redundancy:

If SSO mode cannot be established between the active and standby supervisor engines because of an incompatibility in the configuration file, a mismatched command list (MCL) is generated at the active supervisor engine and a reload into RPR mode is forced for the standby supervisor engine. Subsequent attempts to establish SSO, after removing the offending configuration and rebooting the standby supervisor engine with the exact same image, might cause the C4K_REDUNDANCY-2-IOS_VERSION_CHECK_FAIL and ISSU-3-PEER_IMAGE_INCOMPATIBLE messages to appear because the peer image is listed as incompatible. If the configuration problem can be corrected, you can clear the peer image from the incompatible list with the redundancy config-sync ignore mismatched-commands EXEC command while the peer is in a standby cold (RPR) state. This action allows the standy supervisor engine to boot in standby hot (SSO) state when it reloads.


reference :


***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Leo Laohoo
Hall of Fame
Hall of Fame

@erickalvarado wrote:

3-Issued a redundancy reload peer to upgrade the standby Sup. 

I think this is the cause why the supervisor cards are complaining of "version mismatch".  

NOTE:  I understand the need of "no impact" upgrade. 

In situations like this, I would still advocate the complete reboot of the chassis.  

I upgraded a pair of switches last night, and I added the following commands, and then saved the config. 

auto-sync standard

That did not really make a difference. After reloading the standby supervisor, it successfully came online with the new IOS. But I again received the mismatch error due to different IOS versions and the redundancy mode went from SSO to RPR. So when I reloaded the active supervisor, I took a ~2 minute outage while it switched over between active/standby. I guess I was thinking that I would expect SSO to stay operational even during the upgrade phase, but what I'm seeing is normal. 

@Leo Laohoo - If I were to reload the entire chassis, in your experience, is that better that reloading each supervisor card? Are there pros/cons for either way of reloading? I'm doing this in a maintenance window so I have no problem with downtime.  

If there is a way to power down/up both chassis, that is my preferred method.
Rebooting both chassis is also an alternative method.
Review Cisco Networking for a $25 gift card