Tools for Troubleshooting Access Point

Issues
Cisco IOS XE running on Cisco Catalyst 9800 WLCs is essentially
composed of a Linux Kernel, with Cisco IOS and all the wireless processes
implemented as daemons. All the process daemons can be bundled under
the generic term "control plane." They are responsible for the following,
which are destined to and from the Cisco Catalyst 9800 Series WLC:
• CAPWAP
• Mobility
• Radio Resource Management (RRM)
• Rogue management
• Network Mobility Service Protocol (NMSP)

The data plane refers to the data-forwarding components on the Cisco

Catalyst 9800 Series WLC. During troubleshooting, you may be interested
in retrieving information from the control plane and data plane.

The Cisco tools enable you to gather information from the equipment
directly in your wireless environment while facilitating some of the most
common tasks you would take during troubleshooting. Thus, these tools
can be used for different purposes, such as troubleshooting AP issues,
client connectivity issues, mobility, and so on.

The Cisco wireless troubleshooting tools can be grouped into the following
categories:

• Cisco WLC built-in tools: An integrated part of the Cisco WLC,

such as within Cisco Catalyst 9800 Series Wireless Controller
troubleshooting and monitoring pages in the GUI or similar CLI
commands.
• Cisco standalone tools: Cisco products or Cisco widely available
tools for wireless network troubleshooting and RF spectrum
analysis.

You can use the Cisco WLC built-in tools to see the APs' status and
detect APs that have join issues. Furthermore, you can observe the syslog
and benefit from the trace-on-failure, always-on tracing, and radioactive
tracing features to easily find the failure reason while narrowing your
investigation to specific log events related to the APs that are experiencing
issues. Suppose you still cannot resolve the issue. In that case, you can
leverage the packet-capturing facility in the controller and perform a
deeper analysis of the packets destined to, sourced from, and passing
through the Cisco 9800 WLCs.

When you are faced with an AP issue in your environment, you can also
speed up the troubleshooting process if you are familiar with how to use
the Cisco standalone tools. Besides different Cisco tools that can be used
for monitoring of the wireless environment, as well as to analyze
information from the wireless devices or perform RF spectrum analysis,
some of them can be beneficial from AP issues troubleshooting as well.
For example, you can use Cisco available tools to perform common tasks
such as analyzing the Cisco WLC configuration, inspecting WLC debug
logs in a structural manner, and so on.

Cisco WLC Built-In Tools

Cisco WLC built-in tools enable you to gather information about the status
of your wireless network and collect valuable inputs that can help you
troubleshoot different issues. The administrative interface of Cisco WLC is
an important tool when assessing the overall health and specific issues on
your wireless network. You can verify your WLAN configuration settings
through either the web-based GUI interface or the use
of show and debug commands over the CLI.

The Dashboard page in the GUI represents a single pane view that you
may want to look at daily and when troubleshooting issues since it
provides an overview of the wireless network status. The following figure
depicts the information provided by the dashboard.

Thus, you can compare your baseline state with the current state of your
network while observing the WLANs and APs (how many of them are up
and down), active and excluded clients, rogue APs and clients, and so on.

The Cisco Catalyst 9800 Series Wireless Controller has specific built-in
troubleshooting features that help you quickly identify root causes for
wireless issues in your network with less time and effort. In the GUI, you
can navigate to the Troubleshooting menu to access different tools for
control plane and data plane tracing.
These troubleshooting tools enable you to perform a root cause analysis
while following a systematic approach. For example, during a typical client
connectivity issue, while knowing when the issue was reported, you can
inspect details about failed events in the system, including events that
have occurred in the past, even without having any debugs enabled. If this
action does not help, you can perform an in-depth analysis by
conditionally increasing the level of logging per different processes,
performing packet capture, and so on.

Syslog
You can use the logs generated by the Cisco 9800 Series Wireless
Controller as the first means to verify the general health of the system. Any
violations of the predefined threshold for system resources like CPU,
memory, and buffers are reported into the log. In addition, any errors
generated by any subsystems get written in the logs. You will be able to
view the syslog server messages from the APs as well after they join the
controller. Thus, the syslog can be useful for troubleshooting AP join
issues. To view the logs, navigate to Troubleshooting > Syslog.

The syslog server on the APs and WLC has many levels and facilities.
While the level defines the severity, the facility enables you to specify
where you can put the syslog messages, for example, the syslog itself.

The following lists the syslog levels:

• Emergencies: signifies severity 0. Implies that the system is not

usable.
• Alerts: signifies severity 1. Implies that immediate action is required.
• Critical: signifies severity 2. Implies critical conditions.
• Errors: signifies severity 3. Implies error conditions.
• Warnings: signifies severity 4. Implies warning conditions.
• Notifications: signifies severity 5. Implies normal but significant
conditions.
• Informational: signifies severity 6. Implies informational messages.
• Debugging: signifies severity 7. Implies debugging messages.

Different options are available for the syslog facility,

including auth (authorization system), cron (cron facility), daemon (system
daemons), kern (kernel), local0 to local7 (local use), syslog (syslog itself),
and so on.
You can configure the APs and WLC to redirect the logs to an external
syslog server, where they can be correlated with other events in the
system.

You can leverage a syslog server for an AP logs, which is applied through
an AP join profile once the AP is associated with the WLC, using the
following commands:

WLC-9800(config)# ap profile ap-profile-name

WLC-9800(config-ap-profile)# syslog facility
WLC-9800(config-ap-profile)# syslog host 10.10.10.100
WLC-9800(config-ap-profile)# syslog level critical

You can configure the syslog server for the WLC using the following
commands:

WLC-9800(config)# logging host 10.10.10.100

WLC-9800(config)# logging facility syslog
WLC-9800(config)# logging trap 2

Trace-on-Failure
The Cisco 9800 Series Wireless Controller can keep track of predefined
failure conditions. There is nothing required for this feature to work. It is
continuously working in the background without the need for any debug
command. Hence, you can view the different failure conditions detected
and the number of events, with details about failed events. This feature
enables you to be proactive and detect issues that could be occurring in
your network, even without clients reporting them.

The following example shows the output that you can get for failure
conditions detected in the last two hours and details about the events:

WLC-9800# show logging profile wireless start last 2

days trace-on-failure

Logging display requested on 2022/11/10 21:35:06 (UTC)

for Hostname: [C9800], Model: [C9800-CL-K9], Version:
[17.06.03], SN: [974AXGWX367], MD_SN: [974AXGWX367]
Displaying logs from the last 2 days, 0 hours, 0
minutes, 0 seconds
executing cmd on chassis 1 ...
Large message of size [32273]. Tracelog will be
suppressed.

Large message of size [32258]. Tracelog will be

suppressed.

Time UUID Log

-------------------------------------------------------
------------
2022/11/10 06:32:45.763075 0x1000000e37c92
f018.985d.3d67 CLIENT_STAGE_TIMEOUT State =
WEBAUTH_REQUIRED, WLAN profile = CWA-TEST2, Policy
profile = flex_vlan4_cwa, AP name = ap3800i-r3-sw2-Gi1-
0-35

Always-on-Tracing
If there is no event for a client-reported issue in the predefined failure
conditions, you can use the Always-on-Tracing feature to perform further
analysis. It enables you to check events that have occurred in the past,
even without having any debugs enabled. With this feature, every control
plane process on the Cisco 9800 WLC is constantly logging at the logging
level of Notice to its dedicated buffer. It allows you to get contextual data
when troubleshooting a specific issue that has occurred without
mandating that the failure condition is reproduced. For example, you can
retrieve the context and actions that caused a client or AP disconnections
to check client roaming patterns or the SSIDs where the client had
connected. Furthermore, it can help you establish trends and isolate
causes if the reported client connectivity problem is specific to certain APs
or client MAC addresses.

You can enable higher logging levels if required, per process or for a group
of processes. Still, higher levels will generate more events and reduce the
total overall time that can be logged for that process. Logs can be viewed
in the console, as in the next example, exported in a file, and so on.

WLC-9800# show logging profile wireless

Radioactive Trace
Suppose you cannot identify the root cause for a specific issue using the
available logs, and you need more in-depth information on all processes
and actions. In that case, you can use the Radioactive Trace feature. This
feature enables higher logging levels for specific features for the
conditions of interest. Thus, there is no need to manually increase the
logging level per process since it will increase the level of logging per
different processes based on a specific condition (such as a concrete set
of specified MAC or IP addresses traversing the system). It will restore the
logging level once the specified condition is finished. You can add more
conditions if needed.

So, when you are facing multiple issues, such as client-related problems,
APs, and mobility, you do not need to use a list of different debug
commands for each scenario since you only need to specify the desired
condition. Then, you must reproduce the problem, generate logs, and
inspect them to resolve it. The following figure illustrates the Radioactive
Trace feature with the Troubleshooting menu in the GUI:

Before you can start the trace, you must specify the required time interval.
It defines how long back you want your collated log file to go and should
cover the period you need for the analysis. Note that MAC address vs IP
address as a condition provides different outputs as different processes
are aware of different identifiers for the same network entity (AP or client
or mobility peer).

You can perform radioactive tracing in the Cisco WLC CLI as well, using
conditional debugging. Similarly, you can focus on specific MAC or IP
address traversing the system. For example, when you troubleshoot the
AP connectivity, you can leverage conditional debugging, which can use
the AP MAC address to get an end-to-end view of the control plane. To
enable conditional debugging via CLI, use this command:

WLC-9800# debug wireless {mac | ip} {aaaa.bbbb.cccc |

x.x.x.x } {monitor-time} {N seconds}

To view the currently enabled conditions, use

the # show debugging command.
These debug will print no output on the terminal session. The debug
output file is stored to flash for later retrieval and analysis. The file is saved
with the naming convention ra_trace_*.

For example, for MAC address aaaa.bbbb.cccc, the filename that

generates is the
following: ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_Da
yWeek_Month_Day_year.log.

One advantage is that the same command can be used to troubleshoot

different problems by entering different MAC or IP address values. For
example, you can examine access point join issues by using the AP radio
MAC and Ethernet MAC, and you can examine client connectivity issues
by using the client MAC. In addition, you can examine mobility tunnel
issues by using the WLC peer IP address and examine client roaming
issues by using the client MAC address.

In other words, you do not have to remember multiple commands, such

as debug capwap, debug client, debug mobility, and others.

Note
The debug wireless command also allows you to point to an FTP-server and
run even more verbose logging with the keyword internal. However, it is
not recommended to use these commands currently because some issues
are being ironed out.

To debug the output file on a terminal session, run this command:

WLC-9800# more bootflash:ra_trace_MAC_*.log

To redirect the debug output to an external server for offline analysis, use
this command:

WLC-9800# copy bootflash:ra_trace_MAC_*.log

ftp://username:password@FTPSERVERIP/path/RATRACE_FILENA
ME.txt

To see a much more verbose view of the same debug log levels, use this
command:

WLC-9800# show logging profile wireless internal filter

mac <aaaa.bbbb.cccc> to-file
<RATRACE_INTERNAL_FILENAME.txt>
To disable debugging for a specific context or before the configured or
default monitor time is up, use this command:

WLC-9800# no debug wireless mac <aaaa.bbbb.cccc>

Caution: Conditional debugging enables debug-level logging, which in

turn increases the volume of logs that generate. Leaving this feature
running reduces how far back in time you can view logs. So, it is
recommended always to disable debugging in the CLI at the end of the
troubleshooting session.

To disable all debugging, use these commands:

WLC-9800# clear platform condition all

WLC-9800# undebug all

Embedded Packet Capture

Embedded Packet Capture (EPC) is a packet capturing facility that allows
a view into packets destined to, sourced from, and passing through the
Cisco 9800 WLCs. Thus, you do not need to use an external switch
capture if you are familiar with packet capture analysis. The EPC allows
you to capture packets in the data plane or control plane. When initiating a
packet capture action from the controller, you can filter by client MAC
address, ACL, interface, or type of traffic. The enable EPC in the GUI,
navigate to Troubleshooting > Packet Capture > +Add, as depicted in
the following figure:

Although EPC can be collected easily from the GUI and is sufficient to
capture packets for common use cases, CLI provides more granular
settings for EPC configuration. For example, it can be configured to match
the inner MAC address, which allows you to focus on traffic related to
specific client events when CAPWAP is encapsulated.

The Cisco 9800 Series Wireless Controller also supports the data-path
packet trace feature as part of the Cisco IOS XE platform, which provides
a data plane view of specified traffic. More precisely, it provides a detailed
view of this Cisco IOS XE processing done at the data plane and the
decision made on whether to punt, forward, drop, or consume the packet.
With this feature, you can collect a finite number of packets and include
the conditional debugging ID that can be used to correlate data plane
packet to control plane debugs, timestamp, and feature-specific path-
trace data. Thus, it is not a packet capture feature like EPC. In addition, for
wireless traffic, the data plane packets tracing only parses the outer
CAPWAP header, so conditions like wireless client MAC address do not
yield useful output.

Cisco Standalone Tools

During wireless troubleshooting, you can use the Cisco widely available
tools or Cisco products to analyze information from the wireless devices or
perform RF spectrum analysis. For example, if you need to analyze the RF
spectrum, you may not know what is in your network environment that
may impact wireless network performance and connectivity. Also, using
the Cisco available tools, you can perform common tasks such as
analyzing the Cisco WLC configuration, inspecting WLC debug logs in a
structural manner, and so on.

Wireless Config Analyzer Express

Cisco wireless engineers developed the Cisco Wireless Config Analyzer
Express (WCAE) to evaluate the Cisco WLC configuration for errors and
check against best practices. It supports Cisco 9800 and AireOS
controllers and can help you analyze and validate your wireless network.
Note
Cisco WCAE represents a next-generation evolution of the Cisco Wireless
LAN Controller Configuration Analyzer (WLCCA), with cleanup and
improved checks. It is recommended for the Cisco 9800 Series Wireless
Controller configuration analysis.

Cisco WCAE is available in two versions, Cloud, where you can upload
your file online, or as a mini-Desktop application. It is fully offline to the
controller. It does not store any data or send any data back. This figure
shows the mini-Desktop application with a report in an Excel file.

When using the Cisco WCAE, consider the following preparation

requirements:

1. If you have decided to use the mini-Desktop, download and install

the Cisco WLCE tool from the Cisco DevNet. Alternatively, you can
 access the cloud-based version
via https://cway.cisco.com/tools/WirelessAnalyzer.
2. Get the configuration from your Cisco 9800 WLC using show
tech or show tech wireless (disable paging by first entering terminal
length 0; it eliminates page breaks.)
3. Upload the file to the Cisco WLCE for analysis.
4. Process the file to generate a report.

When using the Cisco WCAE, consider the following operation and
features requirements:

• Audit checks on your configuration:

1. Configuration detail verifications that are based on Cisco TAC
and escalation case experience.
2. Covers best practices.
3. Can compare configurations between controllers.
• Controller configuration view:
1. Detailed information on interfaces, ports, AP groups, WLANs,
RF profiles, mobility peers, RADIUS servers, RF summary, and
redundancy configuration.
• AP configuration view:
1. APs, model, status, MACs, controller.
2. RF summary.
3. Cisco CleanAir persistent devices (interferers).
• RF analysis:
1. Nearby AP information (based on neighbor packet exchange).
• List of APs seen, name, MAC, channel, and power
2. RF summary-controller
• Channel distribution, power levels, client SNR, and
summary.
3. RF summary-APs
• Overlapping APs, neighbor count, and client count.

WLC Debug Analyzer

Inspecting a debug log can be a difficult task, especially when you are
troubleshooting a wireless issue that must be quickly resolved. You can
use the WLC Debug Analyzer to parse debug log files from your Cisco
Catalyst 9800 Series Wireless Controller, which makes it easier to
troubleshoot issues with wireless client association, authentication,
roaming, and connectivity issues. Once you have prepared a debug file,
you can upload it to this tool, which is available as a cloud-based
application via https://cway.cisco.com/wireless-debug-analyzer, and
parse its content. You can filter the MAC addresses and connections of
interest, as well as group the logs based on client MAC, and so on.

This tool enables you to perform logical analysis based on log sequence
matching against existing issues. With Cisco 9800 WLC, you can use this
tool to parse through always-on traces and radioactive trace logs. Hence,
you can use these WLC logs more effectively to resolve wireless issues in
your environment. In addition, you can download the parsed file as CSV,
for offline viewing and analysis.

Content Review Question

You need to perform a troubleshooting task of AP join issues while using
logs from your Cisco 9800 WLC. Which feature should you use to produce
detailed debugging logs, while specifying conditions of interest, so that
you can identify the root cause for the reported issue?
• Always-on-Tracing
• Radioactive Trace
• Embedded Packet Capture
• Use different show log commands.

Monitoring Wireless Network for Rogue

Devices
A rogue AP is an access point that has been installed on a network without explicit
authorization from the system administrator. Rogue APs can disrupt wireless LAN
operations, which can introduce security and operational issues in your environment. Since
rogue APs are inexpensive and readily available, employees in your company can plug
unauthorized rogue APs into existing LANs and build ad hoc wireless networks without their
IT department's knowledge or consent. This can be a serious security breach since they can
bypass the firewall zones and avoid usual security measures. Furthermore, the employees
typically do not configure any security settings on these rogue APs (default configurations
are easily detectable), so it is easy for unauthorized users to use the APs to intercept network
traffic and hijack client sessions. There is an increased chance of enterprise security breaches
when wireless users connect to APs in the enterprise network.

Rogue APs from external parties can also be used to disrupt operations by hijacking
legitimate clients' sessions and performing denial-of-service or man-in-the-middle attacks.
That is, a hacker can use a rogue AP to capture sensitive information, such as usernames and
passwords. The hacker can then transmit a series of Clear to Send (CTS) frames. This action
mimics an AP, informing a particular client to transmit and instructing all the other clients to
wait, which results in legitimate clients being unable to access network resources. Wireless
LAN service providers have a strong interest in banning rogue APs from the air space.

It is important for you to know how to monitor the wireless network for rogue devices,
classify rouge APs, and manage the rogue devices.

Rogue Devices Detection

The two access point RF detection deployment models are standard AP deployment and
monitor mode AP deployment. This figure illustrates an example where a rogue AP and
client are present in the network, as well as integration with Cisco Prime Infrastructure (PI)
for rouge AP detection and classification. In addition, you can also use the Cisco Digital
Network Architecture (DNA) Center rogue AP containment feature to contain the wireless
rogue AP in the controller-based network.

Both deployment models support RF detection and are not limited to rogue APs. They can
also capture information upon detection of ad hoc clients and rogue clients (the users of rogue
APs). In monitor mode, the AP is dedicated to scanning the RF channels but does not pass
client data.

A rogue device is an unknown AP or client that managed APs in your network detect as not
belonging to your system. When searching for rogue devices, an AP goes off channel for
50ms to listen for rogue APs, listen for rogue clients, and monitor for noise and channel
interference (the channels to be scanned are configured in the global WLAN network
parameters for IEEE 802.11a/n/ac and IEEE 802.11b/g/n). Information about detected rogue
clients or APs is sent to the Cisco WLC, which gathers the following information:

• Rogue access point MAC address

• Rogue access point name
• Rogue connected the client MAC address
• Whether the frames are protected
• The preamble
• Signal-to-noise ratio (SNR)
• Received Signal Strength Indicator (RSSI)

Cisco WLC then waits to label a rogue client or AP until another AP reports it or until it
completes another cycle.

When the same AP again moves to the same channel to monitor for rogue APs or clients,
noise, and interference and detects the same clients or APs, it lists them as rogues on Cisco
WLC.

Cisco WLC now begins to determine whether a rogue is attached to the local network or is
simply a neighboring AP. In either case, an AP that is not part of the managed local WLAN is
considered a rogue.
In monitor mode, the AP does not carry user traffic but spends all its time scanning channels.
This mode of deployment is most common when a customer does not want to support WLAN
services in a particular area but wants to monitor that area for rogue APs and rogue clients. It
enables you to detect a large number of rogue APs and clients with high sensitivity since it is
used only for monitoring.

Rogue AP Classification
The controller software enables you to create a rule-based classification of the rogue APs, as
the following type:
• Friendly: A rogue AP that matches the friendly access point rule. The rogue state can
be the following:
1. Internal: If the unknown AP poses no threat to WLAN security, you can
manually configure it as Friendly, Internal. An example of this would be the
APs in your lab network.
2. External: If the unknown AP is outside the network and poses no threat to
WLAN security, you can manually configure it as Friendly, External. An
example of this would be the AP in your neighboring coffee shop.
3. Alert: No action is taken other than notifying the management station. The
management station manages the controller and wired networks.
• Malicious: A rogue AP that matches the malicious access point rule. The rogue state
can be the following:
1. Alert: No action is taken other than notifying the management station. The
management station manages the controller and wired networks.
2. Threat: The unknown AP is found to be on the network and poses a threat to
WLAN security.
3. Contained: The unknown AP is contained. If none of the managed APs are
available for containment, the rogue is in a Contained Pending state.
• Custom: A rogue AP that matches the custom rule. The rogue state can
be Alert or Contained.
• Unclassified: A rogue AP that matches no classification rules. The rogue state can
be Alert or Contained.

By default, none of the classification rules are enabled. Therefore, all unknown APs are
categorized as unclassified. The unclassified APs are reclassified when you create a rule,
configure conditions for it, and enable the rule. Whenever you change a rule, it applies to all
APs (friendly, malicious, custom, and unclassified).

Note
You can configure up to 64 rogue classification rules per controller

When the Cisco WLC receives a rogue report from one of its managed APs, it responds as
follows:

• The Cisco WLC verifies whether the unknown AP is in the Friendly MAC address
list. If it is, the controller classifies the AP as Friendly.
• If the unknown AP is not in the Friendly MAC address list, the controller starts
applying rogue classification rules.
 • If the rogue AP is manually classified, rogue rules are not applied.
• If the rogue AP matches the configured rules criteria, the controller classifies the
rogue based on the classification type configured for that rule.
• If the rogue AP matches none of the configured rules, the Cisco WLC classifies the
rogue as unclassified.
• The Cisco WLC repeats the previous steps for all rogue APs.
• Suppose Rogue Location Discovery Protocol (RLDP) determines that the rogue AP is
on the same wired network. In that case, the Cisco WLC automatically marks the
rogue state as a Threat and classifies it as Malicious, even if you configured no rules.
You can then manually contain the rogue (unless you have configured RLDP to
contain the rogue automatically), which would change the rogue state to contained. If
the rogue AP is not on the network, the controller marks the rogue state as Alert, and
you can manually contain the rogue.
• If desired, you can manually move the AP to a different classification type and rogue
state.

Before performing any classification, the rogue APs are temporarily marked as Pending.

The following guidelines and restrictions apply to classifying rogue APs:

• Classifying Custom type rogues is tied to rogue rules. Therefore, it is not possible to
manually classify a rogue as Custom. Custom class change can occur only when you
use rogue rules.
• Some SNMP traps are sent for containment by rule and every 30 minutes for rogue
classification change.
• Rogue rules apply on every incoming new rogue report in the controller in the order
of their priority.
• After a rogue satisfies a higher priority rule and is classified, it does not move down
the priority list for the same report.
• The rogue classification rules are re-evaluated at every report received by the
managed APs. Hence, a rogue AP can move from one state to another, if a different
rule matches the last report.
• If a rogue AP is classified as friendly or ignored, all rogue clients associated with it
are not tracked.
• Until the controller discovers all the APs through neighbor reports from APs, the
rogue APs are kept unconfigured for 3 minutes after they are detected. After 3
minutes, the rogue policy is applied to the rogue APs, and the APs are moved to the
Unclassified, Friendly, Malicious, or Custom class. When rogue APs are kept
unconfigured, no rogue policy has yet been applied.
• When a rogue Basic Service Set Identifier (BSSID) is submitted for containment on
the Cisco 9800 WLC, if the controller has enough resources, it will contain. The APs
that detect the contained rogue AP start broadcasting DEAUTH packets, which will
result in the disconnection of the clients connected to that rogue BSSID. However, the
clients will likely repeatedly try to reconnect, and the wireless client's experience will
be badly affected.
Also, in a high RF environment like that of a stadium, though DEAUTH packets are
broadcast, the client does not necessarily receive all of them because of the competing
RF. In this scenario, the client may not be fully disconnected, but its performance can
be impacted badly.
Configuring Rogue Classification Rules
You can configure rogue classification rules in the WLC using the GUI or CLI. To configure
rogue classification rules in the Cisco 9800 WLC GUI navigate
to Configuration > Security > Wireless Protection Policies, and choose the Rogue AP
Rules tab, where you can create rules as indicated in this example.

When creating a rule in the CLI, you must enter the priority for the rule. Then you can
specify the classification that needs to be applied when a rogue AP matches the rule, as well
as apply a condition in the rule that a rogue AP must meet: You can define multiple
conditions and specify whether all or any conditions should be matched.

To create or edit an existing rule in the CLI, as well as specify the classification that needs to
be applied and add a condition in the rule itself, use the following commands.

wireless wps rogue rule rule-name priority priority

classify {friendly state {alert | external | internal} |
malicious state {alert | contained }}
condition {client-count value | duration duration_value |
encryption | infrastructure | rssi | ssid ssid_name |
wildcard-ssid}

When defining the conditions, the following options apply:

• Client Count: This condition requires that a minimum number of clients be

associated with the rogue AP. For example, if the number of clients associated with
the rogue AP is greater than or equal to the configured value, the AP could be
classified as malicious. If you choose this option, enter the minimum number of
clients to be associated with the rogue AP for the value parameter. The valid range is
1 to 10 (inclusive), and the default value is 0.
• Duration: This condition requires that the rogue AP is detected for a minimum
period. If you choose this option, enter a value for the minimum detection period for
the duration_value parameter. The valid range is 0 to 3600 seconds (inclusive), and
the default value is 0 seconds.
• Encryption: This condition requires that the rogue AP advertised WLAN does not
have encryption enabled.
• Received Signal Strength Indicator (RSSI): This condition requires the rogue AP to
be detected with a minimum RSSI value. If the classification is Friendly, the
condition requires the rogue AP to be detected with a maximum RSSI value. The
valid range is from –95 to –50 dBm (inclusive).
• SSID: This condition requires the rogue AP to have a specific SSID. You could
specify up to 25 different SSIDs. You should specify an SSID that the controller does
not manage. If you choose this option, enter the SSID for the ssid_name parameter.
The SSID is added to the configured SSID list you just created.
• Wildcard-SSID: This condition allows you to specify an expression that could match
an SSID string. You can specify up to 25 of these SSIDs.
This example shows how to create a rule that can categorize a rogue AP that is using SSID
my-friendly-ssid, and it is seen for at least for 1000 seconds as friendly internal:

WLC-9800(config)# wireless wps rogue rule ap1 priority 1

WLC-9800(config-rule)# condition ssid my-friendly-ssid
WLC-9800(config-rule)# condition duration 1000
WLC-9800(config-rule)# match all
WLC-9800(config-rule)# classify friendly state internal
WLC-9800(config-rule)# end

This example shows how to apply a condition that a rogue AP must meet:

WLC-9800(config)# wireless wps rogue rule ap1 priority 1

WLC-9800config-rule)# condition client-count 5
WLC-9800(config-rule)# condition duration 1000
WLC-9800(config-rule)# end

Classifying Rogue APs and Clients Manually

You can manually classify rogue APs and clients. This way, you can choose a specific AP or
a client and manually set the classification. As indicated previously, when you manually
classify the rogue AP, rogue rules are not applied to it.

The wireless monitoring option in the Cisco 9800 WLC GUI enables you to observe the
rogues and perform classification manually. Navigate
to Monitoring > Wireless > Rogues to see the options as indicated in the following figure,
where the rogue AP details would be listed. For example, in the Unclassified tab, if there are
unclassified rogues APs in the list, you can select the desired AP and set the status.

To detect and report an ad hoc rogue in the WLC CLI, use this command:

wireless wps rogue adhoc {alert mac-addr | auto-contain |

contain mac-addr containment-level | internal mac-addr |
external mac-addr}

When using the adhoc keyword in the command, you can use the following options:

• Alert: Sets the ad hoc rogue AP to alert mode. If you choose this option, enter the
MAC address for the mac-addr parameter.
• Auto-contain: Sets the automatically containing ad hoc rogue to autocontain mode.
• Auto-contain: Sets the automatically containing ad hoc rogue to autocontain mode.
• Contain: Sets the containing ad hoc rogue AP to contain mode. If you choose this
option, enter the MAC address for the mac-addr parameter and containment level for
 the containment-level parameter. The valid range for containment-level is from
1 to 4.
• External: Sets the ad hoc rogue AP as external. If you choose this option, enter the
MAC address for the mac-addr parameter.
• Internal: Sets the ad hoc rogue AP as internal. If you choose this option, enter the
MAC address for the mac-addr parameter.

For example, in the global configuration mode, use the wireless wps rogue adhoc alert
74a0.2f45.c520 command to set the rogue AP with the specified MAC to alert mode.

You can also manually classify a rogue AP using the following command.

wireless wps rogue ap {friendly mac-addr state [external |

internal] | malicious mac-addr state [alert | contain
containment-level]}

For example, use

the wireless wps rogue ap malicious 74a0.2f45.c520 state contain 3 to manually
classify a rogue AP as malicious and state contained.

You can also configure rogue clients while using the following command.

wireless wps rogue client {contain mac-addr containment-level}

For example, with the wireless wps rogue client contain 74a0.2f45.c520
2 command, you can report a rogue client.

Configuring Rogue Detection

The access points are designed to serve associated clients. Still, when the AP goes off
channel based on the scanning interval, it listens for rogue APs and clients, as well as
monitors for noise and channel interference. When you assign an AP Join Profile to the APs,
it contains settings for rogue detection. To access these settings in the GUI, navigate
to Configuration > Tags & Profiles > AP Join, click and edit a chosen profile. Then click
on the Security tab to view and if needed, modify the settings.

In the Rogues section of the Security tab of the AP Join Profile, you can use the following:

• Rogue Detection: Enables rogue detection. By default, it is enabled.

• Rogue Detection Minimum RSSI: Specifies the minimum RSSI value that rogues
should have for APs to detect and for rogue entry to be created in the device. The
valid range for the RSSI in dBm parameter is from –128 dBm to -70 dBm, and the
default value is -90 dBm. When there are rogues with very weak RSSI values that do
not provide any valuable information in rogue analysis, you can use this option to
filter rogues by specifying the minimum RSSI value at which APs should detect
rogues.
 • Rogue Detection Transient Interval: Specifies the transient interval for rogue
detection. The default value is 0 seconds.
• Rogue Detection Report Interval: Specifies the report interval for rogue detection.
The valid range for this interval is from 10 to 300 seconds, and the default value is 10
seconds.
• Rogue Containment Automatic Rate Selection: Enables auto-rate for containment
of rogues.
• Auto Containment on FlexConnect Standalone Enables auto rogue containment of
standalone flexconnect APs.

You can adjust the rogue detection settings in the WLC CLI as well while configuring the
selected AP Join Profile. In addition, you can use different show commands to verify the
rogue detection, as in the example below, verify rogue auto-containment information, display
rogue classification rules, inspect rogue statistics, and so on. The following command
provides various verification options that can be beneficial during rogue devices detection.

WLC-9800# show wireless wps rogue ap ?

clients Displays a list of all Rogue clients
associated with a rogue
custom Displays custom Rogue AP information
detailed Provides detailed information for a Rogue AP
friendly Displays Friendly Rogue AP information
list Show list of rogue APs detected by given AP
malicious Displays Malicious Rogue AP information
rldp Display RLDP scheduling information for rogue
APs
ssid Displays SSID and security policy info for
rogue APs
summary Displays a list of all Rogue APs
unclassified Displays Unclassified Rogue AP information

The following example shows information for rogue AP detection, which includes
authentication errors. As a result, this AP is classified as Malicious, and its state is set
to Threat.

WLC-9800# show wireless wps rogue ap detailed

Rogue BSSID : 0062.ecf3.8d30

Last heard Rogue SSID : rogueA
802.11w PMF required : No
Is Rogue an impersonator : Yes
Is Rogue on Wired Network : No
Classification : Malicious
Manually Contained : No
State : Threat
First Time Rogue was Reported : 01/07/2020 15:51:01
Last Time Rogue was Reported : 01/08/2020 08:08:35

Number of clients : 0

Reported By
AP Name : AP38ED.18CE.45E0
MAC Address : 38ed.18cf.83e0
Detecting slot ID : 0
Radio Type : dot11g, dot11n - 2.4
GHz
SSID : rogueA
Channel : 6 (From DS)
Channel Width : 20 MHz
RSSI : -33 dBm
SNR : 52 dB
ShortPreamble : Disabled
Security Policy : WPA2/WPA/FT
Last reported by this AP : 01/08/2020 08:02:53
Authentication Failure Count : 237

Configuring Rogue Policies

Within the wireless protection policies on the WLC, you can configure rogue policies. When
you navigate to Configuration > Security > Wireless Protection Policies in the Cisco 9800
WLC GUI, choose the Rogue Policies tab where you view and edit the policy settings.

You can adjust the existing parameters if needed, such as the rogue AP expiration timeout, as
well as you can enable additional features in the policy, such as to validate rogue clients and
APs against the AAA server, and so on.

Content Review Question

You are using the WLC CLI, and you want to manually classify a rogue AP as Malicious.
Which two state options are available for the wireless wps rogue ap
malicious command? (Choose two.)
• Internal
• External
• Alert
• Contain
Monitoring and Managing RF Interferers on
Cisco WLC
The important role of non-Wi-Fi interference in the high-density network should be clear.
The success of a high-density WLAN is compromised if any non-Wi-Fi RF interference
operates within the same environment. Non-Wi-Fi interference has a much larger impact on
throughput in a high-density environment than unmanaged Wi-Fi energy because 802.11
utilizes contention-based access mechanisms to coordinate station access to the channel. All
802.11 devices operate in this way. Non–Wi-Fi devices that operate in the same frequency
band do not share these rules and can effectively break the queuing and back-off
mechanisms. As a result, all stations within range must wait until the air is free.

Early in the process of drafting the 802.11 standards, a great concern emerged that the
proliferation of Wi-Fi networks would create interference for licensed users that operate in
the same frequency bands. As a result of this concern, Wi-Fi was very “polite” and yielded
the band to almost anything else it found operating there. Twenty years later, many consumer
devices share the industrial, scientific, and medical (ISM) bands with Wi-Fi. Although these
devices operate under the same output power restrictions as Wi-Fi devices, they are not
obligated to yield the band for Wi-Fi traffic, and most do not.

This situation creates a problem for normal Wi-Fi operations because a Wi-Fi modem can
classify energy only as follows:

• Wi-Fi (the detected RF energy can be demodulated)

• Noise (all remaining RF energy is considered to be noise)

The impact of non-Wi-Fi interference is logarithmic in its impact on Wi-Fi network

operations. The higher the utilization of the Wi-Fi network, the more destructive non-Wi-Fi
energy is. If interference is present, and the network is not heavily utilized (there is ample
duty cycle available within the spectrum), the presence of non-Wi-Fi energy may be
unnoticeable. In that situation, both have enough space to share the spectrum. However, if the
Wi-Fi network is heavily utilized, then even a small amount of non-Wi-Fi interference can
have a large and noticeable effect. Noise can come from many sources other than Wi-Fi,
some of which include microwave ovens, cordless telephones, wireless video cameras,
Bluetooth and ZigBee devices, game controllers, fluorescent lights, or outdoor wireless links
such as WiMAX.

The symptoms of interference may be different, but generally, they can be in the following
categories:

• Asynchronous LAN traffic: The primary symptom decreases or is highly variable

throughput, occasionally resulting in very low, or even nonexistent service rates.
• VoIP over Wi-Fi: The most common symptom that a typical user notices in the
presence of interference is dropouts because packets are lost due to collisions.
 • Video: Users typically notice dropouts and square boxes in the video, or even screen
freezing, when interference is a problem.

Cisco CleanAir
The Cisco CleanAir technology is a system-wide feature streamlining operations and
improving wireless performance by providing complete visibility into the spectrum. Suppose
an interference source is strong enough to jam a Wi-Fi channel completely. In that case,
the system will change channels within seconds to avoid interference, resuming client activity
on another channel outside the affected area.

Cisco CleanAir technology uses silicon-level intelligence to create a spectrum-aware, self-

healing, and self-optimizing wireless network that mitigates the impact of wireless
interference and offers performance protection for 802.11 networks. It allows you to see all
the users of a shared spectrum (both native devices and foreign interferers). Once the Cisco
CleanAir solution detects interference, the Radio Resource Management (RRM) algorithm
can act on this information.

Cisco CleanAir technology mitigates the impact of wireless interference in all Wi-Fi bands,
including 2.4 GHz and 5 GHz. Cisco CleanAir Pro extends the solution to the 6 GHz band
used by Wi-Fi 6E.

Cisco CleanAir is an enterprise-based, distributed spectrum analysis technology with the

following features:

• First chip-level proactive and automatic interference protection.

• Spectrum intelligence solution designed to manage the challenges of a shared wireless
spectrum.
• Reports interference details: who, what, when, where, and how.
• Enables the network to act on this information.

The Cisco CleanAir system consists of CleanAir-enabled APs and the Cisco Catalyst 9800
Series WLC.

• APs collect information about all the devices that operate in the industrial, scientific,
and medical (industrial, scientific, and medical [ISM]) bands, identify and evaluate
the information as a potential interference source, and forward it to the controller.
• The controller controls and configures CleanAir-capable APs and collects and
processes spectrum data. The controller provides local user interfaces (GUI and CLI)
to configure basic CleanAir features and services and display current spectrum
information. The controller also detects, merges, and mitigates interference devices
using RRM Transmit Power Control (TPC) and Dynamic Channel Assignment
(DCA)
For every device operating in the unlicensed band, Cisco CleanAir provides information
about what it is, how it is impacting your wireless network, and what actions to take. Cisco
CleanAir monitors the full channel bandwidth capability of a Cisco CleanAir-capable access
point (20 MHz—160 MHz channels).

To enable Cisco CleanAir on the Cisco Catalyst 9800 WLC in the GUI, navigate
to Configuration > Radio Configurations > CleanAir page and check the Enable
CleanAir check box for the desired frequency band.

In addition, you can configure Interference reporting for a 5-GHz and 2.4-GHz device by
choosing the interference types and adding them to the Interference Types to detect section
in the 5-GHz and 2.4-GHz bands. Hence, you can detect time division duplex (TDD)
transmitters, jammers, continuous transmitters, DECT-like phones, video cameras (used for
analog video cameras), devices that use spectrally inverted Wi-Fi signals, devices that uses
nonstandard Wi-Fi channels, and so on.

Spectrum Intelligence
Maintaining a healthy wireless environment requires knowledge of what is in the air.
Spectrum intelligence is a core technology that is designed for proactively managing the
challenges of a shared wireless spectrum by scanning for non-Wi-Fi radio interference on
2.4-GHz and 5-GHz bands.

Essentially, spectrum intelligence is data about RF spectrum activity that is derived from
advanced interference identification algorithms. Spectrum intelligence provides visibility of
all the users of the shared spectrum: both Wi-Fi devices and non-Wi-Fi interferers. For every
device that operates in the unlicensed band, spectrum intelligence tells you what the device is,
where the device is, and how it is affecting the Wi-Fi network.

The first step in effectively managing the environment is to know what is in the wireless
spectrum:

• Spectrum intelligence provides visibility of all users of the shared spectrum.

1. Wi-Fi devices.
2. Non-Wi-Fi interferences (such as microwave, continuous wave-like baby
monitor, Wi-Fi, and frequency hopping cordless phones, and so on.)
• Spectrum intelligence determines:
1. What the device is.
2. Where the device is.
3. How the device affects the Wi-Fi network.

Spectrum management is the active use of spectrum intelligence data to improve performance
and lower the operational costs of Wi-Fi networks. Information about the severity and
duration of interference can be used to calculate its impact on the network and to troubleshoot
problems. This information can also be stored for historical analysis and trending.
Note
Keep in mind that Cisco CleanAir provides spectrum management.

Combined with contextual data like physical location and system-wide correlation, spectrum
management is a powerful, proactive tool that increases WLAN reliability, performance, and
security.

To configure Spectrum Intelligence on the Catalyst 9800 WLC using GUI, navigate
to Configuration > Radio Configurations > CleanAir page and check the Enable SI check
box for the desired frequency band.

Clean Air Statistics

You can monitor interference devices by using the Cisco WLC GUI. This detailed report
contains information about classified devices that are sent from an AP to a Cisco WLC. To
see the Cisco Clean Air statistics on the Cisco 9800 WLC GUI, navigate
to Monitoring > Wireless > CleanAir Statistics and choose the frequency band.

In the CleanAir Interference Devices, you can view the following information:

• Cluster ID: When a CleanAir-enabled AP detects interference devices, detections of

the same device from multiple sensors are merged to create clusters. Each cluster is
given a unique ID.
• MAC Address: The device MAC address.
• Device ID: The device unique ID.
• Interferer Type: Type of the interferer.
• AP Name: The name of the AP where the interference device is detected.
• Severity: Severity index of the interfering device.
• RSSI (dBm): Receive signal strength indicator (RSSI) of the AP.
• Duty Cycle (%): Proportion of time during which the interfering device was active.
• Affected Channel: Channel that the device affects.

In the same menu, you can view similar information for the spectrum intelligence
interference devices.

With Cisco CleanAir, all energy within the spectrum that is definitely not Wi-Fi is accounted
for and classified. The system interprets energy that is 802.11-modulated and classifies
energy that is coming from co-channels and adjacent channel sources.

For each classified device, the system calculates a severity index, a positive integer from 0 to
100, with 100 being the most severe. The index is then subtracted from the air quality scale (0
to 100, with 100 being good) to generate the actual Air Quality Index (AQI) for a channel,
AP, floor, building, or campus. Air quality (AQ) is a rolling average that indicates the impact
of all classified interference devices against a theoretical perfect spectrum. For example, an
AQI of 10 is wrong, while an AQI > 85 is good.

In the CleanAir Statistics page, you can access the Air Quality Report for each radio band,
as indicated in this figure.

In the Air Quality Report, you can view the following information:

• AP Name: The name of the AP that reported the worst air quality.
• AP MAC: The MAC of the AP that reported the worst air quality.
• Channel: The radio channel where the air quality is monitored.
• Average AQ: The average air quality for this radio channel.
• Minimum AQ: The minimum air quality for this radio channel.
• Number of Interferers: The number of interferers detected by the radios.
• Detected Time: The time when the interferer was detected.

Within the Clear Air statistics page, you can also view the Worst Air Quality Report, which
provides the worst air quality information for the radio band.

Clean Air Trap Configuration

Besides determining which interference types to detect and report with Cisco Clean Air, you
can also choose which types of interference will generate an SNMP trap upon detection. The
configuration options include setting the AQI alarm threshold that triggers an alarm. To
define the interference types to trap, navigate to Configuration > Radio
Configurations > CleanAir page, select the desired frequency band, and choose the Trap
Configuration subtab. Then, check the Enable Air Quality Index (AQI) Trap check box
and choose from the available interference types.

The AQI Alarm Threshold enables you to specify a value between 1 and 100 for the
threshold at which you want the air quality alarm to be triggered. Hence, when the air quality
falls below the threshold level, the alarm is triggered, and you will get a trap notification that
there is an unusual level of interference in your wireless environment.

Content Review Question

You are using the Cisco 9800 WLC GUI to see the air quality report in your wireless
environment. What is considered to be a good AQI?
• AQI>30
• AQI>50
• AQI>75
•