not associated WAPs trying to reach 13.13.13.13 destination via udp/5246

[Moreplovac]

Hello

i am puzzled with situation where lots of WAPs are trying to reach to destination IP address 13.13.13.13 via udp/5246 port.

We have on prem WLC that has no traces of these WAPs; Prime Infrastructure shows info about only one access point in its database.. The firewall is blocking this type of traffic but just want to know if anyone experienced this behaviour and why would this be happening.

Any input appreciated.

[marce1000]

 - Well according to the numbers that was not your lucky day :-) Anyway the IP-address is from Xerox , but more important the udp-port is used for capwap-control. Have these AP's being configured with a correct controller-destination IP ?

 M.

[Moreplovac]

Yup, they might even be lucky numbers, who knows :-)

Yes, the IP is related to Xerox; one of those WAPs was associated with WLC at some point but rest of them not;

WAPs are getting WLC info from DHCP.

I have appr 1400 WAPs working fine with these DHCP settings. 

I can get to console of WAP to obtain a bit more info but that would require some investigation about WAPs location; i have no accurate inventory map

[marce1000]

 - You will indeed need to develop some means to examine these AP's let alone whether they are yours or not. 2) Are they still using 'valid DHCP' ,  3) etc..., 

[Moreplovac]

Hmm, they are mine, that is for sure...

OK thanks..

[Scott Fella]

Are these new access points or existing that was joined and no longer? Only a few places this can be set. Hard coded on the ap high availability, option 43, dns resolution for ap join and if you have ip forward protocol defined.

[Moreplovac]

I can see traces in Prime Infrastructure of only one AP. Cannot see others 

We are not using option 43 for WLC discovery, just DNS.

It is weird that just some numbers of WAPs are causing this behavior and none of these listed IPs are reachable at this moment.

[Leo Laohoo]

Enable DHCP Option 43 and see if those APs join the correct controller.
Since you're able to see that the APs are trying to go to 13.13.13.13, then I suspect someone has console access to the AP/APs.
What happens if the following are entered into the AP/APs (enable mode):

debug capwap console cli
clear capwap private
clear capwap controller ip address
capwap ap primary-base <CONTROLLER NAME> <CONTROLLER IP ADDRESS>

[Scott Fella]

Find one and console into it and reboot the ap. See if you see the ap trying to discover using that address.

[Moreplovac]

Thank you guys for all your suggestions; i will get the console access to see what is going on as well will do the option 43 for testing.

Will post updates shortly.

Thanks again

[Jurgens L]

Not sure what's the history around these AP's, It could be that these AP's connected to a WLC with that IP address previously (in a lab for example). AP's will normally try to connect to a previously associated WLC if failed to connect:
1) L3 Broadcast
2) DHCP Option 43
3) DNS

If you have DHCP Option 43 enabled it will prefer this option over it's previously associated list.

<<< Pls remember to rate all useful responses >>>