We have two WLCs on the same VLAN: 10.228.113.10 (SSO .11 & .12) and 10.228.113.15 (SSO .16 & .17).
Edit: Both WLCs are running 8.5.171.0 code.
.10 is primary WLC, .15 is backup WLC. 99% identical config for proper failover from APs, unique configs are the only difference.
AP boots up, receives DHCP address, and gets option 43 (0xf1040ae4710a), but connects to .15 via broadcast.
I was hoping it would be an HA issue, I configured the APs HA with a primary (10.228.113.10) and secondary (10.228.113.15) and rebooted. Still connects to the .15 WLC.
*Mar 24 20:15:29.235: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.228.113.10 obtained through DHCP
*Mar 24 20:17:10.435: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.228.113.15 peer_port: 5246
*Mar 24 20:17:10.435: %CAPWAP-5-SENDJOIN: sending Join Request to 10.228.113.1
After doing some search engine-FU, I know (now) that the order of discovery is: IP broadcast, locally stored IP(s), DHCP option 43, or via DNS (which we do not use).
Ultimately, I prefer to have it connect to WLC01 and only fail over to WLC02 in case WLC01 drops off the planet, which in SSO, shouldn't happen, but ya' know Murphy...
This is only affecting a single AP, but I'd still like to know the best way to resolve this.
I suppose I'm looking to see if there is an order on how the broadcast gets answered. Both WLCs are setup in the same mobility group, neither are setup for master controller (per Cisco recommendations), yet the .15 responds to the request over the .10. I don't want to have to create an ACL on the SVI to block the discovery because I know that one day, that'll somehow come back to bite me in the butt.
Thanks
--J