Re: No more AP manager addresses remain..

tborkowski · ‎10-31-2017

I've run into a problem with getting my 3802's to join up to a 5520 controller (running as an HA pair). The controller is running 8.5.105 and the AP's are brand new out of the box. Some of the AP's show as unknown on the switch, which I believe is a problem with the code their running. However, they should still join the controller. I was able to join a couple AP's, but after a short while they drop. Here's the output from one of the AP's that was up, but was unable to rejoin. The line that stands out is "No more AP manager addresses remain". I thought this could be due to an IP conflict, but that doesn't seem to be the case. Once I take the controller offline I'm no longer able to ping that IP address.

*10/30/2017 18:43:45.6609] CAPWAP State: Discovery
[*10/30/2017 18:43:45.7252] IP DNS query for CISCO-CAPWAP-CONTROLLER.localdomain.com
[*10/30/2017 18:44:10.8652] Discovery Request sent to 172.20.230.246, discovery type STATIC_CONFIG(1)
[*10/30/2017 18:44:10.9831] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)
[*10/30/2017 18:44:11.0807] Discovery Response from 172.20.230.246
[*10/30/2017 20:06:59.0013]
[*10/30/2017 20:06:59.0013] CAPWAP State: DTLS Setup

AP19>
AP19>
AP19>
AP19>
AP19>
AP19>[*10/30/2017 20:07:56.1016] dtls_disconnect: ERROR shutting down dtls connection ...
[*10/30/2017 20:07:56.1016]
[*10/30/2017 20:07:56.1018]
[*10/30/2017 20:07:56.1018] CAPWAP State: DTLS Teardown
[*10/30/2017 20:08:01.2684] No more AP manager addresses remain..
[*10/30/2017 20:08:01.2684] No valid AP manager found for controller 'WIFI5520-1' (ip: 172.20.230.246)
[*10/30/2017 20:08:01.2714] Failed to join controller WIFI5520-1.
[*10/30/2017 20:08:01.2717] Failed to join controller.
[*10/30/2017 20:08:01.9507]

Interestingly I was able to ping the controller but had 50% failure when pinging the default gateway. Even as I was pinging the WLC it performed a DTLS teardown:

AP19#ping 172.20.230.1
Sending 5, 100-byte ICMP Echos to 172.20.230.1, timeout is 2 seconds
!.!!.
Success rate is 60 percent (3/5), round-trip min/avg/max = 1.050/2.988/6.291 ms
AP19#ping 172.20.230.1
Sending 5, 100-byte ICMP Echos to 172.20.230.1, timeout is 2 seconds
.!!..
Success rate is 40 percent (2/5), round-trip min/avg/max = 1.254/1.634/2.015 ms
AP19#ping 172.20.230.246
Sending 5, 100-byte ICMP Echos to 172.20.230.246, timeout is 2 seconds
!!!![*10/30/2017 20:17:42.1037] dtls_disconnect: ERROR shutting down dtls connection ...
[*10/30/2017 20:17:42.1037]
[*10/30/2017 20:17:42.1038]
[*10/30/2017 20:17:42.1038] CAPWAP State: DTLS Teardown
!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1.553/6.611/24.327 ms
AP19#ping 172.20.230.246[*10/30/2017 20:17:47.1085] No more AP manager addresses remain..
[*10/30/2017 20:17:47.1130] No valid AP manager found for controller 'WIFI5520-1' (ip: 172.20.230.246)
[*10/30/2017 20:17:47.1142] Failed to join controller WIFI5520-1.
[*10/30/2017 20:17:47.1144] Failed to join controller.

Flavio Miranda · ‎11-01-2017

Hi @tborkowski

Verify if time and date is properly configured on the WLC.

Licensing is active and MIC is checked on the SECURITY tab under AP policy.

Also please inform the WLC, AP and gateway IP address and mask.

If possible, share WLC running config.

-If I helped you somehow, please, rate it as useful.-

Vengatesa Prasath · ‎11-03-2017

Hi,

Do you have any dynamic interface configured as AP-manager on Wlc?

If so, please

- remove the dynamic ap-manager interface
- enable dynamic ap management on the management interface

tborkowski · ‎11-16-2017

There was no ap manager on a dynamic interface. The mngt was using that role. We were able to resolve the issue, which had nothing to do with the WLC. Someone had installed another dhcp server that was improperly configured.

The AP's that were dropping was a result of the 8.5.105 code we were using. We downgraded to 8.2.166 and everything became stable again.

jturner2720 · ‎12-06-2017

I'm seeing a similar issue with some 1832s connecting to a 5508 running 8.3.133.0

They're just stuck in a loop trying to connect to their preferred controller, failing to a secondary, then going back to the primary.

Time is good on the controller, security policy allows MICs and we have lots of other APs connected including some from the same network.

I wondered whether it could be related to https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf76274 in that APs aren't able to join the controller, though the erros are slightly different.

Any thoughts?

tborkowski · ‎01-20-2018

That's not the issue I was facing with my controller. What version of code are you running on yours?