0

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

Improve this question
6
  • If the WAPs are on a different network from the controllers (typical), the there will be no broadcast discovery. Just make sure there are no locally stored addresses on the WAP.
    – Ron Maupin ♦
    Mar 24 at 21:13
  • All remote APs are working fine using option 43. I'm just experiencing issues with the single AP that resides on the same subnet as the WLCs.
    – redneckgeek
    Mar 24 at 21:31
  • Right, and my point is to move the WAPs to a different network, and you will solve the problem because there will be no broadcast. Also, an ACL on the SVI will not work for devices on the same network because the traffic does not pass through the SVI when devices are on the same network.
    – Ron Maupin ♦
    Mar 24 at 21:36
  • Derp on the ACL... And unfortunately, moving it to a different network isn't an option.
    – redneckgeek
    Mar 24 at 21:39
  • Once the AP associates with a WLC, it will remember that WLC. So if it associated with .15 once, it will again from now on, unless you manually change it. You could do that to make it associate with .10
    – Ron Trunk
    Mar 24 at 22:12
1

Well, @Ron Trunk got it. Well, at least got me in thinking in a slightly different direction, which is good enough for me.

I did have the HA config mostly correct on the AP, BUT (because there's always a but), I had the name incompletely punched in.

To clarify: Each WLC's sysname is 'wlc-01.FQDN'. When I entered the HA name I only added the hostname, in this case 'wlc-01' and did NOT include the FQDN. Once I added the FQDN and bounced the AP, it connected to WLC-02 then flipped over to WLC-01.

Now comes the test this weekend when I simulate a failover wlc-01 going offline completely and

Thanks!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.