03-09-2015 06:06 AM - edited 07-05-2021 02:40 AM
5760 Wireless Lan Controllers running 3.61 became unreachable and had to be rebooted, it appears to be affected by the following bug CSCus92830.
Will upgrading to 3.7.0 fix this problem
Solved! Go to Solution.
03-09-2015 11:17 AM
warwickwinter,
It is hard to say whether an upgrade to 3.7.0 will fix a bug found in 3.6.1 without looking thoroughly at source code or performing extensive tests. The release notes for 3.7.0 do not explicitly state bug CSCus92830 to be fixed, but it is possible that the bug was inadvertently fixed during some modification to the source code.
However, researching bug CSCus92830 reveals that it is a duplicate of bug CSCus54365, which has related case-notes stating the bug is to be fixed in 3.6.2. The currently scheduled release date for 3.6.2 is set for April 10, 2015.
-- Kenneth
03-09-2015 11:17 AM
warwickwinter,
It is hard to say whether an upgrade to 3.7.0 will fix a bug found in 3.6.1 without looking thoroughly at source code or performing extensive tests. The release notes for 3.7.0 do not explicitly state bug CSCus92830 to be fixed, but it is possible that the bug was inadvertently fixed during some modification to the source code.
However, researching bug CSCus92830 reveals that it is a duplicate of bug CSCus54365, which has related case-notes stating the bug is to be fixed in 3.6.2. The currently scheduled release date for 3.6.2 is set for April 10, 2015.
-- Kenneth
03-30-2015 03:42 AM
Hi all,
We are too hitting this bug with a 5760 in code 3.6.0. The input queue counter of the TenGig interface keeps on growing, until it reaches 100%:
wirelessController5760-D-0-1#sho int te1/0/1 | incl Input queue
Input queue: 155/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Can you confirm this is the same bug as you mentioned: CSCus54365 and CSCus92830?
The reload temporary fixes the issue for a few days. We have also tried to upgrade to code 3.6.1, but the issue remains.
A definitive fix in code 3.6.2 would be more than welcome...
Andre.
03-30-2015 03:47 AM
Didn't mention it, but once the counter reaches 100%, the controller is not reachable anymore, service is completely down, and we have to reload the controller to restore the situation.
Also, do you have commands available in IOS-XE to capture the content of the input queue buffer, as those we can find in IOS : http://www.cisco.com/c/en/us/support/docs/universal-gateways-access-servers/90-series-customer-premises-equipment/12761-bufferleak-troubleshooting.html
03-31-2015 12:33 PM
3.6.2E is out if you wish to give it a try.
HTH
Rasika
03-09-2015 06:43 PM
No, its not sure if the upgrade will fix the bug or not. We need to upgrade and check if the bug still exists.
04-02-2015 03:11 AM
From the bug toolkit, in the bug CSCus92830, version 15.2(2)E1 (= IOS-XE 03.06.01) is written as affected.
The bug seems to be fixed in code 15.4(3)S2.8, but I can't find the IOS-XE version it is referring to. I suppose this is an expected release. The bug does not seem to be fixed in code 03.06.02E.
Anyone has a clue about an ETA for code 15.4(3)S2.8?
In the meantime, as a workaround, we will schedule an automatic weekly reload of the controller using kron I guess.
Andre
04-02-2015 04:08 AM
That is an autonomous code version not an IOS-XE nor AireOS version.
-Scott
04-02-2015 05:12 AM
Hi Scott,
Not sure at all about this, as I'm not in the Cisco Dev Team, but it seems to me that there is a correspondance in the IOS train releases and the notations for the IOS-XE:
I agree there is no correspondance for the AirOS. Only a correspondance with the WLC AirOS version and the IOS code in the AP: http://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html
04-02-2015 05:20 AM
Well if it is, then that is a beta code and seems like to be way out there. Open a tac case and find out from them, that would give you a better idea.
-Scott
04-02-2015 05:25 AM
Hi Scott,
I'm already working with the TAC on this for a few days, but it is always good to discuss with the community.
I already asked to the TAC about the fix release, waiting for the answer. I'll give the information here for anyone interested.
Andre.
04-02-2015 05:48 AM
That is a long time to actually be waiting. If there was a fix, they would of had provided that info to you the same day you opened your case. Let us know what they say.
-Scott
04-29-2015 06:58 AM
I also have been experiencing this issue. Mine started right after trying to trace and debug some Windows 8 devices having troubles connecting to the wireless. I was able to finally upgrade to 03.06.02 last week, which states it resolves this, but It did not. I just heard back from this morning TAC that in my case, I am experiencing CSCut50679. Throughout this whole time, I have worked around it by setting a reoccurring job that reboots my 5760 at convenient time every week. Cisco states "The fix will be available in next BENI MR2 (3.7.2E)". Hope some of you find this information useful.
John
04-29-2015 12:39 PM
Thanks for posting this update. Yes it is very useful
Rasika
04-30-2015 06:09 AM
Disregard my post above. I got excited by the email from TAC thinking that they actually figured out the issue. After I looked into it, I found that CSCut50679 only references the 3650 and 3850 switches running release 15.2(3)E and it is resolved in 15.5(1)S0.2.0. I am unaware of a way to install 15.x on the 5760's which uses IOS-XE. Asking Cisco to take another look and try again.
John
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide