11-25-2021 12:15 AM
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
11-25-2021 03:36 AM
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.
11-25-2021 06:10 AM
Hi Leo
Thanks for your reply.
I'm going to try that and will write back soon.
Best regards
Joël
11-26-2021 09:01 AM
This should be obvious but did you check the logs on the controller for any reason for the AP dropping off?
12-02-2021 08:34 AM
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?
12-03-2021 02:46 AM
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.
12-28-2021 07:57 AM
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.
12-28-2021 03:57 PM
@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.
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