AP Discovery Process

[PiotrBurczyk80035]

Hi,

I have a AP discovery case, which boggles my mind, as I wasn't able to find any explanation of it.

We have a Infra with 2 SSO pairs of 9800 WLC's serving APs from multiple sites.

Next to that, I have a test WLC.

There's a mobility configured between those 3 WLC's (2xProd SSO pairs and Test WLC).

We're also having those 3 WLC's  added to DNA-C for Assurance and Automation (Non-Fabric).

By default, we're placing APs in AP-mgmt VLAN with DHCP and option43 configured, so APs are finding a way to their 'mama'

On top of that, we've configured DNS records in our local domain to point CISCO-CAPWAP-CONTROLLER.localdomain to one of our central WLC's.

All WLC's are in Data Centers, far away from APs, so no L2/L3 discovery applies.

One of my colleague have connected brand new AP to a random VLAN with DHCP, but not configured with option43.

I'd expect AP to discover only the the Primary WLC, which IP is being resolved by DNS record CISCO-CAPWAP-CONTROLLER.localdomain.

That happened, but right after that, the AP send a discover request over to the 2 other WLC's (Secondary Prod WLC and Test WLC). And it also decided to join one of the 2 other WLC's.

This is console log:

[*05/16/2023 12:42:34.0400] Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Noop(0).
[*05/16/2023 12:42:34.2680] AP IPv4 Address updated from 0.0.0.0 to 10.0.24.15
[*05/16/2023 12:42:46.0770] dtls_init: Use SUDI certificate
[*05/16/2023 12:42:46.0800]
[*05/16/2023 12:42:46.0800] CAPWAP State: Init
[*05/16/2023 12:42:46.0810]
[*05/16/2023 12:42:46.0810] CAPWAP State: Discovery
[*05/16/2023 12:42:46.0820] IP DNS query for CISCO-CAPWAP-CONTROLLER.mydomain.net
[*05/16/2023 12:42:46.2240] DNS resolved CISCO-CAPWAP-CONTROLLER.mydomain.net
[*05/16/2023 12:42:46.2240] DNS discover IP addr: IP-of-PrimaryWLC
[*05/16/2023 12:42:46.2260] Discovery Request sent to IP-of-SecondaryWLC, discovery type STATIC_CONFIG(1)
[*05/16/2023 12:42:46.2270] Discovery Request sent to IP-of-TestWLC, discovery type STATIC_CONFIG(1)
[*05/16/2023 12:42:46.2310] Discovery Request sent to IP-of-PrimaryWLC, discovery type STATIC_CONFIG(1)
[*05/16/2023 12:42:46.2320] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)
[*05/16/2023 12:42:46.2330]
[*05/16/2023 12:42:46.2330] CAPWAP State: Discovery
[*05/16/2023 12:42:46.3540] Start: RPC thread 2752856960 created.
[*05/16/2023 12:42:46.3540] Discovery Response from IP-of-SecondaryWLC
[*05/16/2023 12:42:46.3810] Discovery Response from IP-of-PrimaryWLC
[*05/16/2023 12:42:46.3810] Discovery Response from IP-of-TestWLC
[*06/15/2023 10:41:25.0000]
[*06/15/2023 10:41:25.0000] CAPWAP State: DTLS Setup
[*06/15/2023 10:41:25.7360] First connect to vWLC, accept vWLC by default
[*06/15/2023 10:41:25.7360]
[*06/15/2023 10:41:25.7530]
[*06/15/2023 10:41:25.7530] CAPWAP State: Join
[*06/15/2023 10:41:25.7560] Sending Join request to IP-of-SecondaryWLC through port 5249
[*06/15/2023 10:41:30.5090] Sending Join request to IP-of-SecondaryWLC through port 5249
[*06/15/2023 10:41:35.2640] Sending Join request to IP-of-SecondaryWLC through port 5249
[*06/15/2023 10:41:35.3840] Join Response from IP-of-SecondaryWLC
[*06/15/2023 10:41:35.3850] AC accepted join request with result code: 0
[*06/15/2023 10:41:35.3970] Received wlcType 0, timer 30

My best guess would be, that it was a Primary WLC, that gave the AP the addresses of other 2 WLCs to discover.

But I couldn't find any document describing this and which option on WLC could influence this.

[Leo Laohoo]

There are hidden elements in IOS-XE which will affect the "decision":  Load and uptime. 

If the Primary WLC has a low uptime, APs will go to it.  Once the Primary WLC has a high uptime of >30 days, it is a free-for-all.  

My recommendation is to configure only one controller in the DHCP Option 43.

Alternatively, configure the Test WLC as the first option and the Secondary WLC as the secondary option. 

[docjb0221]

Here's a link to an old article I found helpful recently. https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/119286-lap-notjoin-wlc-tshoot.html#anc5
I also noticed that if the controllers are on different versions, the AP tends to prefer the WLC that is running the same version it has.
Also, in mobility groups, if one WLC is set as master, I noticed no matter what option 43 says, that controller might be preferred.
I hope this helps!

[PiotrBurczyk80035]

Interesting references....but I'm just purely interested in the Discovery process, not that much in Join process.

As of my knowledge the AP should only be able to discover a single WLC via DNS discovery process, which is being showed in below log:

*05/16/2023 12:42:46.0820] IP DNS query for CISCO-CAPWAP-CONTROLLER.mydomain.net
[*05/16/2023 12:42:46.2240] DNS resolved CISCO-CAPWAP-CONTROLLER.mydomain.net
[*05/16/2023 12:42:46.2240] DNS discover IP addr: IP-of-PrimaryWLC

But then somehow the AP sent a discovery request to IP of other WLC:

[*05/16/2023 12:42:46.2260] Discovery Request sent to IP-of-SecondaryWLC, discovery type STATIC_CONFIG(1)
[*05/16/2023 12:42:46.2270] Discovery Request sent to IP-of-TestWLC, discovery type STATIC_CONFIG(1)
[*05/16/2023 12:42:46.2310] Discovery Request sent to IP-of-PrimaryWLC, discovery type STATIC_CONFIG(1)
[*05/16/2023 12:42:46.2320] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)

It is saying "STATIC_CONFIG", but my colleague is promising me, he hasn't configured anything on the AP....just took it out of the box and connect to a network.

So the question is, how the AP knew the IP address of the Secondary WLC and Test WLC?

[Leo Laohoo]

---

@PiotrBurczyk80035 wrote:
So the question is, how the AP knew the IP address of the Secondary WLC and Test WLC?

---

1. I am going to presume the AP does not know anything about the "presence" of the Secondary & Test WLC.
2. Let's say that the controller has an uptime of >180 days.  

The AP sends out a broadcast and the AP is handed the information about the Primary WLC via DHCP Option 43.  

In an ideal world, the AP will send a Join request to the WLC and the controller will respond.  And they lived happily ever after.  

However, realistically speaking, it will depend on how "fast" the WLC will respond to the Join request.  A WLC with an uptime of >60 will already start to "lag" in sending out the Join Response in a timely manner.  By the time the controller finally gets the chance to do so, the AP would receive the Join Response(s) from the other two "unknown" controllers.

What I have described are what I have seen in AireOS and IOS-XE.  This is why we only have one controller configured for DHCP Option 43.  And we have done the following: 

• Our first foray into wireless, we had DHCP Option 43 is a "landing" controller (AireOS0.  It is specifically for our auto-provisioning.  Once the APs were provisioned with the correct name, location and AP Group, the APs were manually "thrown" to their correct controllers. 
• Later on, we removed our landing controller and, still, configured only one controller.  Again, once the APs were configured correctly, they were thrown to their correct controller or they stayed.  

[PiotrBurczyk80035]

The AP and WLC's are in different corners of the world.

There's no way for AP "broadcasts" to reach WLC's.

Option43 not configiured in this case. AP is not "hardcoded" with any Controller IPs.

So the only option to discover WLC's, In my understanding, is DNS discovery.

But DNS record is pointing to only Primary WLC.

So, again - How does the AP found IP addresses of two other WLCs?

Could it be, that those WLC's are in the same Mobility Group, hence Primary WLC (or DNA-C) provided the IPs of the 2 other WLCs?

I may need to start some packet capture to figure this out.

[Rasika Nayanajith]

It is normal Cisco WLC let AP knows all other WLCs in the mobility list.

HTH
Rasika
*** Pls rate all useful responses ***

[JPavonM]

That also happen to me where some brand new APs are joining to a WLC which is not in DHCP Option 43, nor in the same broadcast domain or DNS option.

That is correct, AP is informed about the WLCs in the same mobility group.

[Rich R · Accepted solution]

https://datatracker.ietf.org/doc/html/rfc5415#page-42

   An AC MAY also communicate alternative ACs to the WTP within the
   Discovery Response message through the AC IPv4 List (see
   Section 4.6.2) and AC IPv6 List (see Section 4.6.2).  The addresses
   provided in these two message elements are intended to help the WTP
   discover additional ACs through means other than those listed above.

 Also once it has joined:
https://datatracker.ietf.org/doc/html/rfc5415#page-115

   One or both of the following message elements MUST be included in the
   Configuration Status Response message:

   o  AC IPv4 List, see Section 4.6.2

   o  AC IPv6 List, see Section 4.6.3

 The APs also keep a list of every WLC they've discovered before, so even when you change the option 43/DNS/WLC, you still see them sending discovers to previous WLCs.  That only gets cleared when you factory default reset the AP.

[Flavio Miranda]

Hi

 We know that the AP tries to find as much as WLC possible. But, in your case, it seems the AP were not able to, by itself, discovery the others WLC, right?  Probably the information about the others two WLC came from the first one discovered as they are in a mobility group (Which one is the group leader by the way?) .  And, with 3 option,  the decision to join another one, probably was a result of a tie break (more license, higher IP address, etc). 

 Trying to find a doc saying the WLC announce peer groups on the discovery response.