Cisco Cisco Aironet 1310 Access Point Bridge Information Guide
Q. How can I disable the reset button on the APs after conversion from
autonomous to lightweight mode?
autonomous to lightweight mode?
A. You can disable the reset button on APs that you have converted to lightweight mode. The
reset button is labeled "MODE" on the outside of the AP. Use this command in order to
disable or enable the reset button on one or all converted APs that are associated to a
controller:
reset button is labeled "MODE" on the outside of the AP. Use this command in order to
disable or enable the reset button on one or all converted APs that are associated to a
controller:
config ap reset−button {enable | disable} {ap−name | all}
The reset button on converted APs is enabled by default.
Q. Can I have a Lightweight AP Protocol (LWAPP)−capable AP
connected across a WAN link from the wireless LAN controller (WLC)? If
so, how does this work?
connected across a WAN link from the wireless LAN controller (WLC)? If
so, how does this work?
A. Yes, some LAPs support the feature called Remote−Edge AP (REAP). With this feature,
you can have a LAP across a WAN link from the WLC to which the LAP connects. REAP
mode enables a LAP to reside across a WAN link and still be able to communicate with the
WLC and provide the functionality of a regular LAP. Refer to Remote−Edge AP (REAP)
with Lightweight APs and Wireless LAN Controllers (WLCs) Configuration Example for a
detailed example of this setup.
you can have a LAP across a WAN link from the WLC to which the LAP connects. REAP
mode enables a LAP to reside across a WAN link and still be able to communicate with the
WLC and provide the functionality of a regular LAP. Refer to Remote−Edge AP (REAP)
with Lightweight APs and Wireless LAN Controllers (WLCs) Configuration Example for a
detailed example of this setup.
Note: REAP mode is supported only on the Cisco Aironet 1030 LAPs at this point. The
REAP functionality will be included on a broader range of LAPs in the future.
REAP functionality will be included on a broader range of LAPs in the future.
Q. Do we still have the same WAN restraints on monitor mode APs as we
do with regular APs and H−REAP APs? That is, do we require a 100ms or
better RTD between the controller and a monitor mode AP?
do with regular APs and H−REAP APs? That is, do we require a 100ms or
better RTD between the controller and a monitor mode AP?
A. No, monitor mode AP does not have the 100 ms restriction because there is no client
association, which is the reason for the restriction. The 100 ms latency limitation was created
out of varied, and often stringent, client authorization requirements, which is why both local
mode and H−REAP APs have identical latency limitations. Obviously, monitor mode APs do
not have the same client limitations.
association, which is the reason for the restriction. The 100 ms latency limitation was created
out of varied, and often stringent, client authorization requirements, which is why both local
mode and H−REAP APs have identical latency limitations. Obviously, monitor mode APs do
not have the same client limitations.
Q. My WLC version is 3.2. It is configured for Layer 3 Lightweight Access
Point Protocol (LWAPP). The MTU for the network between this WLC and
my lightweight access point (LAP) is configured as 900 bytes. My
LWAPP AP is unable to join this WLC. What can be the reason for this?
Point Protocol (LWAPP). The MTU for the network between this WLC and
my lightweight access point (LAP) is configured as 900 bytes. My
LWAPP AP is unable to join this WLC. What can be the reason for this?
A. The MTU configured in your scenario is 900 bytes. But an LWAPP Join request is larger
than 1500 bytes. So, here LWAPP requires a fragment of the LWAPP Join request. The logic
for all LWAPP APs is that the size of the first fragment is 1500 bytes (includes IP and UDP
header) and the second fragment is 54 bytes (includes IP and UDP header). If the network
between LWAPP APs and the WLC has an MTU size less than 1500 (such as VPN, GRE,
MPLS, and so forth) as in your case, WLC cannot handle the LWAPP Join request.
Therefore, the LWAPP is not able to join the controller.
than 1500 bytes. So, here LWAPP requires a fragment of the LWAPP Join request. The logic
for all LWAPP APs is that the size of the first fragment is 1500 bytes (includes IP and UDP
header) and the second fragment is 54 bytes (includes IP and UDP header). If the network
between LWAPP APs and the WLC has an MTU size less than 1500 (such as VPN, GRE,
MPLS, and so forth) as in your case, WLC cannot handle the LWAPP Join request.
Therefore, the LWAPP is not able to join the controller.
Upgrade your controller to version 4.0 in order to handle this situation. This version is able to
handle Layer 3 fragments. Refer to Cisco bug ID CSCsd94967 (
handle Layer 3 fragments. Refer to Cisco bug ID CSCsd94967 (
registered customers only
) for