Syslog
Introduction to system logging
Network devices constantly monitor their operating status and generate messages when important events occur. Syslog provides a standardized way to collect, store, and manage these messages. For network administrators, syslog is a core tool for monitoring network health, troubleshooting problems, and maintaining reliable performance.
Syslog also acts as a communication channel between network devices and administrators. When something noteworthy happens - anything from a routine status update to a critical failure - Cisco IOS generates messages to describe the event. These messages can be simple informational notices (such as configuration changes) or urgent alerts (such as hardware failures or security-related events).
Understanding syslog message delivery
Cisco IOS supports several ways to deliver log messages, depending on how quickly you need to see them and how long you need to keep them. A device can:
- Display messages in real time to logged-in users
- Store messages locally for later review
- Send messages to a centralized server for long-term storage and analysis
Real-time message delivery
For users connected through the console port, IOS displays log messages by default. This happens because the default logging console setting sends messages to the console session.
Users connected through SSH or Telnet need two steps before messages will appear on their screen.
First, enable monitoring in Global Configuration mode:
Second, each remote user must enable message display for their own session in Privileged EXEC mode:
This approach lets each remote user decide whether they want to see log messages during their session, which can be helpful when messages would interrupt other work.
Message storage options
Real-time messages are useful for immediate awareness, but most organizations also need a record of events. Cisco IOS provides two main storage options: local buffered logging and remote syslog server logging.
Buffered logging stores messages in the device’s RAM using the logging buffered command (enabled by default). You can view buffered messages later with the show logging command. Keep these limitations in mind:
- Buffered logs use device memory.
- Buffered logs are lost when the device restarts.
Syslog server logging avoids those limitations by sending messages to a syslog server using UDP (port 514). Use this command to specify the server:
Centralized syslog servers are useful because they:
- Preserve logs across device reboots
- Collect logs from many devices in one place
- Provide tools for searching, filtering, and analyzing events during troubleshooting
Syslog message structure and components
Each syslog message follows a standard format with fields that are easy for systems to process and text that’s easy for humans to read. Here’s an example:
Here’s what each part means:
-
Timestamp: Indicates when the event occurred (optional, but enabled by default)
For example:
-
Facility: Identifies the system component that generated the message
For example:
-
Severity Level: Indicates the importance of the event
For example:
-
Mnemonic: Provides a short identifier for the message type
For example:
-
Description: Explains the event in detail
For example:
You can adjust the message format to fit your operational needs. For example, you can enable sequence numbers with service sequence-numbers, or you can disable timestamps with no service timestamps. These options can make logs easier to track and read, depending on how you collect and review them.
Syslog severity levels
Syslog uses eight severity levels to describe how important a message is. Levels are numbered 0 through 7, and lower numbers mean more critical events. Knowing these levels helps you decide which messages should be displayed, stored, or forwarded.
Severity level table
| Level | Number | Description | Use Case |
|---|---|---|---|
| Emergency | 0 | System is unusable | Complete system failure |
| Alert | 1 | Immediate action needed | Critical component failure requiring immediate attention |
| Critical | 2 | Critical conditions | Hard drive errors, backup system failures |
| Error | 3 | Error conditions | Interface down, routing protocol errors |
| Warning | 4 | Warning conditions | Configuration warnings, resource utilization warnings |
| Notice | 5 | Normal but significant | Interface state changes, protocol up/down events |
| Informational | 6 | Informational messages | Normal operations, configuration confirmations |
| Debug | 7 | Debug-level messages | Detailed troubleshooting information |
Syslog facilities
Facilities identify which subsystem or process generated a log message. Cisco IOS uses facility codes to group messages by their source. Common facilities include:
| Facility | Description |
|---|---|
| LINEPROTO | Line protocol events |
| SYS | General system messages |
| LINK | Physical link status changes |
| OSPF | OSPF routing protocol events |
| BGP | BGP routing protocol events |
| SNMP | SNMP-related messages |
| SEC | Security-related messages |
| IF | Interface events |
Facilities make troubleshooting faster because you can filter and focus on messages from the subsystem you’re investigating.
Configuring syslog services
Logging configuration controls where messages go and which severity levels are included. The basic pattern is logging [service] [level]:
- service is the destination (console, monitor, buffered, host, trap)
- level is the highest severity number you want to include (and the device also includes all more critical levels with lower numbers)
Key configuration commands include:
- logging console [level]: Controls console message delivery
- logging monitor [level]: Controls terminal (vty line) session delivery
- logging buffered [level]: Controls local RAM storage
- logging host [ip address]: Specifies syslog server destination
- logging trap [level]: Controls syslog server message levels
The show logging command displays the current logging configuration and recent buffered messages, giving you a quick view of how logging is set up and what the device has recorded.
Debug messages and operational considerations
Debug messages (severity 7) are different from most other syslog messages. The debug command turns on detailed monitoring for specific processes and can generate a continuous stream of output. Because debug output can consume significant CPU resources, it should be used carefully on production devices.
Once enabled, debug stays active until you disable it with the no debug command. It can continue generating messages even after the user who enabled it logs out, so it’s important to turn it off when you’re done to avoid unnecessary performance impact.