I have seen the APs jumping between WLCs running different code levels and downloading different codes during upgrade as well. Then I came out this upgrade procedure and it seems no more looping:
1. On WLCs management interface vlans, remove the ACL entries which permit APs to join the WLCs. 2. Download new codes to all WLCs from WCS at once. 3. Reboot all WLCs from WCS once. 4. Put the ACL entries back. Then you just watch the APs joining WLCs without looping. Cisco would suggest to shut down all wisms port channels during upgrade and do upgrade through service port. That is the same idea to prevent APs from joining WLCs before the upgrade finish. Dennis Xu Network Analyst Computing and Communication Services University of Guelph 5198244120 x 56217 ----- Original Message ----- From: "John Watters" <[email protected]> To: [email protected] Sent: Wednesday, August 5, 2009 10:34:09 AM GMT -05:00 US/Canada Eastern Subject: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193 Sorry, I meant to send this to the list. -jcw ------------------------------------- John Watters UA: OIT 205-348-3992 > -----Original Message----- > From: Watters, John > Sent: Wednesday, August 05, 2009 9:33 AM > To: 'Charles Spurgeon' > Subject: RE: [WIRELESS-LAN] WiSM 5.2.193 > > > I upgraded 18 WiSM controllers yesterday & last night that support ~2,000 > APs. I also experienced the delayed joins. > > In addition, I had APs joining controllers in other mobility groups. After > that it is very hard to get them to move back. (I had a little over 100 > APs join controllers in other mobility groups - about 5%.) > > In addition, I am seeing a lot of looping: When the WiSM controller > rebooted to do the code upgrade, all its APs joined another controller and > downloaded the code from that controller even though the controller they > came from was already running that version (in my case 5.2.178). Then they > tried to move back to their primary controller (now upgraded to 5.2.193), > downloaded the new 5.2.193 code and rebooted. They then went back to the > controller they originally moved to while their primary controller was > being upgraded. Since that code was at a different level (5.2.178) that > the new code they had just loaded for the upgraded WiSM, they downloaded > the 5.3.178 code again & rebooted. They then tried to move back to their > primary controller (now upgraded to 5.2.193), downloaded the new 5.2.193 > code and rebooted, they then went back to the controller they originally > moved to while their primary controller was being upgraded. Since that > code was at a different level (5.2.178) that the new code they had just > loaded for the upgraded WiSM, they downloaded the 5.3.178 code again & > rebooted. They then tried to move back to their primary controller > ................ do you see the loop here? > > This was finally resolved by just biting the bullet and upgrading all the > WiSMs as fast as I could (including the suggested emergency boot image). > That put all the APs into a real mess while it was happening, but really > gave them no choice in the end except to join a controller running the > 5.2.193 code which got them to stop downloading different code with every > join. > > I opened a case with Cisco but got nothing useful back. I have had this > same problem with other WiSM code upgrades. Surely there is a better way > to handle this problem of APs moving around to places where they aren't > wanted. > > If anyone has a workable solution to my problems, please send it along. > > -jcw > > ------------------------------------------------------------ > John Watters The University of Alabama: OIT 205-348-3992 > > > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:[email protected]] On Behalf Of Charles Spurgeon > Sent: Wednesday, August 05, 2009 9:12 AM > To: [email protected] > Subject: Re: [WIRELESS-LAN] WiSM 5.2.193 > > On Tue, Aug 04, 2009 at 09:13:29AM -0500, Hector J Rios wrote: > > > > Has anybody upgraded to 5.2.193? Can you provide any feedback? > > We have upgraded 31 WLCs from 4.2.130.0 to 5.2.193.0, with no > operational issues seen and no problems reported for clients so far. > > We have approx 3,500 APs, and the client count is at its lowest level > due to summer session with around 3,000 peak simultaneous clients. We > are installing a number of 1142s, so we needed the new code to support > them. > > We *did* encounter a weird AP join issue on some of the WLCs in one of > our mobility groups when there were mixed versions of WLC code while > upgrading WLCs in the same mobility group (some controllers on 4.2 and > others on 5.2). > > The issue was a delayed join to the primary WLC for APs during the > process of upgrading the controller and then waiting for APs to > re-join the upgraded (primary) controller (we configure the > primary/secondary/tertiary WLCs on the APs). We escalated the issue > and Cisco has developed a fix that will presumably ship in newer code. > > Meanwhile, we noticed that if we upgraded the first controller in the > mobililty group (the one with the lowest MAC address as seen in "show > mobility summary") to the new controller code first then that seemed > to avoid the issue of having large numbers of delayed AP joins. Given > that, we resumed our upgrades and have almost completed the entire set > of WLCs. > > -Charles > > Charles E. Spurgeon / UTnet > UT Austin ITS / Networking > [email protected] / 512.475.9265 > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
