Need advice on Wireless upgrade of WiSM in redundant environment

Answered Question
Apr 22nd, 2012

Hi,

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?

Please suggest.

Regards,

Madhan kumar G

I have this problem too.
0 votes
Correct Answer by Leo Laohoo about 1 year 11 months ago

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. 

Correct Answer by George Stefanick about 1 year 11 months ago

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 ..

Correct Answer by George Stefanick about 1 year 11 months ago

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.

http://www.my80211.com/home/2011/2/20/wlc-predownload-the-image-to-the-access-points-from-the-cont.html

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (11 ratings)
Scott Fella Sun, 04/22/2012 - 05:31

I would upgrade the secondary, then after you reboot the WiSM, push a template or config to change the primary to the secondary WiSM. Only do a few first:). Once the APs upgrade the code and join successfully. You can then push the template or configuration to change the primary to the secondary. When you have all the APs moved, upgrade the primary and the you can move the APs back to the primary chassis WiSMs.

Sent from Cisco Technical Support iPhone App

Correct Answer
George Stefanick Sun, 04/22/2012 - 07:04

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.

http://www.my80211.com/home/2011/2/20/wlc-predownload-the-image-to-the-access-points-from-the-cont.html

madhankumar.g Sun, 04/22/2012 - 09:57

Hi George,

The suggestion shared by you really brought down my worries on downtime. I will plan my upgrade based on the suggestion shared by you. Thanks a lot.

Regards,

Madhan kumar G

Correct Answer
George Stefanick Sun, 04/22/2012 - 10:13

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 ..

Correct Answer
Leo Laohoo Sun, 04/22/2012 - 15:32

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. 

madhankumar.g Mon, 04/23/2012 - 00:12

Hi Leolaohoo,

I am upgrading from 7.0.98.0 to 7.0.116.0. Your idea on blocking management vlan in allowed vlan is good. Today I am planning for a small test on pre-download. I will let you all know the results.

Regards,

Madhan kumar G

Scott Fella Mon, 04/23/2012 - 03:28

You should look to upgrade to 7.0.230.0 since that fixes issues with the previous 7.0.x codes.

Thanks,

Scott Fella

Sent from my iPhone

George Stefanick Mon, 04/23/2012 - 06:27

Test make sure predownload will work with 7.0.98.0. I recall there was an issue with predownload on that rev. test it by pushing your new code and trying to predownload to a few aps. Report back if you have issues.

madhankumar.g Tue, 05/15/2012 - 00:29

Hi George,

Yeah, The upgrade went fine. However APs in each WiSM went into downloading images from controller, though predownload was done. As you said, there may be an issue with predownload in 7.0.98.0. Rest all were good.

Regards,

Madhan kumar G

Actions

Login or Register to take actions

This Discussion

Posted April 22, 2012 at 5:25 AM
Stats:
Replies:12 Avg. Rating:5
Views:1550 Votes:0
Shares:0

Related Content

Discussions Leaderboard