Difficulty associating AP with WLC- 1832i & WLC 3304

[netadmin@medcompnet.com]

I have an 1832i AP at a remote site with IP address in the 192.168.13.0/24 range. It was set up originally as ME and I tried to change it to CAPWAP, but that failed and the AP's on site are now not broadcasting SSID's. I have been trying to force it to AP 192.168.1.68 by priming, also by using DHCP option 43 and 60.... Do I set sub option 102 or 241? DNS is not an option for this implementation. Do I need to do a factory reset, and if so, how do I do it over CLI? I have full admin access over the network, DHCP server is Windows Server 2012R2.

[patoberli]

I had a similar issue. In my case it was caused by a NAT on the Wan-Edge, which routed the packets from the AP wrong. The WLC never received the packets from the AP. A 'debug capwap errors enable' should show the mac address of the AP. If you don't see any events (with the correct mac address), try 'debug capwap events enable'. This second command can cause a lot of logs, if you have many APs connected, so use it with care.

[netadmin@medcompnet.com]

That helps! Take a look:

(Cisco Controller) >debug capwap errors enable

(Cisco Controller) >*spamApTask4: Sep 05 09:24:56.452: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:24:56.460: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:24:58.936: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.52:5264 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:03.780: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.68:5272 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:03.788: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.68:5272 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:25:05.993: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:25:05.996: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:08.455: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.52:5264 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:13.288: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.68:5272 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:25:15.461: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:25:15.463: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:17.943: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.52:5264 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:25:24.965: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:25:24.971: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:27.539: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.68:5272 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:27.546: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.68:5272 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:25:34.468: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask4: Sep 05 09:25:34.471: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.213:5264 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:37.043: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.68:5272 --> 192.168.1.68:5246

*spamApTask5: Sep 05 09:25:37.049: cc:70:ed:1c:24:01 Discarding CAPWAP packet not for this WLC 192.168.13.68:5272 --> 192.168.1.68:5246

Why doesn't it think those packets are for the WLC?

[patoberli]

Not sure, can you let the debug run and reboot the AP? Maybe we are missing the first few messages which are more important.
Or do you maybe have misconfigured hostname/ip configuration in the AP HA tab?

[netadmin@medcompnet.com]

I think the problem is the time on he AP's. How do you configure this? I tried setting the DHCP option for it but no luck and it is showing about a week behind. The WLC is saying the packets are not for this WLC... but they are. Any ideas? I have other sites where this is working, but here is the first I have noticed the time issue.

Thanks!

[patoberli]

I thought it shouldn't matter if the AP has a wrong time, as long as the WLC time is correct, but I might be wrong.
What you could try, there is an option to set an NTP server as DHCP option and if I remember correctly, the 18xx series honor that DHCP option.

[netadmin@medcompnet.com]

Don't know a whole lot yet- I reaffirmed the DHCP scope option for the time server, and I am seeing the AP trying to connect to the WLC, and the WLC is dropping the packets, claiming they are not for another WLC... but the AP time is incorrect. Any idea how to fix this?

[patoberli]

Things to check:
is your new AP for the correct region which is configured on the WLC?
Does your new WLC have unused/free licenses?
You can try to hard-configure the WLC, enter this on the AP:
capwap ap primary-base <WLC-sysname> <IP-address>

Which IP has your 2504 and which IP has your 3504? I'm a tad confused by the various logs.

[netadmin@medcompnet.com]

I think I am getting close to sorting this out... We have multiple problems, but the first one was the failure of the AP's to associate. To clarify what we are working with, it is 5 Aironet 1832i AP's at the remote site and one WLC 3504 located where I sit. The 2504 from the logs was a virtual WLC created by Mobility Express mode on of the AP's when I was trying to get FlexConnect up. I had typo'ed the IP in the DHCP option. I had a DNS entry that was not helping. Some of the AP's are CAPWAP and some ME. Some are static IP and some DHCP. I opened a TAC case to sort everything out, and we got to the point where Cisco recommended removing the DHCP options (I had already removed the DNS entry). One of the AP's associates with WLC 3504 now... but I can't get in to the others. I have no console access (They are mounted to a 25' high roof in a warehouse 2500 miles from where I sit). The fact that one AP is properly associated tells me that there is not a configuration problem with either site and that the network in between is also properly passing the needed traffic... I just have to get in to the other 4 AP's. I think that the only way to do that will be to have someone walk around and see if they have access to the Cisco Air Provision SSID. I can see the AP's by IP, but cannot connect- tried Telnet, SSH, http, and https, so I am guessing they are in a factory state and locked down. I'll update the thread when I have more info.

Thanks!