Interpreting Syslog Messages, Severity Levels, and Facilities

Syslog is a standard protocol for message logging, defined in RFC 5424 (and earlier RFC 3164). It allows network devices (routers, switches, firewalls) to send event messages to a central log server. This centralization is critical for monitoring, troubleshooting, and security auditing. Without syslog, you would have to log into each device individually to check its logs—a nightmare in a network with hundreds of devices. Syslog messages are text-based and include a timestamp, facility code, severity level, hostname, and message text. Cisco IOS devices generate syslog messages for events like interface state changes, configuration changes, authentication failures, and system errors.

Syslog operates over UDP (default port 514) or TCP (port 6514 with TLS). The sender (device) sends messages to a collector (syslog server). The server listens on the configured port and stores logs. The message format per RFC 5424 includes:

Cisco IOS uses a slightly different format (RFC 3164 style) by default, but newer IOS XE supports RFC 5424.

Syslog defines eight severity levels, with 0 being the most critical:

Cisco IOS allows you to filter which messages are logged locally or sent to a server using the logging command with a severity threshold. For example, logging trap 4 sends messages with severity 0-4 to the syslog server.

Facilities identify the source of the message. RFC 5424 defines 23 standard facilities (0-22), but Cisco IOS uses a subset plus local use facilities (16-23). Common facilities:

Cisco IOS uses local0 through local7 for various purposes, such as local7 for debugging. In configuration, you can set the facility using logging facility <facility>.

To view syslog messages locally on a Cisco device:

show logging

Example output:

Syslog logging: enabled (0 messages dropped, 0 messages rate-limited)
    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level debugging, 0 messages logged
    Logging Exception: size (8192) bytes
    Trap logging: level informational, 0 messages logged
    Logging to 192.168.1.100 (udp port 514, audit disabled, link up)

Log Buffer (8192 bytes):

*Mar 15 14:30:00.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down
*Mar 15 14:30:01.456: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down

To configure syslog:

configure terminal
logging host 192.168.1.100
logging trap informational
logging facility local7
logging on
end

Syslog works with SNMP for network management. While SNMP polls device status, syslog provides unsolicited event notifications. NTP is crucial for accurate timestamps in syslog messages. Without NTP, timestamps are unreliable, making correlation difficult. AAA (TACACS+/RADIUS) logs authentication events via syslog. AIOps platforms ingest syslog data to detect anomalies using machine learning.

In a large enterprise network with thousands of devices, syslog is indispensable for security and operations. For example, a network operations center (NOC) uses a centralized syslog server (like Splunk or ELK) to collect logs from all routers, switches, firewalls, and wireless controllers. When an interface goes down, the syslog message is immediately visible to the NOC team, who can start troubleshooting. Without syslog, they would need to manually poll devices via SNMP or SSH.

Another scenario: A security team monitors for authentication failures. Syslog messages from AAA servers (TACACS+ or RADIUS) are sent with facility auth (4) or authpriv (10). The security team filters for severity 3 (Error) or lower to detect brute-force attacks. They correlate timestamps using NTP to trace an attacker's steps across multiple devices.

A common pitfall is misconfiguring severity thresholds. For instance, setting logging trap debugging (level 7) on a busy core router can overwhelm the syslog server with debug messages, causing log loss. Best practice is to use logging trap notifications (level 5) for production and only enable debugging temporarily. Also, ensure the syslog server is reachable and that UDP port 514 is not blocked by firewalls. If the server goes down, messages are lost (UDP is unreliable). Some organizations use TCP for guaranteed delivery, but this can cause backpressure. Finally, always use NTP to synchronize clocks; otherwise, logs from different devices have inconsistent timestamps, making incident reconstruction difficult.