RE: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193

2009-08-06 Thread Bentley, Douglas
We had the same problem here. Via WCS I upgraded all the WiSM and disabled 
fallback and then issued a reboot "all" and reloaded all the WLC at once.  We 
had a one WLC that did not reboot but that was an easy fix.




Douglas Bentley | University IT/NC Network Engineering 
University of Rochester | 727 Elmwood Ave.| Rochester, NY 14620
T: 585.275.6550 | Email: douglas.bent...@rochester.edu

  


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Watters, John
Sent: Wednesday, August 05, 2009 10:34 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
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:wireless-...@listserv.educause.edu] On Behalf Of Charles Spurgeon
> Sent: Wednesday, August 05, 2009 9:12 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> 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 th

RE: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193

2009-08-05 Thread Frank Bulk - iName.com
You would think there should be a near-hitless upgrade process.  Could be as 
simple as temporarily restricting APs from downgrading.  And that doesn't even 
have to be done the AP side, that could be done via a setting on the WLC.

Frank

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:wireless-...@listserv.educause.edu] On Behalf Of Dennis Xu
Sent: Wednesday, August 05, 2009 9:49 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193

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" 
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
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 WattersUA: 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 WattersThe University of Alabama: OIT  205-348-3992
> 
> 
> -Original Message-
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv
> [mailto:wireless-...@listserv.educause.edu] On Behalf Of Charles Spurgeon
> Sent: Wednesday, August 05, 2009 9:12 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> 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
> operati

Re: [WIRELESS-LAN] FW: [WIRELESS-LAN] WiSM 5.2.193

2009-08-05 Thread Dennis Xu
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" 
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
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:wireless-...@listserv.educause.edu] On Behalf Of Charles Spurgeon
> Sent: Wednesday, August 05, 2009 9:12 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> 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 escala