show logging
Displays the state of system logging (syslog) on the device, including buffer contents, logging configuration, and statistics, used for troubleshooting and monitoring system events.
Definition: show logging is a Cisco IOS privileged exec command. Displays the state of system logging (syslog) on the device, including buffer contents, logging configuration, and statistics, used for troubleshooting and monitoring system events.
Overview
The `show logging` command is a fundamental diagnostic tool in Cisco IOS that displays the current state of system logging (syslog) on the device. It reveals the contents of the logging buffer, the configured logging destinations (console, monitor, buffer, syslog server), and detailed statistics about logged messages. This command is essential for network engineers monitoring system events, troubleshooting issues, and auditing device behavior.
The underlying concept is syslog, a standard protocol for message logging that separates the generation of log messages from their storage and analysis. In Cisco IOS, syslog messages are categorized by severity (0-7, where 0 is emergency and 7 is debugging) and facility (e.g., local7, OSPF, RIP). The `show logging` command provides a snapshot of the logging subsystem, including the buffer contents (if configured), which is a circular memory region that stores recent log messages.
This is particularly useful when you need to review events that occurred before a problem was noticed, as the buffer retains messages even if no syslog server is configured. You would reach for this command over alternatives like `show log` (which is a different command on some platforms) or `debug` commands when you need a historical view of system events without the overhead of real-time debugging. It fits into the troubleshooting workflow as an initial step to gather information about system events, often used after noticing an anomaly or before enabling more detailed debugging.
Important IOS behavior: the output is privileged EXEC (enable mode) only; the buffer contents are lost on reload unless configured to be saved to NVRAM (via `logging persistent`); the command does not affect the running configuration. The output includes the logging enable state, buffer size, console logging level, monitor logging level, buffer logging level, trap logging level (for syslog servers), and the actual log entries with timestamps if configured. This command is invaluable for correlating events with network issues, such as interface flaps, routing protocol changes, or security violations.
show loggingWhen to Use This Command
- Review recent system messages to diagnose a network issue after a crash or unexpected behavior.
- Verify that logging is enabled and configured correctly (e.g., buffer size, syslog server).
- Check the timestamp and severity of logged events to correlate with network incidents.
- Monitor for specific error messages (e.g., interface flapping, authentication failures).
Command Examples
Basic show logging output
show loggingSyslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 100 messages logged
Trap logging: level informational, 5 message lines logged
Log Buffer (10000 bytes):
*Mar 1 00:00:34.123: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:01:02.456: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*Mar 1 00:01:03.789: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
*Mar 1 00:02:15.321: %SYS-5-RESTART: System restarted --
*Mar 1 00:02:15.321: Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.7(3)M, RELEASE SOFTWARE (fc2)
*Mar 1 00:02:15.321: Copyright (c) 1986-2016 by Cisco Systems, Inc.
*Mar 1 00:02:15.321: Compiled Thu 22-Dec-16 15:32 by prod_rel_teamFirst line shows syslog is enabled with no dropped messages. Console and monitor logging are disabled. Buffer logging is set to debugging level with 100 messages logged. Trap logging (to syslog server) is informational level with 5 messages. The log buffer shows recent messages: configuration change, interface up/down, and system restart with IOS version.
Show logging with syslog server configured
show loggingSyslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns)
Console logging: level debugging, 37 messages logged
Monitor logging: level debugging, 37 messages logged
Buffer logging: level debugging, 37 messages logged
Trap logging: level informational, 37 message lines logged
Logging to 192.168.1.100 (udp port 514, audit disabled, link up),
2 message lines logged, 0 message lines rate-limited,
0 message lines dropped by MD, xml disabled, sequence number disabled
filtering disabled
Logging to 192.168.1.101 (udp port 514, audit disabled, link up),
0 message lines logged, 0 message lines rate-limited,
0 message lines dropped by MD, xml disabled, sequence number disabled
filtering disabled
Log Buffer (10000 bytes):
*Mar 1 00:05:23.456: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:06:10.789: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down
*Mar 1 00:06:11.012: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to downThis output shows logging is enabled with console and monitor logging at debugging level. Trap logging is informational and messages are being sent to two syslog servers: 192.168.1.100 (2 messages logged) and 192.168.1.101 (0 messages). The buffer shows recent events including an interface going down.
Understanding the Output
The 'show logging' command output is divided into two main sections: logging configuration and log buffer contents. The first section shows whether syslog is enabled, any dropped/rate-limited messages, and the logging levels for console, monitor, buffer, and trap (syslog server) destinations. 'Level debugging' means all messages from severity 0-7 are logged; 'level informational' means only messages 0-6.
The trap logging section lists configured syslog servers with IP, port, link status, and message counts. The log buffer displays recent syslog messages with timestamps, facility code, severity, mnemonic, and description. Key fields: %FACILITY-SEVERITY-MNEMONIC: description.
Severity 0=emergency, 1=alert, 2=critical, 3=error, 4=warning, 5=notice, 6=informational, 7=debug. Watch for high severity messages (0-3) indicating problems. A large number of dropped messages may indicate buffer overflow or rate limiting.
Configuration Scenarios
Configure Syslog Server and Verify Logging
A network administrator needs to send system logs to a central syslog server at 192.168.1.100 for monitoring and compliance. After configuration, they use `show logging` to verify that messages are being sent and to check the buffer contents.
Topology
R1(Gi0/0)---192.168.1.0/24---(eth0) Syslog ServerSteps
- 1.Step 1: Enter global configuration mode: R1> enable, R1# configure terminal
- 2.Step 2: Enable logging to the buffer: R1(config)# logging buffered 16384
- 3.Step 3: Set the logging severity level for syslog server: R1(config)# logging trap informational
- 4.Step 4: Specify the syslog server IP: R1(config)# logging 192.168.1.100
- 5.Step 5: Optionally, set the logging source interface: R1(config)# logging source-interface GigabitEthernet0/0
- 6.Step 6: Exit configuration mode and verify: R1(config)# end, R1# show logging
! R1(config)# logging buffered 16384 R1(config)# logging trap informational R1(config)# logging 192.168.1.100 R1(config)# logging source-interface GigabitEthernet0/0 !
Verify: R1# show logging Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, small buffer) Buffer logging: level informational, 16384 bytes allocated (0 messages logged) Console logging: level debugging, 0 messages logged Monitor logging: level debugging, 0 messages logged Trap logging: level informational, 0 messages logged Logging to 192.168.1.100 (udp port 514, audit disabled, link up) 0 messages logged, 0 message lines logged 0 messages rate-limited Logging Source Interface: GigabitEthernet0/0 Log Buffer (0 messages):
Watch out: A common mistake is forgetting to enable logging globally with `logging on` (though it is on by default). Also, ensure the syslog server is reachable and that UDP port 514 is not blocked by ACLs or firewalls.
Troubleshoot Interface Flap Using Logging Buffer
An engineer notices intermittent connectivity issues on interface GigabitEthernet0/1. They want to review recent log messages to see if the interface has been flapping (going up/down). The logging buffer is configured to capture messages at severity 'debugging' to include all events.
Topology
R1(Gi0/1)---10.0.0.0/30---(Gi0/0)R2Steps
- 1.Step 1: Ensure logging buffer is enabled with sufficient size: R1# configure terminal, R1(config)# logging buffered 32768 debugging
- 2.Step 2: Clear the buffer to start fresh: R1# clear logging
- 3.Step 3: Reproduce the issue (e.g., wait for the interface to flap or simulate by shutting/no shut)
- 4.Step 4: Display the logging buffer: R1# show logging
- 5.Step 5: Look for messages like '%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down' and '%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down'
! R1(config)# logging buffered 32768 debugging !
Verify: R1# show logging ... Log Buffer (32768 bytes): *Mar 1 00:05:23.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down *Mar 1 00:05:24.124: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down *Mar 1 00:05:30.456: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up *Mar 1 00:05:31.457: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
Watch out: If the buffer size is too small, older messages are overwritten. Use `clear logging` to reset the buffer before reproducing the issue. Also, ensure the timestamp is enabled with `service timestamps log datetime msec` for precise timing.
Troubleshooting with This Command
When using `show logging` for troubleshooting, the first step is to understand what healthy output looks like. A healthy system will show logging enabled, with appropriate buffer size and logging levels set according to operational needs. The buffer should contain messages that are relevant to recent events, with no excessive dropped messages or rate-limited entries.
Key fields to focus on include: 'Syslog logging: enabled' (if disabled, no messages are logged), 'Buffer logging: level <level>' (should be at least 'informational' for general troubleshooting), 'Console logging: level <level>' (typically 'debugging' during active troubleshooting but should be set lower in production to avoid console flooding), 'Trap logging: level <level>' (for syslog servers), and the actual log entries. Problem indicators include: '0 messages logged' in the buffer when you expect messages (check buffer size and logging level), 'messages dropped' or 'messages rate-limited' (indicates the device is overwhelmed or logging is misconfigured), 'logging to <IP> ... link down' (syslog server unreachable), or buffer overflow messages. Common symptoms this command helps diagnose include: interface flaps (look for %LINK-3-UPDOWN and %LINEPROTO-5-UPDOWN messages), routing protocol adjacency changes (e.g., %OSPF-5-ADJCHG), security violations (e.g., %SEC-6-IPACCESSLOGP), and system crashes (e.g., %SYS-3-CPUHOG).
A step-by-step diagnostic flow: 1) Check if logging is enabled; if not, enable it. 2) Verify the buffer size and logging level; increase buffer size if messages are being overwritten. 3) Look for timestamps to correlate events with other logs. 4) Search for specific patterns using `show logging | include <pattern>`. 5) If using a syslog server, verify connectivity and that messages are being sent. 6) Correlate with other show commands: for interface flaps, use `show interfaces` and `show interface <interface> | include line protocol`; for routing issues, use `show ip ospf neighbor` or `show ip bgp summary`. Debug commands like `debug ip ospf events` can provide real-time detail but should be used cautiously. The `show logging` command is often the first step before enabling debugs, as it provides a historical record without the performance impact.
CCNA Exam Tips
Remember that 'show logging' displays both configuration and buffer; the buffer is circular and overwrites oldest messages.
Know that severity levels are 0-7, with 0 being most severe; 'debugging' includes all levels, 'informational' includes 0-6.
The command is useful for verifying syslog server reachability and message delivery; exam may ask how to check if logging to a server is working.
Be aware that 'show logging' output includes timestamps; if timestamps are not visible, check 'service timestamps' configuration.
Common Mistakes
Confusing 'show logging' with 'show log' (which does not exist); the correct command is 'show logging'.
Assuming that enabling logging globally automatically sends messages to a syslog server; you must also configure 'logging <ip>'.
Overlooking that the log buffer size is limited; if not configured, default is 4096 bytes, which may overwrite important messages quickly.
show logging vs logging host [ip]
The 'show logging' and 'logging host [ip]' commands are often confused because both are integral to syslog management on Cisco IOS devices, yet they serve opposing roles: one displays logging configuration and buffer contents, while the other directs syslog messages to a remote server. Understanding their distinct purposes is crucial for effective logging and troubleshooting.
| Aspect | show logging | logging host [ip] |
|---|---|---|
| Scope | Views logging state and buffer | Configures remote syslog server |
| Configuration mode | Privileged EXEC | Global configuration |
| Persistence | Non‑persistent (live output) | Persistent in running-config; can be written to startup-config |
| Precedence | No effect on logging behavior | Enables syslog forwarding to the specified server |
| Typical use | Troubleshooting and monitoring current syslog activity | Centralizing logs for long‑term analysis or compliance |
Use show logging when you need to inspect the local syslog buffer, verify logging configuration, or check statistics such as messages logged and dropped.
Use logging host [ip] when you want to forward syslog messages to a centralized log server for archival, alerting, or multi‑device correlation.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches, ISR 4000 series), the `show logging` command syntax and output are very similar to classic IOS, but there are some differences. IOS-XE uses a Linux-based kernel and may include additional fields like 'Logging to: syslogd' or 'Logging to: internal buffer'. The buffer size can be configured in bytes or with the `logging buffered <size>` command, but on some IOS-XE platforms, the buffer is allocated from system memory and may have a maximum limit.
The NX-OS equivalent command is `show logging logfile` or `show logging last <number>` to display recent messages; NX-OS also has `show logging info` for configuration. On ASA firewalls, the command is `show logging` as well, but the output includes fields like 'Syslog logging: enabled' and 'Console logging: level', and the buffer is called 'logging buffer'. ASA also supports `show logging | grep <pattern>`.
In IOS-XR, the equivalent is `show logging` or `show logging last <number>`, but the output format is different, and logging is managed via the syslogd process. For IOS versions, there are minor differences: in 12.x, the buffer size is often limited to 4096 bytes by default; in 15.x and 16.x, default buffer sizes are larger (e.g., 4096 or 8192). The `logging persistent` command (to save buffer to NVRAM) was introduced in later 15.x versions.
Always check the specific platform documentation for exact syntax and capabilities.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions