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