Wireless LAN Controller (WLC) Troubleshoot FAQ

Document ID: 69561

Questions
Introduction Troubleshoot FAQ NetPro Discussion Forums − Featured Conversations Related Information

Introduction
This document provides information on the most frequently asked questions (FAQ) about the troubleshoot of Cisco Wireless LAN (WLAN) Controllers (WLCs). Refer to Cisco Technical Tips Conventions for more information on document conventions.

Troubleshoot FAQ
Q. What is the procedure to upgrade the operating system (OS) software on a Cisco WLC?
A. The document Wireless LAN Controller (WLC) Software Upgrade provides the procedure for a software upgrade on your WLC.

Q. We have finished our initial deployment of lightweight access points (APs). When our clients move from one end of the building to the other, they stay associated with the AP to which they were closest. The clients do not appear to be handed off to the next−closest AP until the signal strength from the initial AP is completely depleted. Have we missed a setting that allows roaming between APs?
A. The client movement from AP coverage area to a different AP zone is entirely controlled by the WLC. The WLC talks between its APs and manages their signal strength on the basis of how each AP senses the others. The client movement from AP to AP is entirely controlled by the client itself. The radio within the client determines when the client wants to make the jump from one AP to the other. No setting on the WLC, AP, or the rest of your network can make the client move before it wants to roam to a different AP.

Q. Can I install an access point (AP) at a remote office and install a Cisco WLC at my headquarters? Does the Lightweight AP Protocol (LWAPP) work over a WAN?
A. Yes, you can have the WLCs across the WAN from the APs. LWAPP works over a WAN. Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Use Remote Edge AP (REAP) mode. REAP allows the control of an AP by a remote controller that is connected via a WAN link. Traffic is bridged onto the LAN link locally, which avoids the need to unnecessarily send local traffic over the WAN link. This is precisely one of the greatest advantages of having WLCs in your wireless network. Note: Not all lightweight APs support REAP. For example, the 1030 AP supports REAP, but the 1010 and 1020 AP do not support REAP. Before you plan to implement REAP, check to determine if the APs support it. Cisco IOS® Software APs that have been converted to LWAPP do not support REAP.

Q. I want to set up the Cisco 1030 Lightweight Access Point (AP) with a Cisco WLC in Remote Edge AP (REAP) mode. In this mode, is all wireless traffic tunneled back to the WLC? Additionally, if the AP cannot contact the WLC, what happens to the wireless clients?
A. The 1030 AP tunnels all WLC traffic (control and management traffic) to the WLC via Lightweight AP Protocol (LWAPP). All data traffic stays local to the AP. The 1030 REAP can only reside on a single subnet because it cannot perform IEEE 802.1Q VLAN tagging. As such, traffic on each service set identifier (SSID) terminates on the same subnet on the wired network. So, while wireless traffic may be segmented over the air between SSIDs, user traffic is not separated on the wired side. Access to local network resources is maintained throughout WAN outages. At times of WAN link outage, all WLANs except the first is decommissioned. Therefore, use WLAN 1 as the primary WLAN and plan security policies accordingly. Cisco recommends that you use a local authentication/encryption method, such as the Wi−Fi Protected Access (WPA) Pre−Shared Key (WPA−PSK), on this first WLAN. Note: Wired Equivalent Privacy (WEP) suffices, but this method is not recommended because of known security vulnerabilities. If you use WPA−PSK (or WEP), properly configured users are still able to gain access to local network resources even when the WAN link is down.

Q. Can a Cisco IOS Software−based access point (AP) that has been converted to lightweight mode register with Cisco 4100 Series WLCs?
A. No, Cisco IOS Software−based APs that are converted to lightweight mode cannot register with the Cisco 40xx, 41xx, or 3500 WLCs. These lightweight APs (LAPs) can register only with the Cisco 4400 and the 2000 series WLCs. For information on the restrictions of APs that are converted to lightweight mode, refer to the Restrictions section of Upgrading Autonomous Cisco Aironet Access Points to Lightweight Mode.

Q. How do I set the Extensible Authentication Protocol (EAP) type on the WLC? I want to authenticate against an Access Control Server (ACS) appliance, and I get an "unsupported EAP" type in the logs.
A. There is no separate EAP type setting on the WLC. For Light EAP (LEAP), EAP Flexible Authentication via Secure Tunneling (EAP−FAST), or Microsoft Protected EAP (MS−PEAP), just configure IEEE 802.1x or Wi−Fi Protected Access (WPA) (if you use Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

802.1x with WPA). Any EAP type that is supported on the RADIUS back end and on the client is supported via the 802.1x tag. The EAP setting on the client and RADIUS server must match. In order to enable EAP through the GUI on the WLC, complete these steps: 1. From the Summary window, click WLANs. 2. Click New on the right side of the window in order to define a new service set identifier (SSID) for the WLAN. 3. In the WLAN > New window, enter the SSID for the WLAN network, choose the WLAN identifier from the drop−down menu, and click Apply. The WLAN > Edit window appears. 4. Choose Security Policies > Layer 2 Security, choose 802.1x authentication from the drop−down menu, and click Apply. You can also configure the 802.1x parameters that are available in the same window. Then, the WLC forwards EAP authentication packets between the wireless client and the authentication server. For information on how to enable the EAP option on WLCs through the command−line interface (CLI), refer to the Configuring Layer 2 Security section of Configuring Wireless LANs.

Q. Is dynamic VLAN assignment that is based on the user ID (through RADIUS) supported on WLCs in Lightweight Access Point Protocol (LWAPP) mode with Cisco Aironet 1242 access points (APs)? If so, how many VLANs can be mapped to one service set identifier (SSID)?
A. Yes, dynamic VLAN assignment that is based on the client user ID (through RADIUS) is supported on WLCs. When a VLAN Interface−Name or VLAN−Tag is present in a RADIUS Access Accept, the system places the client on a specific interface. For more information, refer to the Configuring Identity Networking section of Configuring Security Solutions. An SSID (WLAN, in controller terminology) can only be mapped to one VLAN (one interface, in controller terminology). So, you can have 16 different VLANs to 16 different SSIDs. If you use a Cisco IOS Software−converted AP (like Aironet 1241), the radio interface only supports 8 different SSIDs. This is a hardware limitation.

Q. We are in preparation to deploy access control lists (ACLs) on our WLCs. We have service set identifiers (SSIDs) that are all associated with a different VLAN tag and, therefore, with different IP segments. On the primary user WLAN, we want unrestricted IP access to the network. On our secondary WLAN, we want to restrict access to a few specific servers (four servers) on the internal network, plus access to the Internet. We have three questions. First, if we configure an ACL, does the list processing occur down the sequence order and stop when an entry is hit?
A. ACLs are read from the top down, stopping when an entry is matched.

Q. Second, if we have defined an access control list (ACL) and nothing matches the list, is the traffic permitted or denied? In other words, if all our rules reference the IP network of the restricted segment, what
Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

happens to traffic from our unrestricted subnet?
A. There is an implicit deny at the end of every access list. So, if nothing is matched, the traffic is denied. You must add permit statements for your unrestricted subnet if this subnet is on the same interface.

Q. Lastly, is there any way to apply an access control list (ACL) on a per−WLAN or a per−logical interface basis?
A. Yes, it is possible to apply an ACL to the WLAN. This is the command syntax:
config wlan acl [<Wlan id>] [<ACL name> | none]

Q. Does the Cisco 2000 Series WLC support Web Authentication for guest users? Is the WLC solution able to refrain from the broadcast of the service set identifier (SSID)?
A. Web Authentication is supported on all Cisco WLCs. In order to enable this feature, complete these steps: 1. From the GUI, click Edit in order to edit the specific WLAN parameters, check the Web Authentication check box, and click Apply. 2. Save and reboot in order for the Web Authentication feature to take effect. 3. Under Security, choose Local Net User, and complete these actions: a. Define the guest username and password for the guest to use in order to log on. These values are case sensitive. b. Select the WLAN ID that you use. A. In order to disable SSID broadcast, uncheck the Broadcast SSID check box in the WLAN Edit window.

Q. We have provisioned two WLANs with two different dynamic interfaces. Each interface has its own VLAN, which is different than the management interface VLAN. This seems to work, but we have not provisioned the trunk ports to allow the VLANs that our WLANs use. Does the access point (AP) tag the packets with the management interface VLAN?
A. The AP does not tag packets with the management interface VLAN. The AP encapsulates the packets from the clients in Lightweight AP Protocol (LWAPP), and then passes the packets on to the WLC. The WLC then strips the LWAPP header and forwards the packets to the gateway with the appropriate VLAN tag. The VLAN tag depends on the WLAN to which the client belongs. The WLC depends on the gateway to route the packets to their destination. In order to be able to pass traffic for multiple VLANs, you must configure the uplink switch as a trunk port. This diagram explains how VLANs work with controllers:

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Q. If I select a WLAN ID on a MAC filter under security, and I have a MAC−filtered WLAN and a completely open WLAN, does the client choose the open WLAN by default? Or does the client automatically associate with the WLAN ID that is set on the MAC filter? Also, why is there an "interface" option on a MAC filter? What purpose does this option serve?
A. The client can associate to any WLAN to which the client is configured to connect. The interface option in the MAC filter gives the ability to apply the filter to either a WLAN or an interface. If multiple WLANs are tied to the same interface, you can apply the MAC filter to the interface without the need to create a filter for each individual WLAN.

Q. We have begun the conversion of more than 200 access points (APs) from Cisco IOS Software to Lightweight AP Protocol (LWAPP) with a Cisco 4404 WLC. We have completed the conversion of 48 APs and we receive a message on the WLC that states: "[ERROR] spam_lrad.c 4212: AP cannot join because the maximum number of APs on interface 1 is reached". Why does the error occur?
A. You must create additional AP−manager interfaces in order to support more than 48 APs. Otherwise, you receive the error that looks like this:
Wed Sep 28 12:26:41 2005 [ERROR] spam_lrad.c 4212: AP cannot join because the maximum number of APs on interface 1 is reached.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Configure multiple AP−manager interfaces and configure primary/backup ports that other AP−manager interfaces do not use. You must create a second AP−manager interface in order to bring up additional APs. However, make sure that your primary port and backup port configurations for each manager do not overlap. In another words, if AP−manager 1 uses port 1 as the primary and port 2 as the backup, AP−manager 2 must use port 3 as the primary and port 4 as the backup.

Q. I have configured 512 users on my controller. Is there any way to increase the default number of users on the WLC?
A. The local user database is limited to a maximum of 2048 entries and is set to a default value of 512 entries at the Security > General page. This database is shared by local management users (including lobby ambassadors), net users (including guest users), MAC filter entries, and disabled clients. Together, all of these types of users cannot exceed the configured database size. If you try to configure more than 512 users without increasing the default database size, the WLC displays an error. For example, if you try to add a MAC filter when there are already 512 users configured in the database and the database size is not increased from its default value, this error message appears.
Error in creating MAC filter

In order to increase the local database to 2048, use this command from the CLI.
<Cisco Controller>config database size ? <count> Enter the maximum number of entries (512−2048)

Q. How many WLCs can I have in the same mobility group?
A. You can place up to 24 regular WLCs (Cisco 2000, 4100, and 4400 series) in a single mobility group. You can configure up to 12 Wireless Services Module (WiSM) blades in one mobility group. Therefore, up to a maximum of 3600 access points (APs) are supported in a single mobility group.

Q. I changed my WLC to Master Controller mode and saved the configuration. Later, when I rebooted the WLC, I could not see WLC retaining the Master Controller Mode. Why? Is this an issue or a normal behavior?
A. This is the expected behavior. Master Controller mode is normally used only while new access points are added to the Cisco Wireless LAN Solution (Cisco WLAN Solution). When no more access points are added to the network, Cisco WLAN Solution recommends that you disable the master controller. Because the master controller is normally not used in a deployed network, the master controller setting is automatically disabled upon reboot or OS code upgrade.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Q. Is there any way to recover my 2006 WLC password?
A. No, there is no way to recover the password on your WLC. If you use the Cisco Wireless Control System (WCS) in order to manage the WLC, Wireless LAN Controller Module (WLCM) or Wireless Services Module (WiSM), you should be able to access the controller from the WCS and create a new admin user without logging into the controller itself. Or, if you did not save the configuration on the controller after you deleted the user, then a reboot (power cycling) of the controller should bring it back up with the deleted user still in the system. If you do not have the default admin account or another user account with which you can log in, your only option is to default the controller to factory settings and reconfigure it from scratch.

Q. I have a Wireless LAN Controller (WLC) 4402 and I use 1240 lightweight access points (LAPs). I am trying to enable 128−bit encryption on the WLC. When I select 128−bit WEP encryption on the WLC, I receive an error that says that 128−bit is not supported on the 1240s. Why do I receive this error?
A. The key lengths shown on the WLCs are actually the number of bits that are in the shared secret and do not include the 24−bits of the Initialization Vector (IV). Many products, including the Aironet products, call it a 128−bit WEP key. In reality it is a 104−bit key with 24−bit IV. The key size of 104−bit is what you must enable on the WLC for 128−bit WEP encryption. If you select the 128−bit key size on the WLC, it is actually a 152−bit WEP key encryption.

Q. What is Link Aggregation (LAG)? How do I enable LAG on WLCs?
A. LAG bundles all of the distribution system ports of a controller into a single EtherCannel. This reduces the number of IP addresses needed in order to configure the ports on your controller. When LAG is enabled, the system dynamically manages port redundancy and load balances access points transparently to the user. Cisco 4400 Series Controllers support LAG in software release 3.2 and later, and LAG is enabled automatically on the controllers within the Cisco WiSM and the Catalyst 3750G Integrated Wireless LAN Controller Switch. Without LAG, each distribution system port on the controller supports up to 48 access points. With LAG enabled, the logical port of a 4402 controller supports up to 50 access points, the logical port of a 4404 controller supports up to 100 access points, and the logical port on each Cisco WiSM controller supports up to 150 access points. Refer to Enabling Link Aggregation for more information on LAG and how to enable LAG on WLCs.

Q. I changed the lightweight access point (LAP) mode of my 1030 access point (AP) from Local to Bridge mode and the 2006 WLC no longer detects it. How can I restore the 1030 AP back to it's Local AP mode?
A. There are considerations and required steps before you place an LAP into Bridge mode that must be followed in order, or you can cause the LAP to not join the controller. The AP that is directly associated to the controller is the Bridge roof−top access point (RAP), and Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Remote mode LAPs are pole−top access points (PAPs). Complete these steps in order to enable bridging on the controller, and to prepare LAPs for use as RAP/PAPs. Begin with the LAPs joined to the Layer 2 Lightweight Access Point Protocol (LWAPP) mode controller, in Local mode. 1. From the GUI, go to the Wireless page and make a note of the intended Bridge AP MAC addresses. 2. Click Bridging. 3. Check Enable Zero Touch Configuration. 4. Enter an ASCII or HEX Bridging Shared Secret Key that is used to verify LAP identities. 5. Go to the Security page, and click MAC Filtering located under AAA on the left. Add the MAC addresses of the intended Bridge APs, and specify the WLAN and the associated Interface. 6. Go to the Wireless page. Bridge capable LAPs show Bridging Information in addition to Detail in order to help identify them. Click Detail on one of your intended Bridge APs. Under Inventory Information on the right side, verify the LAP model and if REAP mode is supported. 7. Check AP Static IP, and enter an IP address, Netmask, and Gateway in the subnet of the interface that is used. Ensure these IPs are not in the DHCP scopes that are given to clients. You are now prepared to configure the AP mode, change the role of the AP from Local to Bridge AP, and click Apply. If the setup does not work as expected, follow the recovery process outlined here. 1. From the controller GUI, choose Wireless > Bridging and check Enable Zero Touch Configuration. 2. From the controller GUI, choose Security > MAC Filtering and add a new MAC filter with AP MAC address. 3. Go to the controller CLI and issue the config network allow−old−bridge−aps enable command. This allows the APs to join. Complete these steps once they join. 1. Go to the controller GUI and choose Wireless > Cisco APs > Detail. 2. Check if the AP supports REAP mode. This should be YES for indoor bridging APs. 3. Check the AP mode. If it says Bridge, then change it back to Local. This changes the Bridge AP to Normal AP.

Q. How does DHCP work with the WLC?
A. The WLC acts as a DHCP relay device. The WLC does the DHCP relay through the virtual interface. Typically, the 1.1.1.1 address is assigned to the virtual interface. This address can be any address. However, it must not be a routable address. These are the events that occur: 1. The WLAN client sees the administration−defined virtual address as the DHCP server address. The recommended address is usually 1.1.1.1 because this address is not normally a routable network address.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

2. The WLC shows the virtual address to the WLAN clients and the management interface address upstream. 3. The WLC acts as a DHCP relay (Bootstrap Protocol [BOOTP] relay) device. Note: When the internal DHCP server is used, the lightweight access point (AP) should be directly connected to the WLC. Also, you cannot share a DHCP scope between two or more WLCs.

Q. I recently set up the 4402 Wireless LAN Controller (WLC) to manage the new Cisco lightweight access points (LAPs). I run PIX 501 version 6.3(5) and also use the PIX as a DHCP server for the clients. However, whenever the PIX gets a request from the controller for the wireless clients, it drops the request and the clients do not get an IP address. Why does this happen?
A. The PIX can act as a relay agent. However, in this case the WLC is a relay agent for the client. The PIX does not support DHCP requests from a relay agent. It ignores these requests. Clients must be directly connected to the PIX Firewall and cannot send requests through another relay agent or a router. The PIX has limited functionality in the context of DHCP. It can work as a simple DHCP server for internal hosts that are directly connected to it, so it can maintain its table based on the MAC addresses that are directly connected and that it can see. That is why an attempt to assign addresses from a DHCP relay are not available and the packets are discarded. Refer to Using DHCP Relay for more information on how to use PIX in order to provide DHCP services.

Q. I have setup a guest Wireless LAN and the controller is physically separated from my internal LAN. I decided to use the internal DHCP feature of this controller but my wireless clients do not get IP addresses from the controller. How do the wireless guest users get IP addresses from the controller when they are connected on a physically separate network?
A. One possible solution is to put a DHCP server override on the WLAN settings page for the SSID in question (in this case, it is guest SSID). Then point this DHCP server override to the IP address of the port on the controller to which this guest WLAN is associated.

Q. I have a 4400 Series Wireless LAN Controller (WLC) and lightweight access points (LAPs) registered to the WLC. I have configured WLANs for the clients to connect to on the WLC. The problem is that the WLC does not broadcast the service set identifiers (SSIDs) that I configured for the WLANs. Why?
A. In order for the WLCs to be able to broadcast SSIDs, the Admin Status and the Broadcast SSID parameter must be enabled for the WLANs. Complete these steps in order to enable Admin Status and Broadcast SSID.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

1. Go to the controller GUI and choose Controller > WLANs. The WLANs page appears. This page lists the WLANs that are configured. 2. Select the WLAN for which you want to enable broadcasting of the SSID and click Edit. 3. In the WLAN > Edit page, check Admin Staus in order to enable the WLAN. Also, check Broadcast SSID in order to ensure that the SSID is broadcast in the beacon messages sent by the AP.

Q. We have a wireless network with over 500 access points (APs), and we have some VLANs that can only exist in certain buildings for security reasons. How do I restrict a service set identifier (SSID) by AP so that every SSID is not sent to every AP on the system?
A. You can use the WLAN Override feature. Complete these steps in order to configure WLAN Override: 1. In the WLC GUI, navigate to Wireless and choose whether you want to work with the IEEE 802.11b/g radios or the IEEE 802.11a radios. 2. In order to select the AP that you want to modify, click the Configure link that is next to the name of that AP. 3. From the WLAN Override drop−down menu, choose Enable. Note: The WLAN Override menu is the last item on the left side of the window. The list of all WLANs that are configured on the WLC appears. 4. From this list, check the WLANs that you want to appear on the AP, and click Apply. 5. Save your configuration after you make these changes. If you save your configuration, the changes remain when the WLC reboots.

Q. I have ten Cisco 1000 Series Lightweight Access Points (LAPs) and two WLCs in the same VLAN. How can I register six LAPs to associate to WLC 1, and the other four LAPs to associate to the WLC 2?
A. The Lightweight AP Protocol (LWAPP) allows for dynamic redundancy and load balancing. For example, if you specify more than one IP address for option 43, an LAP sends LWAPP discovery requests to each of the IP addresses that the AP receives. In the WLC LWAPP discovery response, the WLC embeds this information: ♦ Information on the current LAP load, which is defined as the number of LAPs that are joined to the WLC at the time ♦ The LAP capacity ♦ The number of wireless clients that are connected to the WLC The LAP then attempts to join the least−loaded WLC, which is the WLC with the greatest available LAP capacity. Furthermore, after an LAP joins a WLC, the LAP learns the IP addresses of the other WLCs in the mobility group from its joined WLC. Subsequently, the AP sends LWAPP primary discovery requests to each of the WLCs in the mobility group. The WLCs respond with a primary discovery response to the AP. The primary discovery response includes information about the WLC type, total capacity, and current AP load. As long as the WLC has the "AP Fallback" parameter enabled, the AP can decide to change over to a less−loaded WLC. Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Alternatively, if you want the LAP to connect to a specific WLC, you can configure the primary, secondary and tertiary controller names when the LAP is primed for the first time. This way when the LAP is deployed, the LAP searches for and registers with the WLC which is marked as primary. If the primary WLC is not available, it tries to register to the secondary WLC, and so on.

Q. What is the difference between Remote−Edge AP (REAP) and Hybrid−REAP (H−REAP)?
A. This table sumarrizes the differences between REAP and H−REAP.

Refer to Remote−Edge AP (REAP) with Lightweight APs and Wireless LAN Controllers (WLCs) Configuration Example for more information on REAP. Refer to Configuring Hybrid−REAP for more information on H−REAP.

Q. How can I setup the controller/LAP to re−authenticate with the RADIUS server every three minutes or on any specified time period?
A. The session timeout parameter in the WLAN > Edit page can be used to accomplish this. By default the session timeout parameter is configured for 1800 seconds before a reauthentication happens. Change this value to 180 seconds in order to make the client reauthenticate after three minutes. Refer to the WLANs > Edit section of Cisco Wireless LAN Controller Online Help, Release 3.2 for more information.

Q. Why do I see these error messages on the console?
A. This can be due to high CPU load. When the controller CPU is heavily loaded (for example, when it does file copies or other tasks), it does not have time to process all of the ACKs that the NPU sends in response to configuration messages. When this happens, the CPU generates error messages. However, the error messages do not impact service or functionality.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

This is documented in the Heavily Loaded Controller CPU section of the Release Notes for Cisco Wireless LAN Controllers and Lightweight Access Points for Release 3.2.116.21 .

Q. What is the Auto−anchor Mobility feature in Unified Wireless Networks?
A. Auto−anchor Mobility (or guest WLAN mobility) is used to improve load balancing and security for roaming clients on your wireless LANs (WLANs). Under normal roaming conditions, client devices join a WLAN and are anchored to the first controller that they contact. If a client roams to a different subnet, the controller to which the client roams sets up a foreign session for the client with the anchor controller. However, with the use of the Auto−anchor Mobility feature, you can specify a controller or set of controllers as the anchor points for clients on a WLAN. In Auto−anchor Mobility mode, a subset of a mobility group is specified as the anchor controllers for a WLAN. You can use this feature to restrict a WLAN to a single subnet, regardless of a client's entry point into the network. Clients can then access a guest WLAN throughout an enterprise but still be restricted to a specific subnet. Auto−anchor Mobility can also provide geographic load balancing because the WLANs can represent a particular section of a building (such as a lobby, a restaurant, and so on), effectively creating a set of home controllers for a WLAN. Instead of being anchored to the first controller that they happen to contact, mobile clients can be anchored to controllers that control access points in a particular vicinity. Note: Mobility anchor should not be configured for Layer 3 mobility. Mobility anchor is used only for Guest tunnelling. When a client first associates to a controller of a mobility group that has been preconfigured as a Mobility Anchor for a WLAN, the client associates to the controller locally, and a local session is created for the client. Clients can be anchored only to preconfigured anchor controllers of the WLAN. For a given WLAN, you should configure the same set of anchor controllers on all controllers in the mobility group. Refer to Auto−anchor Mobility for more information.

Q. I use Mobility Anchors in order to provide WLAN access for guests/visitors. I have one internal/remote/foreign controller, and two anchor controllers in the DMZ. All three controllers are in the same Mobility Group. The Mobility Anchor list of the internal controller includes the two DMZ controllers. Each of the two Mobility Anchor lists of the DMZ controller includes all three controllers. A WLAN client is connected to DMZ controller 1, through the internal controller. When DMZ controller 1 fails, the WLAN client does not automatically connect to DMZ controller 2. Why?
A. Presently there is no support for redundant WLCs in the DMZ for guest tunneling. This is why the client does not automatically connect to the other controller in the DMZ.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Q. Client AIR−P121AG−E−K9 successfully associates with an access point (AP) using Extensible Authentication Protocol−Flexible Authentication via Secure Tunneling (EAP−FAST), but when the associated AP is switched off, the client does not roam to another AP. This message appears continuously in the controller message log: "Fri Jun 2 14:48:49 2006 [SECURITY] 1x_auth_pae.c 1922: Unable to allow user into the system − perhaps the user is already logged onto the system? Fri Jun 2 14:48:49 2006 [SECURITY] apf_ms.c 2557: Unable to delete username for mobile 00:40:96:ad:75:f4"
A. When the card needs to do roaming, it sends an authentication request, but it does not correctly handle keys (does not inform AP/controller, does not answer reauthentications). This is documented in Cisco bug ID CSCsd02837 ( registered customers only) . The workaround is to switch from WPA2 to WPA1/TK1P.

Q. When I install the new Wireless Services Module (WiSM) blade in the 6509 switch and implement Protected Extensible Authentication Protocol (PEAP) with the Microsoft IAS server, I receive this error:
A. RADIUS and dot1x debugs show that the WLC sends an access request, but there is no response from the IAS server. Complete these steps in order to troubleshoot the problem: 1. Check and verify the IAS server configuration. 2. Check the log file. 3. Install software such as Ethereal which can give you authentication details. 4. Stop and start the IAS service.

Q. Do Cisco WLCs support the failover (or redundancy) feature?
A. Yes, if you have two or more WLCs in your WLAN network, you can configure them for redundancy. Refer to WLAN Controller Failover for Lightweight Access Points Configuration Example.

Q. How can I configure VLANs on my WLC?
A. In order to configure VLANs on your WLC, complete the procedure in the VLANs on Wireless LAN Controllers Configuration Example.

Q. How can I configure TACACS authentication for management users on the WLC?
A. Currently, TACACS is not supported on the WLCs. But you can set up RADIUS to authenticate management users to the WLC. ♦ On the WLCNavigate to Security, AAA, RADIUS Authentication, check the Management check box for each RADIUS server that you want to use, and click Apply to save the changes. Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

♦ On the Access Control Server (ACS)Enable Internet Engineering Task Force (IETF) RADIUS Attribute 006, and set it to Administrative. You can either perform this step for each user to which you want to give access, or you can set the attribute on a group and place users that you want to have access within the group.

Q. Does the Cisco 4400 Series WLC support Internetwork Packet Exchange (IPX) protocol? Does any Airespace product support IPX protocol?
A. No, IPX protocol is not supported on any platforms of the Cisco WLC.

Q. Can I upgrade directly from version 3.1.105 to version 3.2.78? Or do I need to upgrade to version 3.1.111 before I upgrade to 3.2.78?
A. Yes, you can upgrade directly to 3.2.78.0 from 3.1.105.0. After you set up a TFTP server, you can choose Commands > Download File and then select Code from the File Type menu in order to download the software to the WLC. Reboot the WLC after the file transfer in order for the new code to take effect.

Q. What happens to the wireless network when I perform a software upgrade? Do all the access points (APs) go down until they are upgraded? Or are they upgraded one at a time so that the wireless network can remain up (except for the specific APs that undergo the upgrade)?
A. The upgrade is done on the WLC as well as on all the lightweight APs (LAPs). Note: A LAP always has the same version as the WLC. You must reboot the WLC in order for the new software to take effect. Therefore, there is a period of network downtime. Be sure to schedule a maintenance window for the upgrade.

Q. Where can I find more information on the installation of WLCs in my WLAN network?
A. Refer to these documents: ♦ Cisco Wireless LAN Controller Module Q&A ♦ Cisco Wireless LAN Controllers Q&A

Q. What is the maximum number of access points (APs) supported on the 4402 and 4404 Wireless LAN Controllers (WLCs)?
A. The limitation on the number of supported access points is based on the hardware that you have. The 4402 WLC with two gigabit Ethernet ports comes in configurations that support 12, 25, and 50 access points. The 4404 WLC with four gigabit Ethernet ports supports 100 access points.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Q. Wireless LAN Clients associated with the lightweight access points (access points registered with the Wireless LAN Controller [WLC]) are not able to get IP addresses from the DHCP server. How do I proceed?
A. The common reason for this problem might be that the WLC and the DHCP server reside on different subnets. The WLC does not do routing and it depends on a Layer 3 device for routing between these different subnets. The possible workaround is to configure the DHCP server on the same subnet as the WLC. If the DHCP server is on a different subnet, then either a router must be in place in order to route between the WLAN and the DHCP server or you can configure the internal DHCP server on the WLC with a scope for the WLAN.

Q. The lightweight access points (LAPs) do not register with the controller. What could be the possible problem? I see these error messages at the controller:
A. When the access point (AP) sends the Lightweight Access Point Protocol (LWAPP) Join Request to the WLC, it embeds its X.509 certificate in the LWAPP message. It also generates a random session ID that is also included in the LWAPP Join Request. When the WLC receives the LWAPP Join Request, it validates the signature of the X.509 certificate using the APs public key and checks that the certificate was issued by a trusted certificate authority. It also looks at the starting date and time for the AP certificate validity interval and compares that date and time to its own date and time. This problem is due to an incorrect clock setting on the WLC. In order to set the clock on the WiSM modules you can use the show time and config time commands.

Q. A Lightweight Access Point Protocol (LWAPP) AP is unable to join its controller. The WLC log display a message similar to this:
A. The LWAPP tunnel between the AP and the WLC traverses a network path with an MTU under 1500 bytes. This causes the fragmentation of the LWAPP packets. This is a known bug in the controller ( Cisco bug ID CSCsd39911 ( registered customers only) ). The solution is to upgrade the controller firmware to 4.0(155).

Q. Does all network traffic from and to a WLAN Client tunnel through a Wireless LAN Controller (WLC) once the access point (AP) gets registered with the controller?
A. When the AP joins a controller, a Lightweight Access Point Protocol (LWAPP) tunnel is formed between the two devices. All traffic, including all client traffic, is sent through the LWAPP tunnel. The only exception to this is when an AP is in Remote−Edge AP (REAP) mode. When the AP is in REAP mode the control traffic is still tunneled to the controller but the data traffic is bridged locally on the local LAN.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Q. My 1131 lightweight access point (LAP) does not register with my 4402 Wireless LAN Controller (WLC). What can be the possible reason for this?
A. One common reason is that the Lightweight Access Point Protocol (LWAPP) Transport Mode is configured on the WLC. A 4402 WLC can operate in both Layer 2 and Layer 3 LWAPP mode. Whereas, an 1131 LAP can only operate in Layer 3 mode. Layer 2 mode is not supported on the 1131 LAP. So, if the WLC is configured with the LWAPP Transport Mode of Layer 2, then your LAP does not join the WLC. In order to overcome this problem, change the LWAPP Transport Mode of the WLC from Layer 2 to Layer 3. In order to change the LWAPP Transport Mode using the GUI, go to the WLC page and locate the second selection in the main field which is LWAPP Transport Mode. Change this to Layer 3 and reboot the controller. Now, your LAP is able to register with the controller.

Q. I have two Wireless LAN Controllers (WLCs) named WLC1 and WLC2 configured within the same Mobility group for failover. My lightweight access point (LAP) is currently registered with WLC1. If WLC1 fails, does the AP registered to WLC1 reboot during its transition towards the surviving WLC (WLC2)? Also, during this failover, does the WLAN client lose WLAN connectivity with the LAP?
A. Yes, the LAP does de−register from WLC1, reboot, and then re−registers with WLC2, if WLC1 fails. Since the LAP reboots, the associated WLAN clients lose the connectivity to the rebooting LAP.

Q. Can I use the internal DHCP server on the WLC in order to assign IP addresses to the lightweight access points (LAPs)?
A. You can accomplish this with version 4.0 on the WLC. All other versions can assign IP address only to the clients.

Q. What is the use of pre−authentication access control lists (ACLs) in Wireless LAN Controllers (WLCs)?
A. Pre−authentication ACLs are normally used for external web authentication with the 2000 Series WLCs. For a Cisco 2000 Series WLC, you must configure a pre−authentication ACL on the WLAN for the external web server. This ACL should then be set as the WLAN pre−authentication ACL under Web Policy. The pre−authentication ACL then redirects the client to the external authentication URL (on the external web server). Here is an example of a pre−authentication ACL:

In this example 192.168.2.70 is the IP address of the external web server. Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

However, you do not need to configure any pre−authentication ACL for Cisco 4100 Series WLCs and Cisco 4400 Series WLCs.

Q. In a Wireless LAN Controller (WLC) and Lightweight Access Point Protocol (LWAPP) setup, what Differentiated Services Code Point (DSCP) values are passed for voice. We have a standard configuration on our switches and want to make sure the wireless network matches with the Wired LAN side. Can I just configure the same values as on the switch ports that the WLC is connected to? How is Quality of Service (QoS) implemented on the controller?
A. Cisco Unified Wireless Network (UWN) Solution WLANs support four levels of QoS: ♦ Platinum/Voice ♦ Gold/Video ♦ Silver/Best Effort (default) ♦ Bronze/Background You can configure the voice traffic WLAN to use Platinum QoS, assign the low−bandwidth WLAN to use Bronze QoS, and assign all other traffic between the remaining QoS levels. Refer to Configuring Quality of Service for more information.

Q. What is PKC and how does it work with the Wireless LAN Controller (WLC) ?
A. PKC stands for Proactive Key Caching. It was designed as an extension to the 802.11i IEEE standard. PKC is a feature enabled in Cisco 2006/410x/440x Series Controllers which permits properly equipped wireless clients to roam without full re−authentication with an AAA server. In order to understand PKC, you first need to understand Key Caching. Key Caching is a feature that was added to WPA2. This allows a mobile station to cache the master keys (Pairwise Master Key [PMK]) it gains through a successful authentication with an access point, and re−use it in a future association with the same access point. This means that a given mobile device needs to authenticate once with a specific access point, and cache the key for future use. Key Caching is handled via a mechanism known as the PMKID (or the PMK Identifier), which is a hash of the PMK (Pair−Wise Master Key), a string, the station and the MAC addresses of the access point. The PMKID uniquely identifies the PMK. Even with Key Caching, a wireless station must authenticate with each access point it wishes to get service from once. This introduces significant latency and overheads, which delays the hand−off process and can inhibit the ability to support real−time applications. In order to resolve this issue, PKC was introduced with WPA2. PKC allows a station to re−use a PMK it had previously gained through a successful authentication process, eliminating the need for the station to authenticate against new access points when roaming.

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Hence, in an intra−controller roaming, when a mobile device moves from one access point to another access point on the same controller, the client re−computes a PMKID using the previously used PMK and presents it during the association process. The WLC searches its PMK cache to determine if it has such an entry. If it does, it by−passes the 802.1X authentication process and immediately initiates the WPA2 key exchange. If it does not, it goes through the standard 802.1X authentication process. PKC is enabled by default with WPA2. So, when you enable WPA2 as Layer 2 security under the WLAN configuration of the WLC, PKC is enabled on the WLC. Also, configure the AAA server and the wireless client for appropriate EAP authentication. The supplicant used at the client side should also support WPA−2 in order for PKC to work. PKC can also be implemented in an inter−controller roaming environment.

Q. Is roaming dependent on the Lightweight Access Point Protocol (LWAPP) mode that the WLC is configured to use? Can a WLC that operates in Layer 2 LWAPP mode do Layer 3 roaming?
A. As long as mobility grouping at the controllers is configured correctly, client roaming should work fine. Roaming is unaffected by the LWAPP mode (either Layer 2 or Layer 3). But it is recommended to use Layer 3 LWAPP wherever possible.

Q. No traps are generated by the WLC for Ad−Hoc rogues and SNMP debugs on the WLC do not show any traps from the WLC for Ad−Hoc even though the WLC GUI reported the Ad−Hoc rogues. The WLC runs firmware version 3.2.116.21. Why does this happen?
A. This is due to Cisco bug ID CSCse14889 ( registered customers only) . The WLC consistently sends traps for detected rogue access points (APs) but not for detected Ad−Hoc rogues. This bug is fixed in WLC firmware versions 3.2.171.5 and later.

Q. When you have a wireless user that attempts to authenticate via web authentication on a service set identifier (SSID) and the WLC sends the authentication request to an Access Control Server (ACS) (RADIUS), then which IP address on the WLC is used as the source address for the network access server (NAS) from the perspective of the RADIUS server in this scenario?
A. Use the management IP address interface of the WLC for the NAS IP address.

Q. We have an enterprise Cisco Airespace WLAN infrastructure. We have specific problems wherein WLAN clients are unable to browse a Microsoft Active Directory (AD) domain. This is only an issue within one of our buildings. Other buildings do not have the problem. We do not use any access control list (ACL) internally. Also, when a failed client is hard−wired, they can immediately browse the Microsoft AD domain. What could be the problem?
Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

A. One of the reasons can be that multicast mode is disabled on the controller. Enable multicast mode on the controller and check if you are able to access the Microsoft AD domain.

Q. What ports do I need to permit for Lightweight Access Point Protocol (LWAPP) communication when there is a firewall in the network?
A. You must enable these ports: ♦ Enable these UDP ports for LWAPP traffic: ◊ Data − 12222 ◊ Control − 12223 ♦ Enable these UDP ports for Mobility traffic: ◊ 16666 − 16666 ◊ 16667 − 16667 ♦ TCP 161 and 162 for SNMP (for the Wireless Control System [WCS]) These ports are optional (depending on your requirements): ♦ UDP 69 for TFTP ♦ TCP 80 and/or 443 for HTTP or HTTPS for GUI access ♦ TCP 23 and/or 22 for Telnet or secure shell (SSH) for CLI access

Q. I see the "[SECURITY] apf_foreignap.c 763: STA [00:0A:E4:36:1F:9B] Received a packet on port 1 but no Foreign AP configured for this port." error in one of my controllers. What does this error mean and what steps should I take to resolve it?
A. This message is seen when the controller receives a DHCP request for a MAC address for which it does not have a state machine. This is often seen from a bridge or a system that runs a virtual machine like VMWare. The controller listens to DHCP requests because it performs DHCP snooping so it knows which addresses are associated with clients that are attached to its access points (APs). All traffic for the wireless clients pass through the controller. When the destination of a packet is a wireless client, it goes to the controller and then passes through the Lightweight Access Point Protocol (LWAPP) tunnel to the AP and off to the client. One thing that can be done to help mitigate this message is to only allow the VLANs that are used on the controller onto the trunk that goes to the controller with the switchport vlan allow command on the switch.

Q. How do I retrieve Cisco Wireless LAN Controller (WLC) MIBs on the web?
A. You can download the Cisco WLC MIBs from the Wireless Downloads ( registered customers only) page. Complete these steps in order to download the WLC MIBs. 1. From the Wireless Downloads page, click on Wireless LAN Controller and select the controller platform for which you need the MIBs. 2. The Software Download page for the controller appears. This page contains all the files for the WLC including the MIBs. Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

3. Download the standard MIBs and the Cisco specific MIBs. These two files should be downloaded and contain the MIBs. The filenames look similar to this example:
Standard−MIBS−Cisco−WLC4400−2000−XXXXXX.zip Cisco−WLC−MIBS−XXXX.zip

Q. I see a lot of "CPU Receive Multicast Queue is full on Controller" messages on the 2006 WLC but not on the 4400 WLCs. Why? I have disabled multicast on the controllers. What is the difference in the Multicast Queue Limit between the 2006 and 4400 WLC platforms?
A. Since multicast is disabled on the controllers, the messages that cause this alarm could be ARP messages. There is no difference in queue depth (512 packets) between the 2000 WLCs and the 4400 WLCs. The difference is that the 4400 NPU filters ARP packets whereas everything is done in software on the 2006. This explains why the 2006 WLC sees the messages but not the 4400 WLC. A 44xx WLC processes multicast packets via hardware (through CPU). A 2000 WLC processes multicast packets via software. CPU processing is more efficient than software, so the 4400's queue gets cleared faster whereas the 2006 WLC struggles a bit when it sees a lot of these messages.

Q. Can a Cisco 2006 WLC be configured as an anchor for a WLAN?
A. A Cisco 2000 Series WLC cannot be designated as an anchor for a WLAN. However, a WLAN created on a Cisco 2000 Series WLC can have a Cisco 4100 Series WLC and Cisco 4400 Series WLC as its anchor.

Q. Does Layer 3 mobility work with an access point (AP) Group VLAN configuration?
A. Yes, Layer 3 mobility works with an AP Group VLAN configuration. Currently, traffic sources from a Layer 3 roamed wireless client is put on the dynamic interface assigned on the WLAN or the interface of the AP Group VLAN. This is how WLCs handle Layer 3 roaming: 1. When a wireless client roams to a new WLC (for example, WLC1), WLC1 sends mobility packets to all WLCs in the same mobility group. 2. The old WLC (for example, WLC2) sends a mobility packet to WLC1 and lets WLC1 know the IP address of the wireless client. 3. From then, WLC1 puts traffic from the wireless client to the local interface on WLC1. It is not the same interface on WLC2. 4. Any traffic to the wireless client is sent to WLC2. WLC2 forwards the packet using Ethernet over IP (EoIP) to WLC1, which in turn sends the traffic to the wireless client via a Lightweight Access Point Protocol (LWAPP) tunnel.

NetPro Discussion Forums − Featured Conversations
Networking Professionals Connection is a forum for networking professionals to share questions, suggestions, and information about networking solutions, products, and technologies. The featured links are some of the Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

most recent conversations available in this technology. NetPro Discussion Forums − Featured Conversations for Wireless Wireless − Mobility: WLAN Radio Standards Wireless − Mobility: Security and Network Management Wireless − Mobility: Getting Started with Wireless Wireless − Mobility: General

Related Information
• Cisco Wireless LAN Controller Module Q&A • Cisco Wireless LAN Controllers Q&A • Cisco Wireless LAN Controller Configuration Guide, Release 3.2 • Wireless Support Page • Technical Support & Documentation − Cisco Systems

All contents are Copyright © 1992−2006 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.

Updated: Dec 13, 2006

Document ID: 69561

Cisco − Wireless LAN Controller (WLC) Troubleshoot FAQ

Sign up to vote on this title
UsefulNot useful