cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2807
Views
0
Helpful
7
Replies

Access-Points randomly disassociate from WLC 5520

Joel Lallemand
Level 1
Level 1

Hi

 

After activating a monitoring policy on prime, we noticed that the AP's randomly disassociates from controller for a few minutes. After they associate again with the same controller. Only one AP at a time. No regularity can be determined, all aps are involved. Sometimes every 10 minutes a other one, then everthing runs good for 1 hour...During the disassociation, the involved switch shows nothing in the log, the physical link to the AP is always up. A routing problem can also be excluded, because we run several AP's at a location and only one AP is involved at a time.

 

We have the following infrastructure:

 

- 4 x 5520 Controller, v.8.10.162

- ~1500 Access-Points, different Models 1832, 2702, 2802

- local mode and flex connect mode

- several locations (~200) with several WAN-Links

 

Does anyone else notice this behavior? What can we do?

 

Thanks for your support.

 

Best regards - Joël

 

 

 

7 Replies 7

Leo Laohoo
Hall of Fame
Hall of Fame

What is the uptime of the AP? 

Try manually rebooting the AP.  
NOTE:  Do not instruct the AP to "reload".  Instead, kill the power of the AP by shutting the PoE.

Hi Leo

 

Thanks for your reply.

I'm going to try that and will write back soon.

 

Best regards

Joël

Rich R
VIP
VIP

This should be obvious but did you check the logs on the controller for any reason for the AP dropping off?

Hi rrudling

 

Yes, we checked the logs, but they contain no information:

Failure Source
3c:41:0e:e1:ca:60:langnaap3008
Category
AP
Generated
undefined NaN, NaN, 12:NaN:NaN PM GMT-NaN:NaN
Generated By
Controller
Device IP Address
10.129.x.x
Severity
Critical

 

It's always the same error message. No Suspicious logs before and after the disassociation message.

It also seems to stop after killing the power of the ap, as Leo suggested. But i'm wondering for how long...

And that's maybe a solution for a small infrastructure but not for a big one.

 

it just surprises me that no one else has this problem?

 

That is not a controller log though!  I presume that is Prime?  When you say you "checked the logs" are you saying you looked at the logs on Prime or did you actually log into the WLC and check the logs on the WLC?

Quite possible others are not aware of the problem as you weren't before you started monitoring closely.

We only alarm if an AP goes down for more than 10 minutes for example.

Hi Rrudling

 

Your're right, this was a prime log. This is a controller log:

 

*apfReceiveTask: Dec 09 08:13:00.843: %LOG-4-Q_IND: capwap_ac_sm.c:8887 The system detects an invalid AP(dc:f7:19:08:e0:00) event (Capwap_configuration_update_request) and state (Capwap_dtls_teardown) combination
*spamReceiveTask: Dec 09 08:12:58.152: %CAPWAP-4-INVALID_STATE_EVENT: capwap_ac_sm.c:8887 The system detects an invalid AP(dc:f7:19:08:e0:00) event (Capwap_configuration_update_request) and state (Capwap_dtls_teardown) combination
-Traceback: 0xb74ec2 0x9e2efb 0x84326c 0xae28c0 0x1187773 0x3ba6c07dff 0x7f834550239d
*spamApTask4: Dec 09 08:12:58.152: %CAPWAP-3-DTLS_CLOSED_ERR: capwap_ac_sm.c:7126 dc:f7:19:08:e0:00: DTLS connection closed forAP 10:94:28:20 (5272), Controller: 10:129:27:5 (5246) Echo Timer Expiry
*spamApTask4: Dec 09 08:12:58.152: %CAPWAP-3-ECHO_ERR: capwap_ac_sm.c:7871 Did not receive heartbeat reply; AP: dc:f7:19:08:e0:00

 

I'm not sure if this is maybe a time problem? After restarting the AP (shut down POE-Port), the AP is working properly. I'm not sure for how long.


@Joel Lallemand wrote:

*spamApTask4: Dec 09 08:12:58.152: %CAPWAP-3-ECHO_ERR: capwap_ac_sm.c:7871 Did not receive heartbeat reply; AP: 


Raise a TAC Case.  

Review Cisco Networking for a $25 gift card