You are currently viewing Troubleshooting Access Point registration with respective WLC

Troubleshooting Access Point registration with respective WLC

Lightweight Access Point sometimes fails to join a WLC due to various reasons. There can be various possible reasons for this issue. We need to understand the process that APs use to discover and join a WLC. Besides, we’ll cover some typical reasons behind the registration issue. At the end of this document, we’ll cover the DHCP Option 43 to troubleshoot the issue.

The typical reasons behind the AP registration failure with the WLC are as follows:

  1. Mismatch in the regulatory domain
  2. Firewall blocking the ports, AP fails to join the WLC
  3. The duplicate IP address in the network
  4. Bad address ‘Microsoft DHCP’
  5. Controller receiving AP discovery message on the wrong VLAN
  6. AP Authorization list enabled on the WLC, LAP, not in this authorization list
  7. Controller time is outside the certificate validity interval
  8. Certificate or Public key corruption on the AP
  9. LAPs with MESH image not able to join WLC

There can be two troubleshooting approaches depending on the access we have with either the AP or the WLC. We can either Debug from the AP or Debug from the Controller.

Let us start with understanding the process used by an AP to discover and join Cisco WLC. This will help us in clearly defining the issue.

LAP REGISTRATION WITH (WLC) – Wireless Lan Controller

  1. IP address.
  2. Find candidate WLC 
  3. Select a WLC.
  4. Register with the WLC.



LAP REGISTRATION

STEP 1

  • Once an AP Boots up, it looks for an IP address from the DHCP server.
  • LAP issues DHCP discover to get an IP address (unless it has a previously configured IP) — [Discover Messages]
  • The DHCP server responds with IP address as a response to discover messages —–  [offer Messages]

STEP 2

 Layer 3 discovery (supported on all platforms with CAPWAP)

‘Layer 3 Discovery’

  1. Capwap discovery request broadcast on the local subnet (IP broadcast)
  2. Capwap discovery request sent to all locally stored WLC IP addresses.
  3. Capwap discovery request sent to IP address learned through vendor-specific DHCP option 43.
  4. Capwap discovery request sent to IP address learned through DNS “resolution of cisco-capwap-controller.domain”

LWAPP / CAPWAP discovery response message

WLC embeds this important information in the discovery response:-

  • The Controller Sysname.
  • The Controller Type / Model. 
  • Licenses.
  • Current AP’s.
  • The controller AP capacity & its current AP load.
  • The Master Controller Flag.
  • An AP-manager IP add.

The lap uses this information to make a controller selection.

“WLC SELECTION ALGORITHM”

  1. If the lap has been previously configured with Primary, Secondary &/ or Tertiary controller, the lap will attempt to join these first (specified using the controller sysname).
  2. Attempt to join a controller configured as a Master controller.
  3. Attempt to join a controller with greater excess capacity. 

Step 1

Access Point

Wireless Lan Controller

Lap & WLC mutually authenticate using x.509 certificates in the join phase.

Step 2

Access Point

Wireless Lan Controller

The controller also embeds its own digitally signed x.509 certificate in the join response. 

After the AP validates the certificate,

Step 3

Access Point

Wireless Lan Controller

Final Step :

Access Point

Wireless Lan Controller

– Sync firmware on WLC & LAP

– WLC provisions the cap with configuration parameters.

– The registration process complete.

TROUBLESHOOTING AP DISCOVERY AND JOINING WLC



DIAGRAM

Out of the various steps mentioned above, we are going to consider the ‘DHCP OPTION 43 process’ in this lab.

  • The DHCP server includes information in all DHCP advertisements that includes one or more IP addresses.
  • The AP’s will then send discover requests to these IP’s
  • We will see how to configure DHCP OPTION 43
  • When DHCP servers are programmed to offer WLC IP addresses as option 43 for other Cisco Aironet LAP s, the sub-option TLV block is defined in this way:
  • • Type—0xf1: 0xf1 (decimal 241).
  • • Length—Number: Number of controller IP addresses * 4.
  • • Value—List: List of the WLC management interfaces, typically translated to hexadecimal values. 
  • The hex string is assembled by concatenating the TLV values shown here:
  • Type + Length + Value Type is always f1 (hex). Length is the number of controller management IP addresses times 4 in hex. Value is the IP address of the controller listed sequentially in hex.
  • In our Lab, we have one controller with a management interface IP address, 10.1.1.1. The type is f1 (hex). The length is 1 * 4 = 4 = 04 (One Controller 1*4=04) (hex). The IP addresses translate to 0a01010a Assembling the string then yields f1040a010101. The resulting Cisco IOS command added to the DHCP scope is listed here: 
  • option 43 hex f1040a010101

As part of our investigation to clearly define the problem, we should first check the AP association page on all the controllers that you expect the AP to contact as part of the discovery process.

Use Monitor > Statistics > AP Join to help define the problem

Controller Discovery Issues: DHCP Option 43

The AP can use option 43 in DHCP. We need to confirm that the option is configured in the correct format.

  • Monitor the AP console output when the AP is registering.
  • The controller management IP information may be sent as part of option 43.
*APRIL 2 03:42:28.655: %DHCP-6-ADDRESS_ASSIGN: Interface BVI1 
assigned DHCP address 10.1.1.10, mask 255.255.255.0, hostname AP88f0.31b2.6a4c *APRIL 2 03:42:32.379: APAVC: Succeeded to activate all the
STILE protocols. *APRIL 2 03:42:32.379: APAVC: Registering with CFT *APRIL 2 03:42:32.379: APAVC: CFT registration of delete callback succeeded *APRIL 2 03:42:32.379: APAVC: Reattaching Original Buffer pool for system use *APRIL 2 03:42:32.379: Pool-ReAtach: paks 42878 radio42270 %Default route without gateway, if not a point-to-point interface,
APRIL affect performance *APRIL 2 03:42:39.775: AP image integrity check PASSED *APRIL 2 03:42:39.779: %LWAPP-3-CLIENTERRORLOG: Config load from flash failed.
Initialising Cfg *APRIL 2 03:42:39.847: validate_sha2_block:No SHA2 Block present on this AP. *APRIL 2 03:42:39.867: %LINK-5-CHANGED: Interface Dot11Radio0,
changed state to reset *APRIL 2 03:42:39.867: %LINK-5-CHANGED: Interface Dot11Radio1,
changed state to reset *APRIL 2 03:42:49.871: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host
255.255.255.255 port 514 CLI Request Triggered Translating "CISCO-CAPWAP-CONTROLLER"...domain server (255.255.255.255) *APRIL 2 03:43:00.875: %CAPWAP-5-DHCP_OPTION_43: Controller address
10.1.1.1 obtained through DHCP *APRIL 2 03:43:02.791: %CDP_PD-4-POWER_OK: Full power - NEGOTIATED inline
power source *APRIL 2 03:43:03.895: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up *APRIL 2 03:43:04.895: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0,
changed state to up *APRIL 2 03:43:05.131: %LINK-6-UPDOWN: Interface Dot11Radio1, changed state to up *APRIL 2 03:43:06.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1,
changed state to up *APRIL 2 03:44:56.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent
peer_ip: 10.1.10.10 peer_port: 5246 *APRIL 2 03:44:56.439: %CAPWAP-5-DTLSREQSUCC: DTLS connection created successfully
peer_ip:10.1.1.1 peer_port: 5246 *APRIL 2 03:44:56.443: %CAPWAP-5-SENDJOIN: sending Join Request to 10.1.1.1

BB_SWITCH 

DHCP SERVER

Conf t 
ip dhcp pool AP 
network 10.1.1.0 255.255.255.0

default-router 10.1.1.254
option 43 f104.0a01.0101 
(Note : It’s the IP address of WLC – 10.1.1.1)

We can see the AP’s got registered with WLC – AP L3700.1, L3700.2, L3700.3, IP ADDRESS 10.1.1.10, 10.1.1.11, 10.1.1.12 respectively in the outcome.