Available only from the CLI, debug commands can be used on the con-troller to help troubleshoot issues.. Example 20-3 Viewing Available debug Commands Cisco Controller >debug?. dot11 Con
Trang 1Status Code 0
Session Timeout 0
Client CCX version No CCX support Mirroring Disabled QoS Level Silver Diff Serv Code Point (DSCP) disabled 802.1P Priority Tag disabled WMM Support Disabled Mobility State None Mobility Move Count 0
Security Policy Completed No —More— or (q)uit Policy Manager State START Policy Manager Rule Created Yes NPU Fast Fast Notified No Policy Type N/A Encryption Cipher None Management Frame Protection No EAP Type Unknown Interface management VLAN 0
Client Capabilities: CF Pollable Not implemented CF Poll Request Not implemented Short Preamble Not implemented PBCC Not implemented Channel Agility Not implemented Listen Interval 0
Client Statistics: Number of Bytes Received 0
Number of Bytes Sent 0
Number of Packets Received 0
Number of Packets Sent 0
Number of Policy Errors 0 Radio Signal Strength Indicator Unavailable
—More— or (q)uit Signal to Noise Ratio Unavailable Nearby AP Statistics:
TxExcessiveRetries: 0 TxRetries: 0
RtsSuccessCnt: 0 RtsFailCnt: 0 TxFiltered: 0 TxRateProfile: [0,0,0,0,0,0,0,0,0,0,0,0]
Example 20-2 Viewing Client Details (continued)
Trang 2antenna0: 5 seconds ago -93 dBm antenna1: 4293918453 seconds ago -128 dBm
Lobby-AP(slot 0)
antenna0: 4293918453 seconds ago -128 dBm antenna1: 5 seconds ago -94 dBm
Although this information is valuable, it is important to note that it is static In other
words, the information you gain from show commands gives you the state or the
condi-tions of the network at the time that you enter the command If you require real-time in-formation, debugs come in handy
If you have come from the routing world, you are probably familiar with the use of debug
commands and how invaluable they are in troubleshooting If you are working your way through the certification program, and you are doing it in order (CCNA > CCNA
Wire-less), then you learned in the CCNA curriculum how a debug command is used in some basic troubleshooting scenarios The concept of debug commands carries over here to the wireless space Available only from the CLI, debug commands can be used on the con-troller to help troubleshoot issues The principle in the use of debug commands is the
same:
■ Do not leave them on, because they are CPU intensive
■ Be prepared to turn them off Sometimes the output is overwhelming
■ Debug commands take priority over other processes on the controller.
If you think that some debug commands might already be enabled, use the show debug
command to verify that notion One fail-safe that is in place is that if you do turn on a
debug command and forget about it, the debug becomes disabled when the CLI session times out Although this is a good fail-safe, you should still turn your debug commands off when you are done with them To see a list of the available debug commands, use the debug ? command, as seen in Example 20-3 You can use this to determine which debug
command is appropriate for the situation; for example, if you are troubleshooting a
port-based authentication problem, you might enable debug dot1x.
Example 20-3 Viewing Available debug Commands
(Cisco Controller) >debug ?
aaa Configures the AAA debug options.
airewave-director Configures the Airewave Director debug options
ap Configures debug of Cisco AP.
arp Configures debug of ARP.
bcast Configures debug of broadcast.
cac Configures the call admission control (CAC) debug options.
cdp Configures debug of cdp.
crypto Configures the Hardware Crypto debug options.
dhcp Configures the DHCP debug options.
client Enables debugs for common client problems.
disable-all Disables all debug messages.
continues
Example 20-2 Viewing Client Details (continued)
Trang 3dot11 Configures the 802.11 events debug options.
dot1x Configures the 802.1X debug options.
iapp Configures the IAPP debug options.
ccxrm Configures the CCX_RM debug options.
ccxdiag Configures the CCX Diagnostic debug options.
locp Configures the LOCP debug options.
l2roam Configures the L2 Roam debug options.
l2age Configures debug of Layer 2 Ago Timeout Messages.
lwapp Configures the LWAPP debug options mac Configures MAC debugging
More or (q)uit
To really hone in on where the issues are, you can use debug commands for a specific AP
or a specific client This requires placing the controller into client troubleshooting mode
To do this, begin by telling the controller, by way of a CLI command, that you want to de-bug for a specific MAC address For example, to tell the controller that it will be dede-bug- debug-ging for MAC address 00:1a:a2:f9:ed:d0, enter the following:
(Cisco Controller) >debug mac addr 00:1a:a2:f9:ed:d0
The next step is to tell the controller which debug to use for that particular MAC address For example, if you want to debug LWAPP events for the MAC address 00:1a:a2:f9:ed:d0,
use the debug lwapp command as shown here:
(Cisco Controller) >debug lwapp events enable
To verify that the debug command is enabled, use the show debug command, as seen in
Example 20-4
Example 20-4 Verifying Enabled Debugs
(Cisco Controller) >show debug
MAC address 00:1a:a2:f9:ed:d0
Debug Flags Enabled:
arp error enabled.
bcast error enabled.
lwapp events enabled.
lwapp errors enabled.
Then you wait for an LWAPP event to occur In Example 20-5, an LWAPP event has oc-curred, and a message has been sent to the console
Example 20-5 Controller Debug Output
(Cisco Controller) >Wed Jun 25 19:50:50 2008: 00:1a:a2:f9:ed:d0 Received LWAPP ECHO_REQUEST from AP 00:1a:a2:f9:ed:d0
Wed Jun 25 19:50:50 2008: 00:1a:a2:f9:ed:d0 Successfully transmission of LWAPP Echo-Response to AP 00:1a:a2:f9:ed:d0
Wed Jun 25 19:50:50 2008: 00:1a:a2:f9:ed:d0 Received LWAPP PRIMARY_DISCOVERY_REQ
Key
Topic
Key
Topic
Example 20-3 Viewing Available debug Commands (continued)
Key
Topic
Trang 4Wed Jun 25 19:50:50 2008: 00:1a:a2:f9:ed:d0 Received LWAPP RRM_DATA_REQ from AP 00:1a:a2:f9:ed:d0
Wed Jun 25 19:50:50 2008: 00:1a:a2:f9:ed:d0 Successfully transmission of LWAPP Airewave-Director-Data Response to AP 00:1a:a2:f9:ed:d0
Wed Jun 25 19:51:14 2008: 00:1a:a2:f9:ed:d0 Received LWAPP RRM_DATA_REQ from AP 00:1a:a2:f9:ed:d0
Wed Jun 25 19:51:14 2008: 00:1a:a2:f9:ed:d0 Successfully transmission of LWAPP Airewave-Director-Data Response to AP 00:1a:a2:f9:ed:d0
The actual output of the debug in the example is pretty normal What is important, how-ever, is that you understand how to enable the debug process, verify it, and turn it off To
disable the debug process, use the debug disable-all command, as seen in Example 20-6.
First the debug process was verified with the show debug command, and then it was dis-abled After the debug process was disabled, the command show debug was again used to
verify that it was in fact disabled
Example 20-6 Verify the Enabled Debugs
(Cisco Controller) >show debug
MAC address 00:1a:a2:f9:ed:d0
Debug Flags Enabled:
arp error enabled.
bcast error enabled.
lwapp events enabled.
lwapp errors enabled.
(Cisco Controller) >debug disable-all
(Cisco Controller) >show debug
MAC debugging disabled
Debug Flags Enabled:
(Cisco Controller) >
When you let the session time out, even though it turns off the debug command, it still
leaves the command to perform client troubleshooting, as seen in Example 20-7 This
means that if you enable a new debug command, it only debugs for the client you specify.
Example 20-7 Command to Perform Client Troubleshooting Remains
Connection to 192.168.1.50 closed.
terminal$:
terminal$:
terminal$:ssh 192.168.1.50
continues
Example 20-5 Controller Debug Output (continued)
Trang 5(Cisco Controller) User: admin Password:*****
(Cisco Controller) >show debug MAC address 00:1a:a2:f9:ed:d0
Debug Flags Enabled:
As you can see, the connection was closed, essentially timing out After authenticating
again to the CLI of the controller, the show debug command was entered This command
output indicates that the MAC address 00:1a:a2:f9:ed:d0 is still enabled for client
debug-ging The point here is that it is always best to turn off debug commands when you are finished using them You can also turn off a specific debug command using the disable
option at the end of the command For example, to turn off the LWAPP debug that was
used in the previous examples, you would use the debug lwapp events disable command When you are comfortable turning debug commands on and off, you can explore debug commands such as debug dot11 The debug dot11 command helps you troubleshoot
802.11 parameters, such as these:
■ Mobility
■ Rogue detection
■ Load balancing events
In Example 20-8, you can see a client that has successfully associated
Example 20-8 A Successful Association
Fri Aug 8 15:32:54 2008: 00:1e:c2:ab:14:26 apfPemAddUser2 (apf_policy.c:209) Changing state for mobile 00:1e:c2:ab:14:26 on AP 00:1a:a2:f9:ed:d0 from Associated to Associated
Fri Aug 8 15:32:54 2008: 00:1e:c2:ab:14:26 New client (policy)
Fri Aug 8 15:32:54 2008: 00:1e:c2:ab:14:26 Stopping deletion of Mobile Station: (callerId: 48)
Fri Aug 8 15:32:54 2008: 00:1e:c2:ab:14:26 Sending Assoc Response to station on BSSID 00:1a:a2:f9:ed:d0 (status 0)
Fri Aug 8 15:32:54 2008: 00:1e:c2:ab:14:26 apfProcessAssocReq (apf_80211.c:4149) Changing state for mobile 00:1e:c2:ab:14:26 on AP 00:1a:a2:f9:ed:d0 from Associated to Associated
Fri Aug 8 15:32:54 2008: 00:1e:c2:ab:14:26 802 new client 00:1e:c2:ab:14:26
Example 20-5 Command to Perform Client Troubleshooting Remains (continued)
Trang 6Figure 20-1 Viewing the Client Summary
Fri Aug 8 15:32:55 2008: 00:1e:c2:ab:14:26 LBS Client data rcvd from AP 00:1a:a2:f9:ed:d0(0) with RSSI (A -128, B -36), SNR 57
Fri Aug 8 15:32:55 2008: 00:1e:c2:ab:14:26 LBS change cur RSSI B -44 , prev -47, send notify
In this small output, you can see that the client has become associated One aspect of troubleshooting might involve connectivity With this output, you can see that the client
is in fact associated If the client still has connectivity issues, you would want to start looking at the wired network, working your way from the controller, then to the switch, then to the next hop router, and so on
You can also use debugs such as debug dhcp if you are having issues with clients obtain-ing IP addresses If you are havobtain-ing authentication issues, you might use the debug aaa or debug dot1x commands.
Using the Controller Interface
The controller has several tools to help troubleshoot From the controller interface, you can use controller logs, SNMP to alert administrators to current issues, and the Tech Sup-port Pages In the section “Using the CLI to Troubleshoot,” you looked at output of a
client that was trying to associate You can see a web interface equivalent to the show client summary command in Figure 20-1.
Key Topic
Example 20-8 A Successful Association (continued)
Trang 7Figure 20-2 Viewing the Controller Logs
Here you can gain information about the client, the WLAN the client is on, and other valuable information for troubleshooting
Using the Controller Logs
Another valuable resource is the controller logs Controller logs allow you to see events that have occurred at various levels You probably want to send these to a Syslog server,
but you can view them on the controller by going to MANAGEMENT > Logs > Mes-sage logs Figure 20-2 shows just a sample of the information that you can obtain here.
To change the way logging is configured, browse to MANAGEMENT > Logs > Config.
This configuration page is shown in Figure 20-3 You cant see it inf Figure 20-3, but by
se-lecting the Syslog check box, you can point to an external server by entering the address
in the Syslog Server IP Address field
Note: If you do not already have a Syslog server, you can download kiwi from http:/ /www.kiwisyslog.com Kiwi is a free Syslog server that many people use
In addition, from the Syslog Configuration page, you can set the level of logging by changing the facility levels These levels control how much information is captured In general, the larger the facility number, the more information that is recorded; however, this
is not always the case Table 20-2 shows the available facility levels
Key
Topic
Trang 8Table 20-2 Available Facility Levels
Trang 9Figure 20-3 Configuring Syslog
You can locally view the logs by selecting MANAGEMENT > Logs > Message logs The
message logs include information related to the network infrastructure, client issues, au-thentication issues, and AP association issues These have relevance to the controller
Using SNMP
When using SNMP gets/sets, you can obtain information about the status of the controller
and allows you to remotely manage the controller To set up SNMP, go to MANAGEMENT > SNMP > General Here you configure the following parameters, as shown in Figure 20-4:
■ Name
■ Location
■ Contact
■ System Description
■ System Object ID
■ SNMP Port Number
■ Trap Port Number
■ SNMP v1 Mode
■ SNMP v2c Mode
■ SNMP v3 Mode
Trang 10Figure 20-4 SNMP Configuration on Controllers
Configuring the Community Strings
When you set up SNMP, two community names exist by default Public is for read-only access, and Private is for read/write access If you have any involvement in security, you al-ready know that you should change these values They are well-known values that an at-tacker can use to gain control of your controller You can modify the values in the
controller by choosing MANAGEMENT > SNMP > Communities.
You can also set the SNMPv3 users and trap receivers Although it is not covered here, it
is recommended that you use SNMPv3, because it is the most secure method at the mo-ment
To view the SNMP trap logs, go to MANAGEMENT > SNMP > Trap Logs Figure 20-5
shows a sample of the SNMP trap logs
You can use these trap logs to troubleshoot client association failures and AP association failures The trap logs generate a reason code that can point you in the right direction to correct the issue Another way to refine the information you receive is by using the Trap
Controls found at MANAGEMENT > SNMP > Trap Controls Here you can control
what events generate a trap