Log spamming - %LWAPP-3-INVALID_SLOT All the AIDs are in use

[Davide Fiumi]

Good morning,

on a active-active 2x5508 WLC on 8.0.152.0 we are receiving a constant spam of these messages

*apfMsConnTask_2: Nov 08 09:47:03.898: %LWAPP-3-INVALID_SLOT: spam_api.c:1469 The system detects an invalid slot identifier (1) - All the AIDs are in use. Could not allocate association identifier; AP xx:xx:xx:xx:xx:xx
*apfMsConnTask_2: Nov 08 09:46:58.793: %LWAPP-3-INVALID_SLOT: spam_api.c:1469 The system detects an invalid slot identifier (1) - All the AIDs are in use. Could not allocate association identifier; AP xx:xx:xx:xx:xx:xx
*apfMsConnTask_5: Nov 08 09:46:52.952: %LWAPP-3-INVALID_SLOT: spam_api.c:1469 The system detects an invalid slot identifier (1) - All the AIDs are in use. Could not allocate association identifier; AP xx:xx:xx:xx:xx:xx

The MAC Identifier is related not to the AP MAC, but to the AP Base Radio MAC. Aside from flooding the log, some clients report connectivity issues (unverified). In the log nothing of the kind seems to appear, and debugging connected clients doesn't show any issues with auth and deauth, or reauth - which lead me to believe that only these messages might have something to do with it. 

For good measure, I added all of the reported AIDs missing MACs to the MAC-Filter list - nothing changed though.

The WLAN used by clients is a WPA2-AES with Dot1X-CCKM on PEAP and AAA Override (for automatic VLAN assignment). Same exact WLAN is running in a parallel environment without any complaints. What should be noted, this is a mainly Aironet 1532 network (90 APs).

I have enabled on the WLAN Advanced page:

- Allow AAA Override

- Coverage Hole Detection

- Aironet IE

- Client Exclusion

- Client Band Select

- Passive Client

- BSS Max Idle Service

and disabled mDNS Snooping.

Suggestions/ideas? If it's just a graphical bug, would love to get rid of it - could finally syslog the WLC.

[Kenukid04]

Aloha David,

Did 8.0.152.8 fix this particular bug?  Also what were the known symptoms?  I'm seeing this event spam our logs and have recently upgraded the software version of our two 5500s to 8.0.152.0.

Mahalo,

[patoberli]

Based on a previous message it should be fixed since 8.0.152.7.
But as 8.0 is EOL since April 2018, there is a small chance of a regular fixed release, without involving TAC. See here the EOL posting: https://www.cisco.com/c/en/us/products/collateral/wireless/8540-wireless-controller/eos-eol-notice-c51-739984.html
My suggestion is to upgrade to 8.2.170.0, if all your AP are supported.

[yprasannas]

We had it resolved using 8.0.152.2. This was not a cosmetic log issue. Clients were actually getting disconnected.

8.0.152.2 is like a migraine pill that works.

You have to put special TAC request to get this version.

Hope this helps!

[sistemisti-miur]

Hi to all, 

I've a same problem with my Cisco Wireless 5508 controller with 8.0.150.0 firmware.

I've downloaded AIR-CT5500-K9-8-0-152-0.aes before my contract expires.

Do you know if I can solve with this firmware or I need the 8.0.150.2 ?

Thank you.

[patoberli]

Probably not, you probably need the newer 8.0.150.7. Alternatively you could downgrade to 8.0.140.0, which is not affected by this bug (but various others). 

Which AP models do you have in use? Maybe you could upgrade to 8.3.x. 

[sistemisti-miur]

I can't upgrade to 8.3.X due to old AP "AIR-LAP1252G-E-K9" and "AIR-LAP1262N-E-K9".

The 8.0.15x should be the latest firmware that works with my AP.

[patoberli]

In that case you must open a TAC and hope that they still make this very old firmware available to you.

[tanner.zaitt]

Hello all,

I have the same issue with WLC 5508 and AP AIR-CAP1532I-E-K9.
The Software version is 8.0.152.0.

I identified these logs with (Cisco Controller) debug>client 11:22:33:44:55:66

Dec 30 16:29:50.818: %RRM-3-RRM_LOGMSG: rrmClientProc.c:691 RRM LOG: Airewave Director: Unable to set channel 0[20] on the on AP 18:9C:6D:70:60:30(1)

Dec 30 16:28:03.511: %LOG-3-Q_IND: spam_api.c:1469 The system detects an invalid slot identifier (0) - All the AIDs are in use. Could not allocate association identifier; AP 18:9c:6d:70:60:30[...It occurred 3 times.!]

Dec 30 16:26:06.308: 11:22:33:44:55:66 Sending assoc-resp with status 17 station:11:22:33:44:55:66 AP:18:9c:6d:70:60:30-00 on apVapId 2

*apfMsConnTask_1: Jan 03 18:35:33.980: 11:22:33:44:55:66 Sending assoc-resp with status 17 station:11:22:33:44:55:66 AP:18:9c:6d:70:60:30-00 on apVapId 2
*apfMsConnTask_1: Jan 03 18:35:33.980: 11:22:33:44:55:66 Sending Assoc Response to station on BSSID 18:9c:6d:70:60:31 (status maximum station reached) ApVapId 2 Slot 0

Unfortunately I am not able to get the version 8.0.152.7 or 8.0.152.2.
My work a round is to use mac filtration with local database for the affected AP, for the affected WLAN, where the critical client not able to connect to the network regarding BUG CSCve81314.

I used this documentation for Mac filtration with local database:
Configure MAC Filters with Wireless LAN Controllers (WLCs) - Cisco

I know it's not secure only using Mac filtration but in my situation I am able to do only this.
I noticed that the bug occurs when using WPA/WPA2 PSK authentication.
The bug is not happening when the WLAN is open without WPA/WPA2 PSK authentication.
When I noticed that I decided to try Mac filtration.

If you know better work a round without changing image please let me know.

Best Regards.

[tanner.zaitt]

Little update,

After a few hours, the issue occurred again with mac filtration and with open network without WPA/WPA2 PSK.
My thesis is not correct in my previous post.

Now I moved the AP to another stand alone controller to see what will happen.
The controller is with the same hardware as previous and with the same software version.

For now I don't see any errors for the moved AP in the new controller.
But in the new controller I see the same error for another AP.

Did you try to reboot the wlc controllers?
And do you know how is the behavior after reboot?
Or the bug is exist permanently and the behavior of the bug is independent from system uptime?