On 21 Oct 2016, at 15:12, Dennis Xu wrote:
You may be hitting this bug for the 105:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw34201
Fixed in 8.0.135 and later.
107 seems like it may be similarly related to APs hitting a max limit
as well.
I would consult Tac before upgrading, but seems like there are a
couple active bugs that could be triggering this. 8.0.140 has a long
list of resolved caveats that might be worth exploring.
We see the same issue (code 105) here. Upgraded from 8.0.120 to
8.0.133 with no help. With "show client ap 802.11b AP_name" command, I
see a lots of clients in idle state, also these idle clients will not
be cleared out by the idle or ARP timeout. I noticed all these clients
are inter-controller roaming clients. Then I shuffled some APs among
controllers to minimize inter-controller roaming and also use
scheduled job from PI to reboot some APs weekly to clear out the idle
clients. Now I do not see this error anymore in our environment.
If you have inter-controller roaming with AAA override enabled, please
also be aware of this bug;
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb21254
We hit it when upgrading to 8.0.140.0, and it only happens when the
client roams back the first AP on it’s anchor controller after having
roamed to a foreign one. If the client roams further to a new AP on the
same anchor controller, it works again (it can even roam back to the
first AP it joined, and it will work, so it’s only when hitting that
first AP when coming back to your anchor controller).
TAC told us that the bug was introduced in versions after 8.0.133.0, and
is fixed in escalation build 8.0.140.3. They couldn’t tell us if the
bug is affecting other platforms than 5508/WiSM2, so I guess we’ll
have to try&fail with our 8540s (-:
--
Joachim
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
