Lightweight Access Point joining issues to WLC Part 1

In this post I will try to cover as many as possible problems due to AP can not join to WLC.

First of all we should know that there are two types of Access Points (I am only talking about Cisco products):

  1. Autonomous AP or Standalone AP
  2. Lightweight AP

Autonomous AP doesn’t need WLC to connect and it can be used in small office / Home office scenarios. (I will not go into detail, may in later post we will see that, how it works and configuration).

Lightweight AP: This type of AP can only be used with Wireless LAN Controllers. These can be used in medium to large deployments.

How to verify if it’s an autonomous AP or Lightweight?

Here are the two ways:

  • Connect to the AP using a console cable, and login to the AP (if you need to enter credentials, default username pass are Cisco, default enable password is Cisco). As a side note, the autonomous AP code prompts by default ap> and only requires you to enter an enable passowrd. The lightweight code asks you for username and password by default, and display by default the AP MAC address as a prompt. So this might be a first indication, but all this can be changed through configuration, so this is just a note, not an exact way yet.
  • On the AP console, type show version. If the AP runs an autonomous code, the version will show the string k9w7. If the AP runs a lightweight code, the version will show k9w8.
  • Want to know more about AP versions, Go here:  Understand AP IOS Images

Now we know that only LAP have to join WLC, without WLC this these kinds of AP will not work.

Before starting to find out the cause why AP not joining, first we must understand the behind the scene.

In order for the WLC to be able to manage the LAP, the LAP should discover the controller and register with the WLC. There are different methods that an LAP uses in order to discover the WLC.

There are for main events occurs:

  1. Discovery Requests
  2. Discovery Response
  3. Join Request
  4. Join Response

Refer to: LAP Registration to WLC

So now we assume that AP got the IP address, either statically or via DHCP.

Without IP AP will not do anything, so first we need to assign a IP to AP then only it can send discovery request.

Basic things to check:

  1. Is AP got IP via DHCP?
  2. Can you ping AP from WLC or vice versa.
  3. Is this specific VLAN (in which AP got the IP) blocked by anything on switch like STP?
  4. Check the logs on AP: it must start the discovery request for WLCs.

Till now if everything is ok then we can start with some command issues due to which LAP not join to WLC.

Scenario 1: Mismatch in Regulatory Domain

I have seen this errors many times:

We must enable debug capwap <events/error> enable or debug lwapp <events/error> enable

Sample Error Logs:

802.a or 80211bg Regulatory Domain (-E) does not match with country(AU )
AP RegDomain check for the country AU failed
Regulatory Domain check Completely FAILED The AP will not be allowed to join

These errors clearly show that there is a mismatch in the regulatory domain of the LAP and the WLC. To resolve this issue, add the country for which the AP was built to the list of countries supported on the controller from Wireless > Country. We have to disable all 802.11b/g and 802.11a radios to change the controller country codes list.

wirelesscountry

In my example, I only configured DE, this Country supports -E-   regulatory domain on AP:

The WLC can supports multiple regulatory domains but each regulatory domain must be selected before an LAP can join from that domain. When you purchase APs and WLCs, ensure that they share the same regulatory domain. Only then can the LAPs register with the WLC.

Here you can check the Wireless Compliance Status, specific country with specific Regulatory domain for Access Points.

Scenario 2: Certificate and Time

AP and controller needs to exchange certificate to create a secure tunnel for communication. These Certificates have creation and expiry date. If the time and date on WLC are wrong, the AP certificate will be refused because if it is not valid yet or not valid anymore.

We must run these debug commands to find out the exact error:

debug capwap errors enable and debug pm pki enable

Sample Error logs:

Does not include valid certificate in CERTIFICATE_PAYLOAD from AP MACADDRESS. Unable to free public key.
Current time outside AP cert validity interval: make sure the controller time is set.

To resolve this kind of issue, set the controller time and date to a present value from GUI: Command > Set Time or config time command from CLI

command_settime

We can also receive this kind of message if AP certificate is not valid anymore or corrupted: In this case we must return this AP to our supplier and take a new one.

We can check the AP certificate validity by this command: show crypto ca certificates

 Scenario 3: Firewall Blocking Necessary Ports

When APs and controllers are in different subnets, make sure that routing and firewall filters allow traffic both ways.

Enable these UDP ports for LWAPP traffic:

UDP ports 12222 and 12223 must be open in both directions.

Enable these UDP ports for CAPWAP traffic:

UDP ports 5246 and 5247 must be open in both directions.

If the AP cannot access the controller on UDP port 5246 (CAPWAP Control), the discovery and join requests never reach the controller. The result is that the AP is not seen on the controller, and the debug capwap event enable command on the controller does not display any message about the AP.

If the controller cannot access the AP UDP port 5246 (CAPWAP Control), the discovery and join requests never reach the AP. The result is that the controller receives discovery requests, answers with discovery responses, but the AP does not get these responses and never moves to the join phase.

Scenario 4: Brand New Access Points

With new Access Points or even with the old AP, we can get some compatibility issues with WLC version.

Example: The 1600 and 3600 APs are new models, and require new controller codes. The 1600 AP requires controller code release 7.4.100.0 or later, and the 3600 AP requires controller code 7.2 or later. The same issue affects 802.11n APs and older controller codes. If the controller code is too old, the AP model is not recognized.

We must run these debug commands to find out the exact error:

debug capwap errors enable

Sample Error Logs

AP Associated. Base Radio MAC: MAC ADDRESS
AP Disassociated. Base Radio MAC: MAC ADDRESS
AP with MAC MAC ADDRESS is unknown.

To resolve this issue, we have to upgrade the controller code or have the AP discover a controller running the appropriate code version.

Check here the Cisco Software Compatibility Matrix

Find out the version on WLC here by GUI: Go to Monitor and check the Controller Summary

controller_summary

 

Via CLI:

(WLAN1) >show sysinfo
Manufacturer's Name.............................. Cisco Systems Inc.
Product Name..................................... Cisco Controller
Product Version.................................. 7.0.240.0
RTOS Version..................................... 7.0.240.0
Bootloader Version............................... 4.0.191.0
Emergency Image Version.......................... N/A
Build Type....................................... DATA + WPS
System Name...................................... WLAN1
System Location.................................. Test Lab
System Contact................................... Sandeep
System ObjectID.................................. 1.3.6.1.4.1.9.1.828
IP Address....................................... 10.99.80.1
System Up Time................................... 3 days 23 hrs 12 mins 31 secs
System Timezone Location......................... (GMT +1:00) Amsterdam, Berlin, Rome, Vienna
Configured Country............................... DE  - Germany
Operating Environment............................ Commercial (0 to 40 C)
Internal Temp Alarm Limits....................... 0 to 65 C
Internal Temperature............................. +42 C

 

Part 2 coming soon……. 🙂

Autonomous AP and Migration to CAPWAP

  • Autonomous APs use a firmware/software which offers wireless service without a controller.
  • We can configure/manage each autonomous AP using the CLI via a console port or Telnet/SSH.
  • Default credentials are none/Cisco (means no username is required, and default password is Cisco).
  • Once we connect a Autonomous AP(Without any configuration done from our side) to LAN then it tries to get a IP from DHCP server indefinitely.
  • Autonomous AP is easier to config. from web interface mode
  • Better to configure a static IP to AP via CLI ad then open a web browser to access via web interface.
  • This static IP address is assigned to the AP bridge interface, which is a virtual interface, also shared by all radios and Ethernet interfaces.
  • Basic configuration can be done by express setup but there are many limitation of this setup.
    1. Cannot edit SSIDs (delete SSIDs and re-create them).
    2. Cannot assign SSIDs to specific radio interfaces (default enabled on all radio interfaces).
    3. Cannot configure multiple WEP keys.
    4. Cannot assign an SSID to a VLAN that is already configured on the AP.
    5. Cannot configure combinations of authentication types such as MAC address authentication and EAP authentication on the same SSID.
  • Migration of autonomous APs to CAPWAP by uploading a CAPWAP firmware image to the AP(k9w8 – CAPWAP code for an AP). The conversion can be done several ways:
    1. 1st Way: Use an IOS-to-CAPWAP upgrade tool running on Windows. The autonomous AP must be running Cisco IOS Software version 12.3(7) JA or higher, and the WLC should be running version 3.1 or later.  PC with the Lightweight upgrade tool is also required. In the IOS-to-CAPWAP upgrade tool, we would input a text file (containing each AP to convert IP address, and telnet and privilege mode credentials) and would provide the information needed for the conversion process (controller details, TFTP server IP address, and CAPWAP firmware filename). The tool would then connect to each AP and run the conversion routine.
    2. 2nd Way: We can also convert the AP from the Cisco WCS interface. First add the autonomous AP to the WCS (from Configure > Access Points > Add Autonomous AP). After the autonomous AP is added to WCS, go to Configure > Migration Templates and create a template to convert the autonomous AP to CAPWAP.
    3. 3rd Way: Convert the AP directly from the CLI with the command archive download software ftp|tftp://<address and name of the minimal CAPWAP file to use>.
  • We can convert back the AP from CAPWAP to Cisco IOS(Autonomous)
    1. Download the Cisco IOS firmware image for specific AP. Put this image in a TFTP server (k9w7 – IOS version of the AP code). Then we must associate the CAPWAP AP to the controller, and run, from the controller CLI (migration is not available from the controller web interface), the command config ap tftp-downgrade tftp-server-ip-address filename access-point-name.