Courseiva
SystemPrivileged EXEC

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.

Syntax·Privileged EXEC
show logging

When 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 logging
Syslog 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_team

First 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 logging
Syslog 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 down

This 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 Server

Steps

  1. 1.Step 1: Enter global configuration mode: R1> enable, R1# configure terminal
  2. 2.Step 2: Enable logging to the buffer: R1(config)# logging buffered 16384
  3. 3.Step 3: Set the logging severity level for syslog server: R1(config)# logging trap informational
  4. 4.Step 4: Specify the syslog server IP: R1(config)# logging 192.168.1.100
  5. 5.Step 5: Optionally, set the logging source interface: R1(config)# logging source-interface GigabitEthernet0/0
  6. 6.Step 6: Exit configuration mode and verify: R1(config)# end, R1# show logging
Configuration
!
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)R2

Steps

  1. 1.Step 1: Ensure logging buffer is enabled with sufficient size: R1# configure terminal, R1(config)# logging buffered 32768 debugging
  2. 2.Step 2: Clear the buffer to start fresh: R1# clear logging
  3. 3.Step 3: Reproduce the issue (e.g., wait for the interface to flap or simulate by shutting/no shut)
  4. 4.Step 4: Display the logging buffer: R1# show logging
  5. 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'
Configuration
!
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

1.

Remember that 'show logging' displays both configuration and buffer; the buffer is circular and overwrites oldest messages.

2.

Know that severity levels are 0-7, with 0 being most severe; 'debugging' includes all levels, 'informational' includes 0-6.

3.

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.

4.

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.

Aspectshow logginglogging host [ip]
ScopeViews logging state and bufferConfigures remote syslog server
Configuration modePrivileged EXECGlobal configuration
PersistenceNon‑persistent (live output)Persistent in running-config; can be written to startup-config
PrecedenceNo effect on logging behaviorEnables syslog forwarding to the specified server
Typical useTroubleshooting and monitoring current syslog activityCentralizing 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