5508 upgrade Flexconnect AP3702 and AP1602

[Thomasvdk]

Hi fellow community members,

Yesterday I did an upgrade of a 5508 WLC HA pair with only Flexconnext AP's (mix of 3702 and 1602 AP's) distributed all over Europe. We went from version 8.2.151 to 8.5.135. After the upgrade and before the reboot of WLC's I did an "ap image pre-download". Most of 3702 AP's completed this task, three 3702 AP's failed and all the1602 AP's didn't upgrade (1602 is supported in 8.5.135 following RN).

After reboot most 3702 AP's came up after a while. The three failed 3702  AP's and all the 1602 AP's stayed on status "downloading". After 75 minutes of no status change, we decided to rollback to 8.2.151. 

When the WLC's came up with version 8.2.151 the three failed 3702  AP's and all the 1602 AP's were immediately visible and it seemed these AP's didn't suffer any downtime from the upgrade. The uptime of these AP's was more than 80 days so they never rebooted.

My questions are:

1. How can I upgrade the 1602 AP's in a future upgrade plan?

2. The three failed image pre-download 3702 AP's. What's needed to get these working in a future upgrade plan? I've seen this behavior before and then a flash_init via console was needed. That's a bit difficult if the AP's are 2000km far in different places.

Thanks!

Regards,

Thomas

[Ric Beeching · Accepted solution]

Hi Thomas,

Firstly why not 8.5.140.0 which is recommended by TAC? Just curious...

With regards to the upgrade, you may be hitting this critical bug:

https://www.cisco.com/c/en/us/support/docs/field-notices/703/fn70330.html

With a fix being varied depending on severity. The WLAN Poller tool created by Cisco can check for the bugs and try to resolve (if you want it to) but this may strand the APs due to the flash error. So then you can try and power cycle them a few times to see if it resolves it or just replace them with spares. Occasionally affected APs can end up in rommon mode with this bug so that can be frustrating, I recommend you run the WLAN Poller tool before the upgrade in false mode to confirm if any APs are affected then decide how to proceed. Note: If you have on site support you could always spin up a TFTP server locally with the required boot image (same VLAN in 10.0.0.0/29 range) for a tech to do mode button recovery.

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/213317-understanding-various-ap-ios-flash-corru.html

[Thomasvdk]

Thanks! 8.5.140 should be used indeed but wasn't...