Примечания к выпуску для Cisco Cisco 2106 Wireless LAN Controller
11
Release Notes for Cisco Wireless LAN Controllers and Lightweight Access Points for Release 4.2.209.0
OL-31336-01
Important Notes
Important Notes
This section describes important information about the controllers and access points.
ARP Requests Sometimes Fail for Access Points Connected Directly to
2006 and 2100 Series Controllers
2006 and 2100 Series Controllers
Cisco 2006 and 2100 series controllers do not support ARP requests from access points connected
directly to a port on the controller unless there is an interface configured on that controller port. ARP
requests from the access point cannot reach the gateway on the interface VLAN and the access point
might lose its connection to the controller.
directly to a port on the controller unless there is an interface configured on that controller port. ARP
requests from the access point cannot reach the gateway on the interface VLAN and the access point
might lose its connection to the controller.
To work around this limitation, configure the access point’s default gateway to match the controller’s
management IP address, or connect the access point to a switch port between the access point and the
controller.
management IP address, or connect the access point to a switch port between the access point and the
controller.
One-Time Password (OTP) Support
One Time Passwords (OTP) are supported on the Wireless Lan Controller (WLC) using TACACS and
RADIUS. In this configuration, the controller acts as a transparent pass-thru device. The controller
forwards all client requests to the TACACS/RADIUS server without inspecting the client behavior.
When using OTP the client must only establish a single connection to the controller to function properly.
The controller currently does not have any intelligence or checks to correct a client that is trying to
establish multiple connections.
RADIUS. In this configuration, the controller acts as a transparent pass-thru device. The controller
forwards all client requests to the TACACS/RADIUS server without inspecting the client behavior.
When using OTP the client must only establish a single connection to the controller to function properly.
The controller currently does not have any intelligence or checks to correct a client that is trying to
establish multiple connections.
QoS Interaction with RRM
Controller software release 4.2.205.0 or later affects the way that QoS interacts with the RRM scan defer
feature:
feature:
•
When you configure a WLAN with a Bronze (Background Priority) QoS policy level, traffic with
Scan Defer Priority 0 (UP=0) should be downgraded to UP=1 (UP 1,2 are the lowest priority; 0,3
are the next higher priority). Traffic to and from clients on this WLAN will compete with clients
sending UP=0 traffic in Silver/Gold/Platinum policies.
Scan Defer Priority 0 (UP=0) should be downgraded to UP=1 (UP 1,2 are the lowest priority; 0,3
are the next higher priority). Traffic to and from clients on this WLAN will compete with clients
sending UP=0 traffic in Silver/Gold/Platinum policies.
•
The QoS policy for the WLAN configuration overrides the traffic sent. In other words, if you have
patient monitors, phones, or other client devices in a WLAN with a Silver QoS policy, the traffic is
downgraded to a priority no higher than UP=3. If you attempt to defer off-channel scanning by
configuring the WLAN for UP=5,
patient monitors, phones, or other client devices in a WLAN with a Silver QoS policy, the traffic is
downgraded to a priority no higher than UP=3. If you attempt to defer off-channel scanning by
configuring the WLAN for UP=5,
the QoS policy overrides that configuration and off-channel
scanning is not deferred.
•
Traffic sent with UP=7 on a WLAN with a Platinum policy will be downgraded to UP=6; if you
configure off-channel scanning for UP=7 only, scanning will not be deferred. You might not want
to defer scanning for UP=7 traffic but you might for UP=6 traffic; in this case, the traffic sent with
UP=7 will be downgraded and cause a deferral. Similarly, if you want to defer scanning for UP=7
traffic, you must set the scanning priority to
configure off-channel scanning for UP=7 only, scanning will not be deferred. You might not want
to defer scanning for UP=7 traffic but you might for UP=6 traffic; in this case, the traffic sent with
UP=7 will be downgraded and cause a deferral. Similarly, if you want to defer scanning for UP=7
traffic, you must set the scanning priority to
UP=6 because the traffic will be downgraded.
If you completely disable off-channel scanning on your network, you should consider alternative ways
to implement off-channel scanning: adding monitor-mode access points or creating AP groups where
some access points in the area do not carry the configured WLANs for those devices.
to implement off-channel scanning: adding monitor-mode access points or creating AP groups where
some access points in the area do not carry the configured WLANs for those devices.