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.
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.
For more information about system messages and trap logs, see http://www.cisco.com/c/en/us/support/wireless/wireless-lan-controller-software/products-system-message-guides-list.html.
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. |
Step 1 | Enable system logging and set
the IP address of the syslog server to which to send the syslog messages by
entering this command:
config logging syslog host server_IP_address You can add up to three syslog servers to the controller.
| ||||
Step 2 | Set the severity level for
filtering syslog messages to the syslog server by entering this command:
config logging syslog level severity_level where severity_level is one of the following:
| ||||
Step 3 | Set the severity
level for filtering syslog messages for a particular access point or for all
access points by entering this command:
config ap logging syslog level severity_level {Cisco_AP | all} where severity_level is one of the following:
| ||||
Step 4 | Set the facility
for outgoing syslog messages to the syslog server by entering this command:
config logging syslog facility facility-code where facility-code is one of the following:
| ||||
Step 5 | Configure the syslog facility for AP using the following command:
config logging syslog facility AP where AP can be: | ||||
Step 6 | Configure the syslog facility for an AP or all APs by entering this command:
config ap logging syslog facility facility-level {Cisco_AP | all} where facility-level is one of the following:
| ||||
Step 7 | Configure the syslog facility for Client by entering this command:
config logging syslog facility Client where facility-code can be:
| ||||
Step 8 | Set the severity
level for logging messages to the controller buffer and console, enter these
commands:
where severity_level is one of the following:
| ||||
Step 9 | Save debug messages to the controller buffer, the controller console, or a syslog server by entering these commands: | ||||
Step 10 | To cause the controller to include information about the source file in the message logs or to prevent the controller from displaying this information by entering this command: | ||||
Step 11 | Configure the controller to include process information in the message logs or to prevent the controller from displaying this information by entering this command: | ||||
Step 12 | Configure the controller to include traceback information in the message logs or to prevent the controller from displaying this information by entering this command: | ||||
Step 13 | Enable or disable timestamps in log messages and debug messages by entering these commands: | ||||
Step 14 | Save your changes by entering this command: |
To see the logging parameters and buffer contents, enter this command:
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:
To see the contents of the event log file for an access point that is joined to the controller, enter this command:
Information similar to the following appears:
AP event log download has been initiated Waiting for download to complete AP event log download completed. ======================= AP Event log Contents ===================== *Sep 22 11:44:00.573: %CAPWAP-5-CHANGED: CAPWAP changed state to IMAGE *Sep 22 11:44:01.514: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down *Sep 22 11:44:01.519: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to down *Sep 22 11:44:53.539: *** Access point reloading. Reason: NEW IMAGE DOWNLOAD *** *Mar 1 00:00:39.078: %CAPWAP-3-ERRORLOG: Did not get log server settings from DHCP. *Mar 1 00:00:42.142: %CDP_PD-4-POWER_OK: Full power - NEGOTIATED inline power source *Mar 1 00:00:42.151: %LINK-3-UPDOWN: Interface Dot11Radio1, changed state to up *Mar 1 00:00:42.158: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up *Mar 1 00:00:43.143: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to up *Mar 1 00:00:43.151: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up *Mar 1 00:00:48.078: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-CAPWAP-CONTROLLER *Mar 1 00:01:42.144: %CDP_PD-4-POWER_OK: Full power - NEGOTIATED inline power source *Mar 1 00:01:48.121: %CAPWAP-3-CLIENTERRORLOG: Set Transport Address: no more AP manager IP addresses remain *Mar 1 00:01:48.122: %CAPWAP-5-CHANGED: CAPWAP changed state to JOIN *Mar 1 00:01:48.122: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to administratively down *Mar 1 00:01:48.122: %LINK-5-CHANGED: Interface Dot11Radio1, changed state to administratively down
To delete the existing event log and create an empty event log file for a specific access point or for all access points joined to the controller, enter this command:
Using the Debug Facility
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:
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:
| ||||
Step 2 | 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. | ||||
Step 3 | To determine why packets might not be displayed, enter this command: debug packet error {enable | disable} | ||||
Step 4 | To display the status of packet debugging, enter this command:
Information similar to the following appears: Status........................................... disabled Number of packets to display..................... 25 Bytes/packet to display.......................... 0 Packet display format............................ text2pcap Driver ACL: [1]: disabled [2]: disabled [3]: disabled [4]: disabled [5]: disabled [6]: disabled Ethernet ACL: [1]: disabled [2]: disabled [3]: disabled [4]: disabled [5]: disabled [6]: disabled IP ACL: [1]: disabled [2]: disabled [3]: disabled [4]: disabled [5]: disabled [6]: disabled EoIP-Ethernet ACL: [1]: disabled [2]: disabled [3]: disabled [4]: disabled [5]: disabled [6]: disabled EoIP-IP ACL: [1]: disabled [2]: disabled [3]: disabled [4]: disabled [5]: disabled [6]: disabled LWAPP-Dot11 ACL: [1]: disabled [2]: disabled [3]: disabled [4]: disabled [5]: disabled [6]: disabled LWAPP-IP ACL: [1]: disabled [2]: disabled [3]: disabled [4]: disabled [5]: disabled [6]: disabled? |