07-17-2018 06:19 AM - edited 03-08-2019 03:42 PM
Hello all,
I am trying to upgrade a 4500-x vss pair with ISSU to a newer IOS.
From cat4500e-universalk9.SPA.03.06.05.E.152-2.E5.bin to cat4500e-universalk9.SPA.03.06.08.E.152-2.E8.bin
All pre-checks come out ok, bootvar is set ok, Hardware, License(features) are all equal.
When running the first ISSU command:
issu loadversion 1 bootflash:cat4500e-universalk9.SPA.03.06.08.E.152-2.E8.bin 11 slavebootflash: cat4500e-universalk9.SPA.03.06.08.E.152-2.E8.bin
The standby node reloads and starts with this new IOS image.
After a few minutes the following error shows up on the console and the standby unit reloads and loads the old firmware:
%VSLP-5-VSL_UP: Ready for control traffic %VSLP-5-RPR_ROLE_RESOLVED: role resolved as STANDBY by VSLP %C4K_REDUNDANCY-2-IOS_VERSION_CHECK_FAIL: IOS version mismatch. Active supervisor version is 15.2(2)E5 (cat4500e-UNIVERSALK9-M). Standby supervisor version is 15.2(2)E8 (cat4500e-UNIVERSALK9-M). Redundancy feature may not work as expected. %C4K_REDUNDANCY-2-NON_SYMMETRICAL_REDUNDANT_SYSTEM: STANDBY:STANDBY supervisor will operate in fallback redundancy mode rpr. %C4K_REDUNDANCY-3-COMMUNICATION: STANDBY:Communication with the peer Supervisor has been established %C4K_REDUNDANCY-2-VS_REBOOT_ON_RPR_FALLBACK: STANDBY:Supervisor in virtual-switch configuration cannot operate in redundancy mode RPR, will be reset %RF-5-RF_RELOAD: STANDBY:Self Reload. Reason: Virtual-switch fallback to RPR %SYS-5-RELOAD: STANDBY:Reload requested by Platform redundancy manager. Reload Reason: Virtual-switch fallback to RPR. Message from sysmgr: Reason Code:[3] Reset Reason:Reset/Reload requested by [console]. [Reload command]
Am sort of at a loss here.. anyone got any ideas?
ps. also there are no MCL errors.
Solved! Go to Solution.
07-17-2018 09:06 AM
07-17-2018 09:06 AM
07-17-2018 11:51 PM
07-18-2018 10:14 PM
lesson learned.. check the compatibility matrix.
From 3.6.5 to 3.6.7 worked flawless, with the loss of just a few pings.
07-17-2018 03:52 PM
ISSU or FSU/eFSU doesn't working for everyone. Here's an alternative method:
1. Save the config.
2. Export the config to an external source.
3. Copy the IOS into the Active unit.
4. Copy the IOS into the Secondary unit.
5. Compare the MD5 hash value of the IOS (in both units) against the MD5 hash value found in the Cisco website.
6. Change the boot variable string so that the new IOS is loaded first and the old IOS is loaded when the first one fails to boot.
7. Make sure the config-registr value is correct: 0x2102
8. Save the config.
9. Reboot.
Don't forget to read the Release Notes.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide