10-02-2015 10:19 AM - edited 07-05-2021 04:01 AM
Beta process is closed, final release 8.1.131.0 is now posted in CCO
10-02-2015 06:23 PM
CSCut33114 |
LAG with 1G does not work in 5520 and 8540 |
Thanks Javier. I find this bug ... weird.
According to the 8540 Deployment Guide it states "A single LAG across the 4 x 10 G interfaces is supported in software versions 8.1 and later." This statement leads me to believe LAG with SFP is not supported.
10-05-2015 09:07 AM
Hi Leo
the DG mentions "a single lag", to emphasize that multiple lag interfaces are not supported at this time
The 10g is not a restriction on 8540/5520, as they physical ports support 1G/10G SFP
it was a restriction on 8510/7500, so probably a leftover in documentation that may need correction
The bug fixes handling of the 1G link state for 8.1
regards
10-06-2015 03:46 AM
Ok, thanks for the explanation.
So this means that 5520/8540 will (version 8.1.123.X and later) support 1G LAG? Am I reading this correct?
10-06-2015 04:14 AM
Yes.
10-06-2015 04:35 AM
Ok. Thanks for the confirmation.
I hope someone can fix up the "document bug".
03-09-2016 08:32 AM
Hi Javier,
thanks
03-09-2016 09:17 AM
hi Abraham
we do not plan to do further MR releases for 8.1 at this time, so if a migration is needed, it is recommended to invest certification/validation time into 8.2, if you need to upgrade
if you absolutely need 8.1 based code, send me private message, and I can share the list of known "bad" issues for your evaluation
if you are on 8.0 code now, you can migrate directly to 8.0.121.0 for this bug
regards
03-21-2016 08:30 AM
Apple TV does not work on 8.0.121.0, 8.1.131.0. Something was changed so looks like mDNS is no longer supported. I have 5500 and 8510. We have a 500+ school environment with over 120k+ endusers and many AppleTV devices being used so I cannot upgrade to fix the security breach. Any thoughts?
10-09-2015 03:12 AM
Is there coming any fix to te bug causing the 802.11a radio resets due the DCA interval? We've tried 8.1 MR1 and MR2 but the bug persists. I had to freeze the RRM DCA cycle to prevent the bug from occuring.
Regards.
10-13-2015 06:18 AM
Hi
A channel change "requires" a radio reset. if you see a large channel change count, please open TAC case to investigate. The change maybe a symptom not the root cause
regards
10-13-2015 06:58 AM
I'm know that an DCA channel change causes an radio reset. The problem is that there is no channel change, tx level change or radar and it still resets the radio with an Unknown reason. (The timing is the at or after the DCA interval).
An overview of the resets code is presented below:
AP_109360#show controllers dot11radio 1 radio-reset
Last radio reset code: 88
Radio resets - total:65 retries:0 failed:0
Reset Stats: Start Cnt: 10, Recovery: Cnt 0, Last Ret: 0, Fails: 0, Recvry Status: Stalled NO, In Prog NO
Code/Count: 37/00059 1 62/00003 24AC 67/00001 0 88/00002 24AC
10-13-2015 07:53 AM
hi
37 -> IDB interface reset (main contributor in you list, with 59 events)
This is generic reset, it may have several triggers, not all pointing to DCA
Things like RLDP or auto contention can be directly responsible for this, independently of DCA
Check if you have those features enabled
62 is manual channel assignment
67 is due to hostname change
88 is due to client deauth (Special recovery case due to pending packets)
There are possibilities of troubleshooting this further, as AP can register the reset caller, not just the type, that is why I recommended TAC process. That should be part of separated discussion, outside 81MR3 release thread. ;-)
regards
10-22-2015 02:03 AM
We have vWLC with several 1602i and 1702i APs in flexconnect local switching mode.
Previous week we upgraded from version 7.6.x to 8.1.122.0 and we enabled 802.11r and 802.11k on a 802.1x secured SSID.
After a few days some users with Apple devices were complaining of reconnect issues.
After investigation it looked like we ‘hit’ bug CSCuv37613.
Yesterday I installed version 8.1.123.20 but after some running around in the building with my iPhone 5s the issue still occurred. So it seems to me bug CSCuv37613 is not solved (or we are running in another issue). After disabling 802.11r the reconnect problems seem to be resolved (but no fast roaming anymore…).
11-04-2015 04:29 AM
Any idea when the actual release will be out? The TAC told me "end of October" two weeks ago.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: