Upgrade WLC in HA SSO does not work

[Martin Simek]

Hello,
we have two WLC-5520 in HA SSO. In AireOS version 8.10.112.0 and 8.10.121.0 it is not possible to upgrade using standard procedure (see screenshot).
I have never seen this message. The only functional upgrade of WLC HA SSo is manual. First, restart the backup peer using "reset system peer" and then active WLC using "reset system self forced". It's not an ideal procedure, but it works.
I think it's a bug.

Regards,

Martin Simek

[Scott Fella]

Have you tried reset system in? Look at this guide.

https://www.rogerperkin.co.uk/wireless/upgrade-cisco-5508-ha-wlc/

[Leo Laohoo]

The commands are not the same.
The screenshot says you're scheduling both units to reboot in 10 minutes.
The workaround says you want to reboot now.
What happened when you try to schedule a reboot using GUI?

[Martin Simek]

Hello everyone,
WLC HA SSO is newly built, because in version 8.8.125.0 we encountered the CSCvs37305 bug. That is why we have moved to version 8.10 after agreement with the supplier.
The scheduled system reset cannot be done from either the CLI or the GUI. Only instant reset from both CLI and GUI works.

[Scott Fella]

Open a TAC case and see if there is a bug or if they will file one. To be honest, I never schedule a reset and walk away... I monitor the reboot from the console because I have seen when the standby have never rebooted with the image and both goes into maintenance mode. Once I see the primary is booting up and the secondary doesn’t, then I issue a reset on the secondary from the console.

[Leo Laohoo]

I am with Scott.
I never schedule a reboot (of a WLC) and walk away.
I monitor the console output to both unit all the time.

[Rich R]

And I'll third that to Scott and Leo.

But I decided to do a bug search anyway ...

So it turns out somebody got a bug raised for the problem in 8.10.112.0 a few weeks ago https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt33091 (you can't see what it says directly because it's dup'd to another one but if you search "reset system both in" for Model "Cisco 5500 Series Wireless Controllers" you'll be able to see it in the results).  The workaround is a classic "Don't use 8.10" - ROFL - some TAC engineers and developers!  Anyway it's dup'd to https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvo46081 which is supposedly fixed in 8.10.112.0 & 8.10.121.0 but the workaround there is "Do not schedule the WLC reload instead use the command reset system both".  If you really feel you want to schedule the reload (which others of us do not recommend) then suggest you open a TAC case but it's looks to me like that option is now prohibited.  I suspect that in fact the 'fix' is that they do not allow scheduled reload anymore in which case the bug notes should be updated to explain that and documentation and release notes should be updated to show that too.

Regards

Rich

[Martin Simek]

Thank you all for your quick response.
I used a "system reset at" because it is a recommended procedure to minimize wireless network downtime according to the documentation. I planned a restart, but I didn't walk away. I watched the whole upgrade process.
Therefore, I was surprised that in version 8.10 this option was disabled, although the documentation still refers to it. So I will only use "reset system both". Perhaps someone will update the documentation in the future.
What do you think is the recommended procedure for upgrading WLC SSO HA to minimize wireless network downtime? When I read the documentation, so
1. Upload a new image.
2. AP pre-download and swap image.
3. Reset peer WLC peer.
4. After one minute reset active WLC (basically simulation "reset system at/in" according to documentation).

It seems to me that "reset system both" will cause both WLCs to restart immediately.

Regards,

Martin

[patoberli]

As stated, I do step 1+2. Once they are done, I click reset system in the waiting interface from step 1.
I do the AP pre-download via CLI, but the image upgrade via web interface. The web interface will then (normally) correctly reset both appliances.

[Scott Fella · Accepted solution]

To add, I follow the first couple steps, but I will reboot the primary first and wait like 10-30 seconds and then restart the secondary. This way I can control which controller is the primary. You will have a downtime so just allocate that time to make sure all your AP’s are up and you see clients connected. I typically allocate one hour so I have fluff time in case something goes wrong. I also do everything from the console just in case.