-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This appendix contains the following sections:
This appendix lists system messages that can appear on the Cisco UWN solution interfaces, describes the LED patterns on controllers and lightweight access points, and provides CLI commands that can be used to troubleshoot problems on the controller. It contains these sections:
This section describes how to interpret controller LEDs and lightweight access point LEDs.
See the quick start guide for your specific controller for a description of the LED patterns. See the list of controllers and the respective documentation at http://www.cisco.com/en/US/products/hw/wireless/index.html .
See the quick start guide or hardware installation guide for your specific access point for a description of the LED patterns. See the list of access points and the respective documentation at http://www.cisco.com/en/US/products/hw/wireless/index.html.
Table 18-1 lists some common system messages and their descriptions. For a complete list of system messages, see the Cisco Wireless LAN Controller System Message Guide .
This section contains the following topics:
You can determine the amount of system resources being used by the controller such as the current controller CPU usage, system buffers, and web server buffers.
The Cisco 5500 Series Controllers have multiple CPUs, so you can view individual CPU usage. For each CPU, you can see the percentage of the CPU in use and the percentage of the CPU time spent at the interrupt level (for example, 0%/3%).
On the controller GUI, choose Management > Tech Support > System Resource Information . The System Resource Information page appears.
Figure 18-1 System Resource Information Page
On the controller CLI, enter these commands:
Information similar to the following appears:
Where the first number is the CPU percentage that the controller spent on the user application and the second number is the CPU percentage that the controller spent on the OS services.
If you experience any problems with your controller, you can use the commands in this section to gather information and debug issues.
1. show process cpu —Shows how various tasks in the system are using the CPU at that instant in time. This command is helpful in understanding if any single task is monopolizing the CPU and preventing other tasks from being performed.
Information similar to the following appears:
In the example above, the following fields provide information:
Note If you want to see the total CPU usage as a percentage, enter the show cpu command.
2. show process memory —Shows the allocation and deallocation of memory from various processes in the system at that instant in time.
Information similar to the following appears:
In the example above, the following fields provide information:
3. show tech-support —Shows information related to the state of the system, including the current configuration, last crash file, CPU utilization, and memory utilization.
4. show run-config —Shows the complete configuration of the controller. To exclude access point configuration settings, use the show run-config no-ap command.
Note If you want to see the passwords in clear text, enter the config passwd-cleartext enable command. To execute this command, you must enter an admin password. This command is valid only for this particular session. It is not saved following a reboot.
5. show run-config commands —Shows the list of configured commands on the controller. This command shows only values configured by the user. It does not show system-configured default values.
This section contains the following topics:
System logging allows controllers to log their system events to up to three remote syslog servers. The controller sends a copy of each syslog message as it is logged to each syslog server configured on the controller. Being able to send the syslog messages to multiple servers ensures that the messages are not lost due to the temporary unavailability of one syslog server. Message logging allows system messages to be logged to the controller buffer or console.
Step 1 Choose Management > Logs > Config . The Syslog Configuration page appears.
Figure 18-2 Syslog Configuration Page
Step 2 In the Syslog Server IP Address text box, enter the IP address of the server to which to send the syslog messages and click Add . You can add up to three syslog servers to the controller. The list of syslog servers that have already been added to the controller appears below this text box.
Note If you want to remove a syslog server from the controller, click Remove to the right of the desired server.
Step 3 To set the severity level for filtering syslog messages to the syslog servers, choose one of the following options from the Syslog Level drop-down list:
If you set a syslog level, only those messages whose severity is equal to or less than that level are sent to the syslog servers. For example, if you set the syslog level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are sent to the syslog servers.
Step 4 You can set the facility for outgoing syslog messages to the syslog servers. The facility level is used to specify what type of program is logging the message. Choose one of the following options from the Syslog Facility drop-down list:
Step 5 Click Apply to commit your changes.
Step 6 To set the severity level for logging messages to the controller buffer and console, choose one of the following options from both the Buffered Log Level and Console Log Level drop-down lists:
If you set a logging level, only those messages whose severity is equal to or less than that level are logged by the controller. For example, if you set the logging level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are logged.
Step 7 Select the File Info check box if you want the message logs to include information about the source file. The default value is enabled.
Step 8 Select the Trace Info check box if you want the message logs to include traceback information. The default value is disabled.
Step 9 Click Apply to commit your changes.
Step 10 Click Save Configuration to save your changes.
To view message logs using the controller GUI, choose Management > Logs > Message Logs . The Message Logs page appears.
Note To clear the current message logs from the controller, click Clear.
To configure system and message logging using the controller CLI, follow these steps:
Step 1 To enable system logging and set the IP address of the syslog server to which to send the syslog messages, enter this command:
config logging syslog host server_IP_address
You can add up to three syslog servers to the controller.
Note To remove a syslog server from the controller, enter this command:
config logging syslog host server_IP_address delete
Step 2 To set the severity level for filtering syslog messages to the syslog server, enter this command:
config logging syslog level severity_level
where severity_level is one of the following:
Note As an alternative, you can enter a number from 0 through 7 for the severity_level parameter.
Note If you set a syslog level, only those messages whose severity is equal to or less than that level are sent to the syslog server. For example, if you set the syslog level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are sent to the syslog server.
Step 3 To set the severity level for filtering syslog messages for a particular access point or for all access points, enter this command:
config ap logging syslog level severity_level { Cisco_AP | all }
where severity_level is one of the following:
Note If you set a syslog level, only those messages whose severity is equal to or less than that level are sent to the access point. For example, if you set the syslog level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are sent to the access point.
Step 4 To set the facility for outgoing syslog messages to the syslog server, enter this command:
config logging syslog facility facility_code
where facility_code is one of the following:
Step 5 To set the severity level for logging messages to the controller buffer and console, enter these commands:
where severity_level is one of the following:
Note As an alternative, you can enter a number from 0 through 7 for the severity_level parameter.
Note If you set a logging level, only those messages whose severity is equal to or less than that level are logged by the controller. For example, if you set the logging level to Warnings (severity level 4), only those messages whose severity is between 0 and 4 are logged.
Step 6 To save debug messages to the controller buffer, the controller console, or a syslog server, enter these commands:
By default, the console command is enabled, and the buffered and syslog commands are disabled.
Step 7 To cause the controller to include information about the source file in the message logs or to prevent the controller from displaying this information, enter this command:
config logging fileinfo {enable | disable}
Step 8 To cause the controller to include process information in the message logs or to prevent the controller from displaying this information, enter this command:
config logging procinfo { enable | disable }
The default value is disabled.
Step 9 To cause the controller to include traceback information in the message logs or to prevent the controller from displaying this information, enter this command:
config logging traceinfo {enable | disable}
The default value is disabled.
Step 10 To enable or disable timestamps in log messages and debug messages, enter these commands:
– datetime = Messages are timestamped with the standard date and time. This is the default value.
– disable = Messages are not timestamped.
Step 11 To save your changes, enter this command:
To see the logging parameters and buffer contents, enter this command:
Information similar to the following appears:
This section contains the following topics:
Access points log all system messages (with a severity level greater than or equal to notifications) to the access point event log. The event log can contain up to 1024 lines of messages, with up to 128 characters per line. When the event log becomes filled, the oldest message is removed to accommodate a new event message. The event log is saved in a file on the access point flash, which ensures that it is saved through a reboot cycle. To minimize the number of writes to the access point flash, the contents of the event log are written to the event log file during normal reload and crash scenarios only.
Use these CLI commands to view or clear the access point event log from the controller:
Information similar to the following appears:
This section contains the following topics:
– If you are uploading through the service port, the TFTP or FTP server must be on the same subnet as the service port because the service port is not routable, or you must create static routes on the controller.
– If you are uploading through the distribution system network port, the TFTP or FTP server can be on the same or a different subnet because the distribution system port is routable.
– A third-party TFTP or FTP server cannot run on the same computer as WCS because the WCS built-in TFTP or FTP server and the third-party TFTP or FTP server require the same communication port.
Step 1 Choose Command > Upload File . The Upload File from Controller page appears.
Figure 18-4 Upload File from Controller Page
Step 2 From the File Type drop-down list, choose one of the following:
Step 3 From the Transfer Mode drop-down list, choose TFTP or FTP .
Step 4 In the IP Address text box, enter the IP address of the TFTP or FTP server.
Step 5 In the File Path text box, enter the directory path of the log or crash file.
Step 6 In the File Name text box, enter the name of the log or crash file.
Step 7 If you chose FTP as the Transfer Mode, follow these steps:
a. In the Server Login Username text box, enter the FTP server login name.
b. In the Server Login Password text box, enter the FTP server login password.
c. In the Server Port Number text box, enter the port number of the FTP server. The default value for the server port is 21.
Step 8 Click Upload to upload the log or crash file from the controller. A message appears indicating the status of the upload.
Step 1 To transfer the file from the controller to a TFTP or FTP server, enter this command:
transfer upload mode { tftp | ftp }
Step 2 To specify the type of file to be uploaded, enter this command:
transfer upload datatype datatype
where datatype is one of the following options:
Step 3 To specify the path to the file, enter these commands:
Step 4 If you are using an FTP server, also enter these commands:
Note The default value for the port parameter is 21.
Step 5 To see the updated settings, enter this command:
Step 6 When prompted to confirm the current settings and start the software upload, answer y .
This section contains the following topics:
To help troubleshoot controller crashes, you can configure the controller to automatically upload its core dump file to an FTP server after experiencing a crash. You cannot upload the core dump file directly to an FTP or TFTP server but you can upload a crash file to an FTP or TFTP server. The controllers save the core dump file to flash memory following a crash.
Step 1 Choose Management > Tech Support > Core Dump to open the Core Dump page.
Step 2 To enable the controller to generate a core dump file following a crash, select the Core Dump Transfer check box.
Step 3 To specify the type of server to which the core dump file is uploaded, choose FTP from the Transfer Mode drop-down list.
Step 4 In the IP Address text box, enter the IP address of the FTP server.
Note The controller must be able to reach the FTP server.
Step 5 In the File Name text box, enter the name that the controller uses to label the core dump file.
Step 6 In the User Name text box, enter the username for FTP login.
Step 7 In the Password text box, enter the password for FTP login.
Step 8 Click Apply to commit your changes.
Step 9 Click Save Configuration to save your changes.
Step 1 To enable or disable the controller to generate a core dump file following a crash, enter this command:
config coredump { enable | disable }
Step 2 To specify the FTP server to which the core dump file is uploaded, enter this command:
config coredump ftp server_ip_address filename
Note The controller must be able to reach the FTP server.
Step 3 To specify the username and password for FTP login, enter this command:
config coredump username ftp_username password ftp_password
Step 4 To save your changes, enter this command:
Step 5 To see a summary of the controller’s core dump file, enter this command:
Information similar to the following appears:
Note This procedure is not applicable for Cisco 2106 and 4400 controllers.
Step 1 To see information about the core dump file in flash memory, enter this command:
Information similar to the following appears:
Step 2 To transfer the file from the controller to a TFTP or FTP server, enter these commands:
Note After the file is uploaded, it ends with a .gz suffix. If desired, you can upload the same core dump file multiple times with different names to different servers.
Step 3 If you are using an FTP server, also enter these commands:
Note The default value for the port parameter is 21.
Step 4 To view the updated settings, enter this command:
Step 5 When prompted to confirm the current settings and start the software upload, answer y.
This section contains the following topics:
When a Cisco 5500 Series Controller’s data plane crashes, it stores the last 50 packets that the controller received in flash memory. This information can be useful in troubleshooting the crash.
When a crash occurs, the controller generates a new packet capture file (*.pcap) file, and a message similar to the following appears in the controller crash file:
You can use the controller GUI or CLI to upload the packet capture file from the controller. You can then use Wireshark or another standard packet capture tool to view and analyze the contents of the file. Figure 18-6 shows a sample output of a packet capture file in Wireshark.
Figure 18-6 Sample Output of Packet Capture File in Wireshark
– If you are uploading through the service port, the TFTP or FTP server must be on the same subnet as the service port because the service port is not routable, or you must create static routes on the controller.
– If you are uploading through the distribution system network port, the TFTP or FTP server can be on the same or a different subnet because the distribution system port is routable.
– A third-party TFTP or FTP server cannot run on the same computer as WCS because the WCS built-in TFTP or FTP server and the third-party TFTP or FTP server require the same communication port.
Step 1 Choose Commands > Upload File to open the Upload File from Controller page.
Figure 18-7 Upload File from Controller Page
Step 2 From the File Type drop-down list, choose Packet Capture .
Step 3 From the Transfer Mode drop-down list, choose TFTP or FTP .
Step 4 In the IP Address text box, enter the IP address of the TFTP or FTP server.
Step 5 In the File Path text box, enter the directory path of the packet capture file.
Step 6 In the File Name text box, enter the name of the packet capture file. These files have a .pcap extension.
Step 7 If you are using an FTP server, follow these steps:
a. In the Server Login Username text box, enter the username to log into the FTP server.
b. In the Server Login Password text box, enter the password to log into the FTP server.
c. In the Server Port Number text box, enter the port number on the FTP server through which the upload occurs. The default value is 21.
Step 8 Click Upload to upload the packet capture file from the controller. A message appears indicating the status of the upload.
Step 9 Use Wireshark or another standard packet capture tool to open the packet capture file and see the last 50 packets that were received by the controller.
Step 1 Log on to the controller CLI.
Step 2 Enter the transfer upload mode { tftp | ftp } command.
Step 3 Enter the transfer upload datatype packet-capture command.
Step 4 Enter the transfer upload serverip server-ip-address command.
Step 5 Enter the transfer upload path server-path-to-file command.
Step 6 Enter the transfer upload filename last_received_pkts .pcap command.
Step 7 If you are using an FTP server, enter these commands:
Note The default value for the port parameter is 21.
Step 8 Enter the transfer upload start command to see the updated settings and then answer y when prompted to confirm the current settings and start the upload process. This example shows the upload command output:
Step 9 Use Wireshark or another standard packet capture tool to open the packet capture file and see the last 50 packets that were received by the controller.
This section provides instructions for troubleshooting hard-to-solve or hard-to-reproduce memory problems.
Step 1 To enable or disable monitoring for memory errors and leaks, enter this command:
config memory monitor errors { enable | disable }
The default value is disabled.
Note Your changes are not saved across reboots. After the controller reboots, it uses the default setting for this feature.
Step 2 If you suspect that a memory leak has occurred, enter this command to configure the controller to perform an auto-leak analysis between two memory thresholds (in kilobytes):
config memory monitor leaks low_thresh high_thresh
If the free memory is lower than the low_thresh threshold, the system crashes, generating a crash file. The default value for this parameter is 10000 kilobytes, and you cannot set it below this value.
Set the high_thresh threshold to the current free memory level or higher so that the system enters auto-leak-analysis mode. After the free memory reaches a level lower than the specified high_thresh threshold, the process of tracking and freeing memory allocation begins. As a result, the debug memory events enable command shows all allocations and frees, and the show memory monitor detail command starts to detect any suspected memory leaks. The default value for this parameter is 30000 kilobytes.
Step 3 To see a summary of any discovered memory issues, enter this command:
Information similar to the following appears:
Step 4 To see the details of any memory leaks or corruption, enter this command:
Information similar to the following appears:
Step 5 If a memory leak occurs, enter this command to enable debugging of errors or events during memory allocation:
debug memory {errors | events} {enable | disable}
This section contains the following topics:
The controller supports three features designed to help troubleshoot communication problems with CCXv5 clients: diagnostic channel, client reporting, and roaming and real-time diagnostics. See the “Configuring Cisco Client Extensions” section for more information on CCX.
These features are supported only on CCXv5 clients. They are not supported for use with non-CCX clients or with clients running an earlier version of CCX.
The diagnostic channel feature enables you to troubleshoot problems regarding client communication with a WLAN. The client and access points can be put through a defined set of tests in an attempt to identify the cause of communication difficulties the client is experiencing and then allow corrective measures to be taken to make the client operational on the network. You can use the controller GUI or CLI to enable the diagnostic channel, and you can use the controller CLI or WCS to run the diagnostic tests.
Note We recommend that you enable the diagnostic channel feature only for nonanchored SSIDs that use the management interface.
Step 1 Choose WLANs to open the WLANs page.
Step 2 Create a new WLAN or click the ID number of an existing WLAN.
Note We recommend that you create a new WLAN on which to run the diagnostic tests.
Step 3 When the WLANs > Edit page appears, choose the Advanced tab to open the WLANs > Edit (Advanced) page.
Figure 18-8 WLANs > Edit (Advanced) Page
Step 4 If you want to enable diagnostic channel troubleshooting on this WLAN, select the Diagnostic Channel check box. Otherwise, leave this check box unselected, which is the default value.
Note You can use the CLI to initiate diagnostic tests on the client. See the “Configuring the Diagnostic Channel (CLI)” section for details.
Step 5 Click Apply to commit your changes.
Step 6 Click Save Configuration to save your changes.
Step 1 To enable diagnostic channel troubleshooting on a particular WLAN, enter this command:
config wlan diag-channel { enable | disable } wlan_id
Step 2 To verify that your change has been made, enter this command:
Information similar to the following appears:
Step 3 To send a request to the client to perform the DHCP test, enter this command:
config client ccx dhcp-test client_mac_address
Note This test does not require the client to use the diagnostic channel.
Step 4 To send a request to the client to perform the default gateway ping test, enter this command:
config client ccx default-gw-ping client_mac_address
Note This test does not require the client to use the diagnostic channel.
Step 5 To send a request to the client to perform the DNS server IP address ping test, enter this command:
config client ccx dns-ping client_mac_address
Note This test does not require the client to use the diagnostic channel.
Step 6 To send a request to the client to perform the DNS name resolution test to the specified hostname, enter this command:
config client ccx dns-resolve client_mac_address host_name
Note This test does not require the client to use the diagnostic channel.
Step 7 To send a request to the client to perform the association test, enter this command:
config client ccx test-association client_mac_address ssid bssid { 802.11a | 802.11b | 802.11g } channel
Step 8 To send a request to the client to perform the 802.1X test, enter this command:
config client ccx test-dot1x client_mac_address profile_id bssid { 802.11a | 802.11b | 802.11g } channel
Step 9 To send a request to the client to perform the profile redirect test, enter this command:
config client ccx test-profile client_mac_address profile_id
The profile_id should be from one of the client profiles for which client reporting is enabled.
Note Users are redirected back to the parent WLAN, not to any other profile. The only profile shown is the user’s parent profile. However, parent WLAN profiles can have one child diagnostic WLAN.
Step 10 Use these commands if necessary to terminate or clear a test:
config client ccx test-abort client_mac_address
Only one test can be pending at a time, so this command terminates the current pending test.
config client ccx clear-results client_mac_address
Step 11 To send a message to the client, enter this command:
config client ccx send-message client_mac_address message_id
where message_id is one of the following:
Step 12 To see the status of the last test, enter this command:
show client ccx last-test-status client_mac_address
Information similar to the following appears for the default gateway ping test:
Step 13 To see the status of the last test response, enter this command:
show client ccx last-response-status client_mac_address
Information similar to the following appears for the 802.1X authentication test:
Step 14 To see the results from the last successful diagnostics test, enter this command:
show client ccx results client_mac_address
Information similar to the following appears for the 802.1X authentication test:
Step 15 To see the relevant data frames captured by the client during the previous test, enter this command:
show client ccx frame-data client_mac_address
Information similar to the following appears:
The client reporting protocol is used by the client and the access point to exchange client information. Client reports are collected automatically when the client associates. You can use the controller GUI or CLI to send a client report request to any CCXv5 client any time after the client associates. There are four types of client reports:
Step 1 Choose Monitor > Clients to open the Clients page.
Step 2 Click the MAC address of the desired client. The Clients > Detail page appears.
Figure 18-9 Clients > Detail Page
Step 3 Click Send CCXV5 Req to send a report request to the client.
Note You must create a Trusted Profile using ACAU for Cisco CB21AG or equivalent software from your CCXv5 vendor.
Step 4 Click Display to view the parameters from the client. The Client Reporting page appears.
Figure 18-10 Client Reporting Page
This page lists the client profiles and indicates if they are currently in use. It also provides information on the client’s operating parameters, manufacturer, and capabilities.
Step 5 Click the link for the desired client profile. The Profile Details page appears.
Figure 18-11 Profile Details Page
This page shows the client profile details, including the SSID, power save mode, radio channel, data rates, and 802.11 security settings.
Step 1 To send a request to the client to send its profiles, enter this command:
config client ccx get-profiles client_mac_address
Step 2 To send a request to the client to send its current operating parameters, enter this command:
config client ccx get-operating-parameters client_mac_address
Step 3 To send a request to the client to send the manufacturer’s information, enter this command:
config client ccx get-manufacturer-info client_mac_address
Step 4 To send a request to the client to send its capability information, enter this command:
config client ccx get-client-capability client_mac_address
Step 5 To clear the client reporting information, enter this command:
config client ccx clear-reports client_mac_address
Step 6 To see the client profiles, enter this command:
show client ccx profiles client_mac_address
Information similar to the following appears:
Step 7 To see the client operating parameters, enter this command:
show client ccx operating-parameters client_mac_address
Information similar to the following appears:
Step 8 To see the client manufacturer information, enter this command:
show client ccx manufacturer-info client_mac_address
Information similar to the following appears:
Step 9 To see the client’s capability information, enter this command:
show client ccx client-capability client_mac_address
Note This command displays the client’s available capabilities, not current settings for the capabilities.
Information similar to the following appears:
You can use roaming and real-time logs and statistics to solve system problems. The event log enables you to identify and track the behavior of a client device. It is especially useful when attempting to diagnose difficulties that a user may be having on a WLAN. The event log provides a log of events and reports them to the access point. There are three categories of event logs:
The statistics report provides 802.1X and security information for the client. You can use the controller CLI to send the event log and statistics request to any CCXv5 client any time after the client associates.
Step 1 To send a log request, enter this command:
config client ccx log-request log_type client_mac_address
where log_type is roam, rsna, or syslog.
Step 2 To view a log response, enter this command:
show client ccx log-response log_type client_mac_address
where log_type is roam, rsna, or syslog.
Information similar to the following appears for a log response with a log_type of roam:
Information similar to the following appears for a log response with a log_type of rsna:
Information similar to the following appears for a log response with a log_type of syslog:
Step 3 To send a request for statistics, enter this command:
config client ccx stats-request measurement_duration stats_name client_mac_address
where stats_name is dot11 or security.
Step 4 To view the statistics response, enter this command:
show client ccx stats-report client_mac_address
Information similar to the following appears:
This section contains the following topics:
The debug facility enables you to display all packets going to and from the controller CPU. You can enable it for received packets, transmitted packets, or both. By default, all packets received by the debug facility are displayed. However, you can define access control lists (ACLs) to filter packets before they are displayed. Packets not passing the ACLs are discarded without being displayed.
Each ACL includes an action (permit, deny, or disable) and one or more fields that can be used to match the packet. The debug facility provides ACLs that operate at the following levels and on the following values:
– Destination port (if applicable)
– Destination port (if applicable)
– Destination port (if applicable)
At each level, you can define multiple ACLs. The first ACL that matches the packet is the one that is selected.
Step 1 To enable the debug facility, enter this command:
debug packet logging enable { rx | tx | all } packet_count display_size
Note To disable the debug facility, enter debug packet logging disable command.
Step 2 Configure packet-logging ACLs by entering these commands:
– rule_index is a value between 1 and 6 (inclusive).
– action is permit, deny, or disable.
– npu_encap specifies the NPU encapsulation type, which determines how packets are filtered. The possible values include dhcp, dot11-mgmt, dot11-probe, dot1x, eoip-ping, iapp, ip, lwapp, multicast, orphan-from-sta, orphan-to-sta, rbcp, wired-guest, or any.
– port is the physical port for packet transmission or reception.
– rule_index is a value between 1 and 6 (inclusive).
– action is permit, deny, or disable.
– dst is the destination MAC address.
– src is the source MAC address.
– type is the two-byte type code (such as 0x800 for IP, 0x806 for ARP). This parameter also accepts a few common string values such as “ip” (for 0x800) or “arp” (for 0x806).
– vlan is the two-byte VLAN ID.
– proto is a numeric or any string recognized by getprotobyname(). The controller supports the following strings: ip, icmp, igmp, ggp, ipencap, st, tcp, egp, pup, udp, hmp, xns-idp, rdp, iso-tp4, xtp, ddp, idpr-cmtp, rspf, vmtp, ospf, ipip, and encap.
– src_port is the UDP/TCP two-byte source port (for example, telnet, 23) or “any.” The controller accepts a numeric or any string recognized by getservbyname(). The controller supports the following strings: tcpmux, echo, discard, systat, daytime, netstat, qotd, msp, chargen, ftp-data, ftp, fsp, ssh, telnet, smtp, time, rlp, nameserver, whois, re-mail-ck, domain, mtp, bootps, bootpc, tftp, gopher, rje, finger, www, link, kerberos, supdup, hostnames, iso-tsap, csnet-ns, 3com-tsmux, rtelnet, pop-2, pop-3, sunrpc, auth, sftp, uucp-path, nntp, ntp, netbios-ns, netbios-dgm, netbios-ssn, imap2, snmp, snmp-trap, cmip-man, cmip-agent, xdmcp, nextstep, bgp, prospero, irc, smux, at-rtmp, at-nbp, at-echo, at-zis, qmtp, z3950, ipx, imap3, ulistserv, https, snpp, saft, npmp-local, npmp-gui, and hmmp-ind.
– dst_port is the UDP/TCP two-byte destination port (for example, telnet, 23) or “any.” The controller accepts a numeric or any string recognized by getservbyname(). The controller supports the same strings as those for the src_port .
– bssid is the Basic Service Set Identifier.
– snap_type is the Ethernet type.
Note To remove all configured ACLs, enter debug packet logging acl clear-all command.
Step 3 To configure the format of the debug output, enter this command:
debug packet logging format { hex2pcap | text2pcap }
The debug facility supports two output formats: hex2pcap and text2pcap. The standard format used by IOS supports the use of hex2pcap and can be decoded using an HTML front end. The text2pcap option is provided as an alternative so that a sequence of packets can be decoded from the same console log file. Figure 18-12 shows an example of hex2pcap output, and Figure 18-13 shows an example of text2pcap output.
Figure 18-12 Sample Hex2pcap Output
Figure 18-13 Sample Text2pcap Output
Step 4 To determine why packets might not be displayed, enter this command:
debug packet error { enable | disable }
Step 5 To display the status of packet debugging, enter this command:
Information similar to the following appears:
This section contains the following topics:
The controller enables you to configure an access point as a network “sniffer,” which captures and forwards all the packets on a particular channel to a remote machine that runs packet analyzer software. These packets contain information on time stamps, signal strength, packet sizes, and so on. Sniffers allow you to monitor and record network activity and to detect problems.
– Wildpackets Omnipeek or Airopeek
– AirMagnet Enterprise Analyzer
To perform wireless sniffing, you need the following hardware and software:
Step 1 Choose Wireless > Access Points > All APs to open the All APs page.
Step 2 Click the name of the access point that you want to configure as the sniffer. The All APs > Details for page appears.
Figure 18-14 All APs > Details for Page
Step 3 From the AP Mode drop-down list, choose Sniffer .
Step 4 Click Apply to commit your changes.
Step 5 Click OK when warned that the access point will be rebooted.
Step 6 Choose Wireless > Access Points > Radios > 802.11a/n (or 802.11b/g/n ) to open the 802.11a/n (or 802.11b/g/n) Radios page.
Step 7 Hover your cursor over the blue drop-down arrow for the desired access point and choose Configure . The 802.11a/n (or 802.11b/g/n) Cisco APs > Configure page appears.
Step 8 Select the Sniff check box to enable sniffing on this access point, or leave it unselected to disable sniffing. The default value is unchecked.
Step 9 If you enabled sniffing in Step 8, follow these steps:
a. From the Channel drop-down list, choose the channel on which the access point sniffs for packets.
b. In the Server IP Address text box, enter the IP address of the remote machine running Omnipeek, Airopeek, AirMagnet, or Wireshark.
Step 10 Click Apply to commit your changes.
Step 11 Click Save Configuration to save your changes.
Step 1 To configure the access point as a sniffer, enter this command:
config ap mode sniffer Cisco_AP
where Cisco_AP is the access point configured as the sniffer.
Step 2 When warned that the access point will be rebooted and asked if you want to continue, enter Y . The access point reboots in sniffer mode.
Step 3 To enable sniffing on the access point, enter this command:
config ap sniff {802.11a | 802.11b} enable channel server_IP_address Cisco_AP
– channel is the radio channel on which the access point sniffs for packets. The default values are 36 (802.11a/n) and 1 (802.11b/g/n).
– server_IP_address is the IP address of the remote machine running Omnipeek, Airopeek, AirMagnet, or Wireshark.
– Cisco_AP is the access point configured as the sniffer.
Note To disable sniffing on the access point, enter the config ap sniff {802.11a | 802.11b} disable Cisco_AP command.
Step 4 To save your changes, enter this command:
Step 5 To view the sniffer configuration settings for an access point, enter this command:
show ap config { 802.11a | 802.11b } Cisco_AP
Information similar to the following appears:
This section contains the following topics:
The controller supports the use of the Telnet and Secure Shell (SSH) protocols to troubleshoot lightweight access points. Using these protocols makes debugging easier, especially when the access point is unable to connect to the controller.
Note For instructions on configuring Telnet or SSH SSH sessions on the controller, see the “Configuring Telnet and SSH Sessions” section.
You can configure Telnet or SSH by using the controller CLI in software release 5.0 or later releases or using the controller GUI in software release 6.0 or later releases.
Step 1 Choose Wireless > Access Points > All APs to open the All APs page.
Step 2 Click the name of the access point for which you want to enable Telnet or SSH.
Step 3 Choose the Advanced tab to open the All APs > Details for (Advanced) page.
Figure 18-15 All APs > Details for (Advanced) Page
Step 4 Select the Telnet check box to enable Telnet connectivity on this access point, . The default value is unchecked.
Step 5 Select the SSH check box to enable SSH connectivity on this access point. The default value is unchecked.
Step 6 Click Apply to commit your changes.
Step 7 Click Save Configuration to save your changes.
Step 1 To enable Telnet or SSH connectivity on an access point, enter this command:
config ap { telnet | ssh } enable Cisco_AP
The default value is disabled.
Note To disable Telnet or SSH connectivity on an access point, enter the config ap {telnet | ssh} disable Cisco_AP command.
Step 2 To save your changes, enter this command:
Step 3 To see whether Telnet or SSH is enabled on an access point, enter this command:
show ap config general Cisco_AP
Information similar to the following appears:
This section contains the following topics:
The controller sends access point status information to the Cisco 3300 Series Mobility Services Engine (MSE) using the access point monitor service.
The MSE sends a service subscription and an access point monitor service request to get the status of all access points currently known to the controller. When any change is made in the status of an access point, a notification is sent to the MSE.
If you experience any problems with the access point monitor service, enter this command:
debug service ap-monitor {all | error | event | nmsp | packet} {enable | disable}
This section contains the following topics:
This section provides troubleshooting information if you experience any problems with your OfficeExtend access points.
The LED patterns are different for 1130 series and 1140 series OfficeExtend access points. See the Cisco OfficeExtend Access Point Quick Start Guide for a description of the LED patterns. You can find this guide at this URL:
When positioning your OfficeExtend access point, consider that its RF signals are emitted in a cone shape spreading outward from the LED side of the access point. Be sure to mount the access point so that air can flow behind the metal back plate and prevent the access point from overheating.
Figure 18-16 OfficeExtend Access Point Radiation Patterns
Most of the problems experienced with OfficeExtend access points are one of the following:
Resolution: Follow the instructions in the “Viewing Access Point Join Information (GUI)” section to view join statistics for the OfficeExtend access point, or find the access point’s public IP address and perform pings of different packet sizes from inside the company.
Resolution: Ask the teleworker for the LED status.
Resolution: Ask the teleworker to perform a speed test and a ping test. Some servers do not return big packet pings.
Resolution: Perform client troubleshooting in WCS to determine if the problem is related to the OfficeExtend access point or the client.
Resolution : Ask the teleworker to check the cables, power supply, and LED status. If you still cannot identify the problem, ask the teleworker to try the following:
– Connect to the home router directly and see if the PC is able to connect to an Internet website such as http://www.cisco.com/ . If the PC cannot connect to the Internet, check the router or modem. If the PC can connect to the Internet, check the home router configuration to see if a firewall or MAC-based filter is enabled that is blocking the access point from reaching the Internet.
– Log on to the home router and check to see if the access point has obtained an IP address. If it has, the access point’s LED normally blinks orange.
Resolution : A problem could exist with the home router. Ask the teleworker to check the router manual and try the following:
– Assign the access point a static IP address based on the access point’s MAC address.
– Put the access point in a demilitarized zone (DMZ), which is a small network inserted as a neutral zone between a company’s private network and the outside public network. It prevents outside users from getting direct access to a server that has company data.
– If problems still occur, contact your company’s IT department for assistance.
Resolution : Clear the access point configuration and return it to the factory-default settings by clicking Clear Config on the access point GUI or by entering the clear ap config Cisco_AP command and then follow the steps in the “Configuring a Personal SSID on an OfficeExtend Access Point” section to try again. If problems still occur, contact your company’s IT department for assistance.
Resolution : Ask the teleworker to follow these steps:
a. Leave all devices networked and connected, and then power down all the devices.
b. Turn on the cable or DSL modem, and then wait for 2 minutes. (Check the LED status.)
c. Turn on the home router, and then wait for 2 minutes. (Check the LED status.)
d. Turn on the access point, and then wait for 5 minutes. (Check the LED status.)
When a mesh access point that joined the controller uses radio backhaul with the intent to use Ethernet as mesh backhaul, an inappropriate operation sequence could occur, when you enter the flapping mac-address .
Note This troubleshooting tip is not applicable if Ethernet is not used for mesh AP backhaul,
To configure a mesh map Ethernet port (on the same subnet or VLAN of the Mesh RAP) as the mesh backhaul at runtime, follow these steps:
Step 1 Choose Configure > Access Points > All APs > select the AP name, click on Reset AP Now to reset mesh AP.
Step 2 Connect the Ethernet cable between the switch and the mesh AP.