10-23-2020 08:40 AM
Is it possible to do an ISSU to 15.5.1-SY5 from 153-1.SY2? Both units have dual C6800-SUP6T and everything downstream is dual-homed.
If not, has anyone done this upgrade and might be able to advise what kind of outage can be expected for the switches and FEXs?
10-23-2020 08:45 AM
Take a look at one of the Good thread - reently posted in community - look last post how he able to resolved.
https://community.cisco.com/t5/cisco-software-discussions/cisco-6807-vss-upgrading/td-p/4015382
10-23-2020 05:09 PM - edited 10-15-2021 07:45 PM
WARNING:
DO NOT USE ISSU or FSU/eFSU if upgrading to 15.5(1)SY train on a 6807/6880 chassis.
IMPORTANT: Read the Release Notes very, very carefully.
Pay very, very close attention to the "Performing FPGA Upgrade" section. There are three things everyone must be aware warned of:
1. You will need console access or line cards will not boot.;
2. For unknown reason, the line cards needs to have an FPGA upgrade done MANUALLY. This can only be done once the new IOS gets loaded. This FPGA upgrade is not "incorporated" in the IOS.
3. The command to do the FPGA upgrade is a "bug". For VSS, the command is:
upgrade winters-flash switch switch-number slot <slot-number> bundled-image GOLD
For stand-alone, the command is:
upgrade winters-flash slot <slot-number> bundled-image GOLD
See the last option, "GOLD"? That option is HIDDEN and the fact that it is a hidden option is not documented anywhere else.
And one final thing, ISSU or FSU/eFSU does not support FGPA Upgrade.
Use the tried-and-tested method:
Once the reboot is complete, there will be some line cards that will "refuse" to boot up. If a console cable is attached before rebooting the chassis there will be a "large" message stating that FPGA upgrade must be done, however, the command to do the FPGA upgrade is not mentioned. The time it will take, after the panic has wane, to find the flippin' FPGA upgrade command will obviously run into an hour or two.
NOTE:
10-26-2020 02:23 PM
Thanks for the information. This would still be disruptive correct since the line cards would be done? Would I still be rebooting 1 6807 at a time or still the entire chassis? I was planning on following this if it had to be disruptive:
copy disk0:/tftp:s6t64-adventerprisek9-mz.SPA.155-1.SY5.bin bootdisk
copy bootdisk:s6t64-adventerprisek9-mz.SPA.155-1.SY5.bin slavebootdisk:
config-register 0x2102
no boot system bootdisk:s6t64-adventerprisek9-mz.SPA.153-1.SY2.bin
no boot system slavebootdisk:s6t64-adventerprisek9-mz.SPA.153-1.SY2.bin
boot system bootdisk:s6t64-adventerprisek9-mz.SPA.155-1.SY5.bin
wr
show bootvar (to confirm the correct variable)
redundancy reload shelf
10-26-2020 03:06 PM
copy disk0:/tftp:s6t64-adventerprisek9-mz.SPA.155-1.SY5.bin bootdisk copy bootdisk:s6t64-adventerprisek9-mz.SPA.155-1.SY5.bin slavebootdisk: config-register 0x2102 no boot system bootdisk:s6t64-adventerprisek9-mz.SPA.153-1.SY2.bin no boot system slavebootdisk:s6t64-adventerprisek9-mz.SPA.153-1.SY2.bin
These make sense.
boot system bootdisk:s6t64-adventerprisek9-mz.SPA.155-1.SY5.bin
This one, however, does not. There is only one boot statement. This means that if this file fails to boot both chassis goes into ROMMON. Cover your a$$ and stick the old IOS after this line. That way, if either one of the chassis fails to boot the new IOS it will roll back to the next boot statement.
REMINDER: Make sure you have a console cable attached in case you need to do a manual FPGA upgrade.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: