Информационное Руководство для Cisco Cisco 2000 Series Wireless LAN Controller
bug is fixed in WLC firmware versions 3.2.171.5 and later.
Q. We have an enterprise Cisco Airespace WLAN infrastructure. WLAN
clients are unable to browse a Microsoft Active Directory (AD) domain.
This issue is seen 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?
clients are unable to browse a Microsoft Active Directory (AD) domain.
This issue is seen 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?
A. One of the reasons can be that multicast mode is disabled on the WLC. Enable multicast
mode on the WLC and check if you are able to access the Microsoft AD domain.
mode on the WLC and check if you are able to access the Microsoft AD domain.
Q. Does Layer 3 mobility work with an access point (AP) Group VLAN
configuration?
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..
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..
Q. Why are our access points (APs) that are registered to other WLCs
that are in the same RF group shown as rogues?
that are in the same RF group shown as rogues?
A. This can be due to Cisco bug ID CSCse87066 (
registered customers only
) . LWAPP APs in the
same RF group are seen as rogue APs by another WLC for one of these reasons:
The AP sees more than 24 neighbors. The neighbor list size is 24, so the 25th AP is
reported as a rogue.
reported as a rogue.
♦
AP1 can hear the client that communicates to AP2, but AP2 cannot be heard.
Therefore, it cannot be validated as a neighbor.
Therefore, it cannot be validated as a neighbor.
♦
The workaround is to manually set the APs to known internal on the WLC and/or WCS.
Complete these steps on the WLC in order to manually set the APs to known internal:
Complete these steps on the WLC in order to manually set the APs to known internal:
Go to the WLC GUI and choose Wireless.
1.
Click Rogue Aps in the left side menu.
2.
From the Rogue−AP list, choose the specific access point and clickEdit.
3.
From the Update Status menu, choose Known internal.
4.
Click Apply. This bug is fixed in version 4.0.179.11.
5.
Q. I have a 1200 Lightweight Access Point (LAP) to be registered with my
wireless LAN controller (WLC). I have configured my DHCP server with
option 43. How can I verify whether DHCP option 43 is functioning
properly?
wireless LAN controller (WLC). I have configured my DHCP server with
option 43. How can I verify whether DHCP option 43 is functioning
properly?
A. With DHCP option 43, the DHCP server provides the IP address of the WLCs along with
the IP address provided through DHCP. This can be verified from the LAP if the AP is a
Cisco IOS based Lightweight Access Point Protocol (LWAPP) AP, such as the 1242 or
1131AG LAP. In these cases, issue the debug dhcp detail command on the AP side in order
to see if the AP successfully receives the option 43 information and what it receives.
the IP address provided through DHCP. This can be verified from the LAP if the AP is a
Cisco IOS based Lightweight Access Point Protocol (LWAPP) AP, such as the 1242 or
1131AG LAP. In these cases, issue the debug dhcp detail command on the AP side in order
to see if the AP successfully receives the option 43 information and what it receives.