Interesting bug, We’ve hit a similar one(or perhaps that one) a while back but 8.0 code. Was never identified what was causing it but lack of beacons was a symptom. Spent a lot of time trying to collect the data required but tac required captures/debugs etc from multiple places at once including the AP. But it wouldn’t necessarily be the same AP that broke next time, and it might take months to occur. We ended up giving up and just reboot AP’s. Couldn’t see a clear sign we would identify the issue without potentially hours of work over multiple weeks. When compared to just a “workaround” reboot….reboot won. AP’s with zero 5ghz clients typically identifies them.. That’s not normal in high density areas. Prime would show clients just dropping to 0.
Interestingly we had a similar issue with 1142’s a sometime in the 7.X code I believe. That did get fixed but we’d see both 2.5 & 5ghz drop off over time. -- Jason Cook Technology Services The University of Adelaide, AUSTRALIA 5005 Ph : +61 8 8313 4800 From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Garret Peirce Sent: Monday, 19 September 2016 11:33 PM To: [email protected] Subject: Re: [WIRELESS-LAN] Cisco 8540s, and 8.3.102 Code We run 8.3 on some new 8540s. We moved to 8.3 to resolve a DFS issue in 8.2 (CSCuy45955 - AP stops xmitting beacons after some # of DFS events). This is fairly silent btw, look for a dearth of 5G clients and/or cleanair being down. I'm not on the daily battlefield of wireless support so much anymore, but hearing a new 8.3 bug is: '..seen a problem in the past few weeks where sometimes when an AP power cycles the primary image becomes corrupted (premature end of mzip file on boot), AP switches to the backup image, connects to controller, sees that it has the "correct" version in its backup, and boots the bad file again. Infinite loop. The only fix is by renaming the backup image via it's console' As complexity/features continue to increase, no vendor's images will ever be bug free. I was wondering if there might be an advantage in having modular AireOS code. That'd not be without issues either, but bug fixes might possibly come more quickly and allow more time before migrating to the next major release. The biggest downside of that, as seen on the ASR side, is that many modular patches still require a reboot - but on an AP(s) that would not be as big of an issue. On a side note, over the last year/two there seems a behavior on part of the TAC pushing back for us to 'lab' problems. In our view, once we've pretty clearly identified an issue exists, it's a TAC/developer issue to further ferret out and resolve. That adds time and pain to the service impact of the bug. On Wed, Sep 7, 2016 at 7:52 AM, Osborne, Bruce W (Network Services) <[email protected]<mailto:[email protected]>> wrote: …Or better vendor support. We always check with our vendor support people before jumping on an upgrade. Sometimes they recommend waiting due to new buigs. We find vendor support generally better informed than peer user support. Bruce Osborne Wireless Engineer IT Network Operations - Wireless (434) 592-4229<tel:%28434%29%20592-4229> LIBERTY UNIVERSITY Training Champions for Christ since 1971 From: Lee H Badman [mailto:[email protected]<mailto:[email protected]>] Sent: Tuesday, September 6, 2016 3:52 PM Subject: Re: Cisco 8540s, and 8.3.102 Code Wow. Thanks, Brandon. You need a program to keep up with all of the bugs… From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Case, Brandon J Sent: Tuesday, September 06, 2016 3:42 PM To: [email protected]<mailto:[email protected]> Subject: Re: [WIRELESS-LAN] Cisco 8540s, and 8.3.102 Code We deployed our first 8540s running 8.3.102 and ended up running into CSCva98592. Basically caused both HA peers to crash and reboot simultaneously. Also had problems re-pairing them after bringing the secondary out of maintenance state. We were advised to back down to 8.2.121.9 which is an engineering special that we had to request. Been stable on that for about 2 weeks now. 8540 pair has about 250 APs and peaks around 1300 clients right now. We are not running AVC though. -Brandon From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Lee H Badman Sent: Tuesday, September 6, 2016 3:31 PM To: [email protected]<mailto:[email protected]> Subject: [WIRELESS-LAN] Cisco 8540s, and 8.3.102 Code Sigh… we continue to have WLC performance issues seemingly related to AVC, even after upgrading to 8.2.121. TAC has mentioned 8.3.102 as having AVC fixes, but I don’t see anything after looking at release notes. Anyone using 8.3.102. or heard any rumblings that are of concern? Lee Badman | Network Architect (CWDP, CWNA, CWSP, Mobility+) Information Technology Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244 t 315.443.3003<tel:315.443.3003> f 315.443.4325<tel:315.443.4325> e [email protected]<mailto:[email protected]> w its.syr.edu<http://its.syr.edu> SYRACUSE UNIVERSITY syr.edu<http://syr.edu> ********** 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/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. -- Garry Peirce Network Architect Networkmaine, University of Maine System US:IT 207-561-3539 ********** 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/.
