Filter
Top Products
1-52
FAQ and Troubleshooting Guide for the CiscoWorks Wireless LAN Solution Engine
OL-8376-01
Chapter 1 FAQs and Troubleshooting
Intrusion Detection System FAQs and Troubleshooting
Q.
I understand that WLSE does not accept SNMP traps that indicate an AP detected a rogue. So why
is an AP that is currently designated as the WDS generating rogue AP SNMP traps?
A.
The AP is generating the detected rogue trap, not the WDS functionality currently operating within
the AP. This trap is based on authentication tattletale rogue detection, which is currently not reported
to the WLSE.
WLSE uses radio measurements to detect the rogues. The authentication tattletale method uses a
message sent from a participating client that indicates some type of authentication issue with some
other AP. This other AP is considered to be rogue for one of these reasons:
–
The rogue was not running 802.1x.
–
Authentication with the rogue timed out.
–
Bad user password.
–
Authentication challenge failed.
This tattletale method is enabled on the AP itself, detected by the AP, and flagged at the AP via the
trap.
Q.
I configured the Friendly AP-to-Rogue AP no-observation period as 5 minutes, moved a rogue AP
(AP1) to the friendly list, and shut down its radio. After 5 minutes, AP1 was moved to the rogue AP
list. When I moved AP1 back to the friendly list, it was immediately (with in 40 seconds) moved
back to the rogue AP list.
A.
When the Friendly-to-Rogue policy evaluates a site, any device that hasn’t been seen in “too long a
time” is reclassified as rogue. This time period starts when WLSE last observed the device, not after
the administrator has set it to Friendly. To keep an unmanaged device as Friendly, set the maximum
unobserved time to a value larger than the amount of time the device is expected to not be observed.
For example, if a friendly AP is turned off after business hours, the maximum unobserved time
should be at least 14 hours (or more for weekends) or the WLSE will reclassify it as rogue.
Q.
What should I do when my system is overrun with rogue APs?
A.
Some networks might experience large numbers of rogues due to the nature of their neighboring
networks or a one-time storm. When the number of unknown (rogue infra-structure or ad-hoc) radios
is high (greater than 5000), your network might experience performance degradation. This can occur
when your network is in a crowded airspace, you have products such as printers that have wireless
functions that create and/or rotate ad-hoc network IDs, that are attacked by the FakeAP program, or
that have APs sending corrupt beacon reports. To handle large numbers of rogues:
–
Use IDS > Manage Network Wide Settings to disable all rogue detection and processing from
either infrastructure or ad-hoc rogues (or both).
–
If your network is in a crowded airspace, examine the report IDS > Manage Rogues. This report
shows you the RSSI value for the detected rogues. Sorting by RSSI might give you a limit of
RSSI values that you could use in IDS > Manage Network Wide Settings as a threshold.
–
Use IDS > Manage Rogues to delete the rogues that are no longer an issue (for example, from
a temporary storm or isolated occurrence) to free up space in the WLSE.
–
For an explanation of the fault, see IDS (Intrusion Detection System) Faults, page 2-14.
Q.
Why is a fault generated regardless of the threshold set for detecting rogue APs with an defined RSSI
value under IDS > Manage Network-Wide IDS Settings?
For example, the threshold is set for detecting a rouge AP with an RSSI value of greater than
-80dBM, but alerts are being generated for a rogue AP with an RSSI value of -200 dBm.
A.
What happens is as follows: