DiagnosticsEXEC

show logging

Displays system logging messages and configuration for Cisco NX-OS devices.

Overview

The 'show logging' command is a fundamental diagnostic tool on Cisco NX-OS devices that displays system log messages stored in the internal buffer. These messages, also known as syslog messages, provide a chronological record of events occurring on the switch, including interface state changes, configuration modifications, authentication attempts, and system errors. The command is essential for troubleshooting network issues, monitoring security events, and verifying system health. In NX-OS, logging is configured per VDC (Virtual Device Context), and the output includes the VDC identifier. The command can be filtered to show only the last N messages, messages from a specific module, or messages of a certain severity level. Understanding how to interpret the output is crucial for network engineers, as it helps identify patterns such as link flapping, routing protocol instability, or unauthorized access attempts. The logging buffer is a circular buffer; when full, the oldest messages are overwritten. Therefore, for long-term monitoring, it is recommended to configure a syslog server. The command is typically used in the initial stages of troubleshooting to gather recent events, and it can be combined with other show commands for a comprehensive analysis.

Syntax·EXEC

show logging [last <number> | startup | logfile | module <module> | vdc <vdc-id> | severity <level> | level <level> | timestamp | sequence-number | tail <number> | grep <expression>]

When to Use This Command

Investigating why a link keeps flapping by reviewing interface state change logs.
Checking for authentication failures during a security audit.
Monitoring system health by reviewing error messages related to hardware or software.
Verifying that logging is correctly configured and messages are being generated.

Parameters

Parameter	Syntax	Required	Description
last	last <number>	Optional	Displays only the last <number> of log messages. Useful for quickly viewing the most recent events without scrolling through the entire buffer.
startup	startup	Optional	Displays log messages from the startup configuration log, which contains messages generated during the boot process.
logfile	logfile	Optional	Displays log messages from a configured logfile, if any. This is used when logging is directed to a file.
module	module <module>	Optional	Displays log messages for a specific hardware module (e.g., module 1). Useful for isolating issues to a particular line card or supervisor.
vdc	vdc <vdc-id>	Optional	Displays log messages for a specific Virtual Device Context. In multi-VDC environments, this filters output to the specified VDC.
severity	severity <level>	Optional	Displays log messages of a specific severity level or higher. Levels range from 0 (emergencies) to 7 (debugging).
level	level <level>	Optional	Synonym for severity; displays messages of a specific severity level or higher.
timestamp	timestamp	Optional	Displays the timestamp format used in log messages. Does not show the messages themselves.
sequence-number	sequence-number	Optional	Displays log messages with sequence numbers, which can help in tracking message order in high-volume environments.
tail	tail <number>	Optional	Similar to 'last', displays the last <number> of log messages. Often used interchangeably.
grep	grep <expression>	Optional	Filters log messages to show only those containing the specified regular expression. Useful for searching for specific patterns like interface names or error codes.

Command Examples

Basic show logging output

show logging

Syslog logging: enabled
Console logging: level warnings, 23 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level informational, 100 messages logged
Logging buffer size: 4096 bytes
Timestamp format: Mon DD YYYY HH:MM:SS

May 15 14:23:45 NX-OS1 %$ VDC-1 %$ %KERN-2-SYSTEM_MSG: kernel: interface Ethernet1/1, link up
May 15 14:23:46 NX-OS1 %$ VDC-1 %$ %KERN-2-SYSTEM_MSG: kernel: interface Ethernet1/1, link down
May 15 14:24:00 NX-OS1 %$ VDC-1 %$ %AUTHPRIV-3-SYSTEM_MSG: sshd[1234]: Failed password for admin from 10.1.1.100 port 22 ssh2

The first lines show logging configuration: syslog is enabled, console logs warnings, monitor logs debugging, buffer logs informational. The buffer size is 4096 bytes. Then log messages appear with timestamp, hostname, VDC, facility, severity, and message. The first message shows link up on Ethernet1/1, the second shows link down, the third shows an SSH authentication failure.

Show logging last 5 messages

show logging last 5

May 15 14:23:45 NX-OS1 %$ VDC-1 %$ %KERN-2-SYSTEM_MSG: kernel: interface Ethernet1/1, link up
May 15 14:23:46 NX-OS1 %$ VDC-1 %$ %KERN-2-SYSTEM_MSG: kernel: interface Ethernet1/1, link down
May 15 14:24:00 NX-OS1 %$ VDC-1 %$ %AUTHPRIV-3-SYSTEM_MSG: sshd[1234]: Failed password for admin from 10.1.1.100 port 22 ssh2
May 15 14:25:10 NX-OS1 %$ VDC-1 %$ %OSPF-5-ADJCHG: Process 100, Nbr 10.1.1.2 on Ethernet1/2 from FULL to DOWN, neighbor down: interface down
May 15 14:25:12 NX-OS1 %$ VDC-1 %$ %OSPF-5-ADJCHG: Process 100, Nbr 10.1.1.2 on Ethernet1/2 from DOWN to FULL, neighbor up: interface up

This shows only the last 5 log messages. The first two indicate link flapping on Ethernet1/1. The third is an SSH authentication failure. The last two show OSPF adjacency changes due to interface state changes.

Understanding the Output

The show logging command output is divided into two sections: configuration summary and log messages. The configuration summary shows whether syslog logging is enabled, and the logging levels for console, monitor, and buffer. It also shows the buffer size and timestamp format. The log messages section lists each message with a timestamp, hostname, VDC, facility code, severity level, and the actual message text. The severity levels range from 0 (emergencies) to 7 (debugging). Healthy values typically show informational (6) or notice (5) messages, while problems often appear as warnings (4), errors (3), critical (2), or alerts (1). For example, repeated link down messages indicate a flapping interface, while authentication failures may indicate a security issue. The buffer size indicates how many bytes of logs are stored; if it's too small, older messages may be overwritten.

Configuration Scenarios

Configuring Syslog Server and Verifying Logging

A network engineer wants to centralize logging from a Nexus switch to a syslog server at 10.1.1.100 for long-term storage and analysis.

Topology

[Nexus Switch] --- Management Network --- [Syslog Server (10.1.1.100)]

Steps

1.Configure the syslog server with the logging server command.
2.Set the logging severity level to informational to capture most events.
3.Verify the configuration using show logging.

Configuration

! Enter configuration mode
configure terminal
! Configure syslog server
logging server 10.1.1.100 5 use-vrf management
! Set logging level to informational (6)
logging level 6
! Exit and save
end
copy running-config startup-config

Verify: Use 'show logging' to confirm that syslog logging is enabled and the server is listed. Also check that messages are being sent by viewing the syslog server logs.

Watch out: Ensure the VRF (management) is correctly specified; otherwise, the syslog server may be unreachable.

Troubleshooting with This Command

When troubleshooting network issues on Cisco NX-OS, 'show logging' is often the first command to run. It provides a timeline of events that can help correlate symptoms with root causes. For example, if users report intermittent connectivity, check for interface flapping messages like 'link up/down'. Repeated messages indicate a physical layer issue, such as a faulty cable or SFP. If OSPF neighbors are dropping, look for adjacency change messages and correlate them with interface state changes. Security incidents often leave traces in the logs, such as 'Failed password' for SSH or 'authentication failure' for AAA. The severity level helps prioritize: messages with severity 0-2 (emergency, alert, critical) indicate serious problems requiring immediate attention, while severity 3-4 (error, warning) indicate issues that may need investigation. Severity 5-7 (notice, informational, debug) are for normal events or detailed troubleshooting. Use the 'last' parameter to focus on recent events, and 'grep' to filter for specific interfaces or error codes. If the buffer is full, consider increasing its size with 'logging size <bytes>' or exporting logs to a syslog server. In multi-VDC environments, ensure you are viewing logs from the correct VDC by using the 'vdc' parameter. Remember that logs are lost on reload unless saved to a logfile or syslog server. For persistent issues, configure logging to a server and monitor trends over time.

CCNA Exam Tips

Remember that the severity levels in NX-OS are 0-7, with 0 being most severe.

Know that 'show logging last <n>' is useful for quickly viewing recent events without scrolling.

Be aware that NX-OS uses VDC (Virtual Device Context) in the log format, which is unique compared to IOS.

Common Mistakes

Confusing severity levels: e.g., thinking 0 is low severity when it's the highest.

Forgetting that the buffer size is limited; logs may be lost if not exported to a syslog server.

Assuming 'show logging' shows real-time logs; it shows the buffer, not live streaming.

Platform Notes

On Cisco NX-OS, the 'show logging' command includes VDC information in the log format, which is not present in classic IOS. The severity levels are the same (0-7), but NX-OS uses a different facility code format (e.g., %KERN, %AUTHPRIV). In IOS, the command is similar but lacks VDC support and may have different filtering options. For example, IOS uses 'show logging | include' instead of 'grep'. On Nexus, the 'logging server' command requires specifying a VRF, whereas IOS assumes the global routing table. Additionally, NX-OS supports module-specific logging, which is useful for modular chassis. The buffer size on Nexus defaults to 4096 bytes but can be increased up to 1 MB. In IOS, the default is often larger. For equivalent functionality on other platforms, such as Arista EOS, the command is 'show logging' with similar options, but the output format differs. On Juniper Junos, the equivalent is 'show log messages'. Understanding these differences is important for multi-vendor environments.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions