We are planning software upgrade of WiSM in our WiFi environment. We have two 6500 series chassis loaded with 5 WiSMs' each. In that, 1 chassis is acting as primary and 1 chassis is acting as secondary. The WiSMs are fully loaded with access points. I need suggestion on whether to upgrade WiSMs' in redundant chassis first or the ones in primary chassis first.
- Lets consider, I finished upgrading WiSMs' in redundant chassis, when they are empty. Then When I upgrade Primary chassis WiSMs' and reload them, The APs will failover to redundant chassis's WiSMs. Then APs will try to upgrade them with new version. Meanwhile the Primary Chassi's WiSMs come up after booting with new image. AP fall back is enabled.
- Whether the AP will try to fallback to primary WiSM, when it is in downloading image stage in secondary chassis? or the AP will not fallback until completion of downloading and registration process in secondary controller?
Madhan kumar G
From what version and to what version are you doing this?
I agree with Scott and George. This is also what I've been doing.
1. Upgrade the firmware and bootstrap of the secondary WiSM.
2. Move all the WAPs to the secondary. (Several ways of doing this. Primarily if you have WCS/NCS then this is the way to go. If you don't then either disable or BLOCK the allowed VLAN to your Management address from your primary WiSM chassis. This will forcefully send the WAPs to the secondary WiSM.)
3. Once you have confirmed that all the WAPs are fully accounted for, then upgrade the firmware and bootstrap of the primary WiSM.
4. IF you don't have WCS/NCS then enable the Management VLAN.
If you have "pre-download" option, then this will save you time.
Another thing is this: Newer IOS of the 7.0.X have the option to schedule the reboot of your WiSM. So maybe you can enable this option.
We had a case where a site didn't like it that we are going to bring the WAPs down due to firmware upgrades (because the network admin of that site would go "ape" about his precious laptops not joining) so what we did was enable EnergyWise and disabled PoE to the WAP ports. We upgraded the firmware and bootstrap and enabled the PoE ports 4 am in the morning. He didn't knew what "hit" him.
Here are a few things a learned.
1) Push the code to the controllers when there is less folks on the wireless. When the code unpacks on the WLC you will see some aps lose connection to the controllers. This is known (among people who pay close attention to their logs), but not widely if at all documented. The aps lose their capwap connection for a second or so. Its like a blip to the user
2) Do the predownload process hours before your actual cut over time. It can take a full wism 300 aps like and hour or more to predownload the new code.
3) Code Swap on the wlc and ap. Read my blog post carefuly.
If you dont have the software in the right position you could indeed cause the aps to download code again after your reboot.
So make sure you swap the ap code and the controller code correctly before reboot! Also if you predownload the code to the WLC and APs well in advance of the upgrade. Make sure you put the codes in the backup on the wlc and aps. If not, and a wlc accidentally reboots you will have a little problem on your hands.
4) Make sure you reboot all the WLCs at the same time. Use the config system reset at command in the cli or in the GUI. Make sure your wlcs all have the same time before doing this.
If you do all the above you will be out for only 3 minutes ..
Scott suggestion is one way of doing it. Thats how I use to do it actually.
But I use ap predownload. It saves a ton of time, since the WISM is limted to how many aps it can upgrade at a time. You can be sitting for a good bit waiting for aps to upgrade.
I have a large enviroment and i have 3000 aps down and up in 3 minutes with ap predownload.
If you push the code to the WLC you can then push the code to the APs. When you reboot the controller they will all come up with the new code. No need to wait for downloading. No need for templates.