Describe the Use of Syslog Features Including Facilities and Levels

Imagine trying to run a hospital without any patient charts — no record of symptoms, treatments, or events. You would have no way to diagnose recurring problems or prove what happened after the fact. Networks face the same challenge: routers, switches, firewalls, and servers generate constant events — interface flaps, failed logins, configuration changes, hardware errors — and without a system to record them, troubleshooting becomes guesswork.

Syslog is the standard protocol used across nearly every network device and operating system to generate, categorize, and centrally collect these event messages. This article explains syslog from first principles — especially its facilities and severity levels — and shows you how to configure, verify, and use it in real environments.

What Is Syslog, Fundamentally?

Syslog is a simple, standardized way for a device to say: “Something happened, here’s what, here’s how serious it is, and here’s when.” Each syslog message has three key parts:

1. Facility — what part/subsystem of the system generated the message (e.g., kernel, mail system, local application).
2. Severity Level — how serious the event is (from purely informational to catastrophic).
3. Message Text — the human-readable description of the event.

Syslog messages can be:

• Displayed on the local console.
• Stored in a local logging buffer (memory).
• Sent to a remote syslog server for centralized collection, long-term storage, and analysis.

Syslog Severity Levels

Severity levels range from 0 (most severe) to 7 (least severe, purely informational). This is one of the most commonly tested and used pieces of syslog knowledge.

A helpful memory trick: “Every Awesome Cisco Engineer Will Need Icecream Daily” — Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug.

Important concept: When you configure a device to log at a certain severity level, it logs that level and everything more severe (lower-numbered). For example, setting logging to level 4 (Warning) captures levels 0 through 4 — Emergency, Alert, Critical, Error, and Warning — but not Notice, Informational, or Debug.

Syslog Facilities

The facility identifies which subsystem or process generated the message. This matters most in Unix/Linux systems and multi-vendor environments where many different types of devices send logs to the same central server, and you need to sort messages by source type.

Cisco devices, by default, typically use local7 as their facility when sending to an external syslog server, though this is configurable.

Anatomy of a Cisco Syslog Message

%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

Breaking this down:

• LINK — the facility (subsystem that generated this, related to the link/interface layer).
• 3 — the severity level (Error).
• UPDOWN — the mnemonic, a short code describing the event type.
• The rest — the human-readable message.

flowchart LR
    A[Event Occurs on Device
e.g. Interface Down] --> B[Syslog Message Generated
Facility + Severity + Text]
    B --> C{Logging Destination}
    C --> D[Console]
    C --> E[Local Buffer - RAM]
    C --> F[Remote Syslog Server]
    F --> G[Centralized Log Analysis
SIEM / Splunk / Graylog]

Configuring Syslog on a Cisco Router

Step 1: Enable Timestamps (Critical for Correlating Events)

Router(config)# service timestamps log datetime msec localtime show-timezone

Router(config)# service timestamps log datetime msec localtime show-timezone

Without timestamps, log messages are nearly useless for troubleshooting timing-related issues.

Step 2: Set the Logging Trap Level (What Gets Sent to Remote Server)

Router(config)# logging trap warnings

Router(config)# logging trap warnings

This sends severity 0 through 4 (Emergency through Warning) to the remote syslog server.

Step 3: Configure the Remote Syslog Server Destination

Router(config)# logging host 10.1.1.50
Router(config)# logging source-interface Loopback0
Router(config)# logging facility local7

Router(config)# logging host 10.1.1.50
Router(config)# logging source-interface Loopback0
Router(config)# logging facility local7

logging source-interface ensures the syslog messages always originate from a consistent, predictable IP address (useful for filtering on the syslog server side), even if the router has multiple interfaces.

Step 4: Configure Local Buffered Logging

Router(config)# logging buffered 16384 informational

Router(config)# logging buffered 16384 informational

This keeps the last 16KB of log messages (severity 6 and more severe) in router memory, viewable even without a remote server.

Step 5: Disable Console Logging Interruptions (Optional, for Busy Networks)

Router(config)# no logging console

Router(config)# no logging console

On heavily-loaded devices, constant console logging can actually slow down CLI responsiveness; many production environments disable console logging and rely on buffered + remote logging instead.

Verifying Syslog Configuration

Router# show logging

Router# show logging

Sample output:

Syslog logging: enabled (0 messages dropped, ...)
    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level informational, 45 messages logged
    Logging to 10.1.1.50, 45 message lines logged

Syslog logging: enabled (0 messages dropped, ...)
    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level informational, 45 messages logged
    Logging to 10.1.1.50, 45 message lines logged

Other useful verification commands:

Router# show logging | include %LINK
Router# show run | section logging
Router# terminal monitor    (shows log messages on an SSH/Telnet session, not just console)

Router# show logging | include %LINK
Router# show run | section logging
Router# terminal monitor    (shows log messages on an SSH/Telnet session, not just console)

Setting Up a Central Syslog Server on Linux (rsyslog)

Most Linux distributions ship with rsyslog.

sudo apt install rsyslog -y
sudo nano /etc/rsyslog.conf

sudo apt install rsyslog -y
sudo nano /etc/rsyslog.conf

Enable UDP/TCP reception:

module(load="imudp")
input(type="imudp" port="514")

module(load="imtcp")
input(type="imtcp" port="514")

module(load="imudp")
input(type="imudp" port="514")

module(load="imtcp")
input(type="imtcp" port="514")

Create a template to store network device logs in a separate file, organized by source IP:

$template RemoteLogs,"/var/log/network/%HOSTNAME%.log"
*.* ?RemoteLogs

$template RemoteLogs,"/var/log/network/%HOSTNAME%.log"
*.* ?RemoteLogs

sudo mkdir -p /var/log/network
sudo systemctl restart rsyslog
sudo systemctl status rsyslog

sudo mkdir -p /var/log/network
sudo systemctl restart rsyslog
sudo systemctl status rsyslog

Verify logs arriving from the router:

sudo tail -f /var/log/network/R1.log

sudo tail -f /var/log/network/R1.log

Filtering Syslog Messages with Python

Once logs accumulate on a central server, engineers often need to parse and filter them programmatically — for example, to alert only on Critical-or-worse events.

import re

SEVERITY_NAMES = {
    0: "Emergency", 1: "Alert", 2: "Critical", 3: "Error",
    4: "Warning", 5: "Notice", 6: "Informational", 7: "Debug"
}

log_line = "<187>Jul 24 10:15:32 R1 %LINK-3-UPDOWN: Interface Gi0/1, changed state to down"

def parse_severity(line):
    match = re.search(r"-(\d)-", line)
    if match:
        level = int(match.group(1))
        return level, SEVERITY_NAMES.get(level, "Unknown")
    return None, None

level, name = parse_severity(log_line)
print(f"Severity {level}: {name}")

if level is not None and level <= 3:
    print("ALERT: This event requires immediate attention!")

import re

SEVERITY_NAMES = {
    0: "Emergency", 1: "Alert", 2: "Critical", 3: "Error",
    4: "Warning", 5: "Notice", 6: "Informational", 7: "Debug"
}

log_line = "<187>Jul 24 10:15:32 R1 %LINK-3-UPDOWN: Interface Gi0/1, changed state to down"

def parse_severity(line):
    match = re.search(r"-(\d)-", line)
    if match:
        level = int(match.group(1))
        return level, SEVERITY_NAMES.get(level, "Unknown")
    return None, None

level, name = parse_severity(log_line)
print(f"Severity {level}: {name}")

if level is not None and level <= 3:
    print("ALERT: This event requires immediate attention!")

Output:

Severity 3: Error
ALERT: This event requires immediate attention!

Severity 3: Error
ALERT: This event requires immediate attention!

This kind of script is the basis for simple log-monitoring automation, often expanded later into full SIEM integrations.

Comparison Table: Local vs Remote Logging

Best Practices

• Always configure timestamps with millisecond precision — essential for correlating events across multiple devices.
• Send logs to a centralized syslog server rather than relying on local buffers, which are lost on reboot.
• Set an appropriate trap level — too low (e.g., Debug) floods the server with noise; too high misses important events. Informational or Warning is a common production setting.
• Use logging source-interface with a stable Loopback address so filtering by source is consistent.
• Regularly review logs for repeated warnings — they often predict a future outage (e.g., repeated CRC errors before a link fails completely).
• Protect the syslog server itself — logs often contain sensitive operational data.
• Consider syslog over TLS (secure syslog) in environments where log data could be intercepted.

Troubleshooting

Real-World Example: Enterprise Logging Policy

A mid-sized company standardizes on the following logging policy across all Cisco devices:

service timestamps log datetime msec localtime show-timezone
logging buffered 32768 informational
logging trap warnings
logging host 10.1.1.50
logging source-interface Loopback0
logging facility local7
no logging console

service timestamps log datetime msec localtime show-timezone
logging buffered 32768 informational
logging trap warnings
logging host 10.1.1.50
logging source-interface Loopback0
logging facility local7
no logging console

All logs converge on a central rsyslog server, which forwards Critical-and-above events into an alerting system (e.g., email or Slack notification) using a script similar to the Python example above — giving the NOC (Network Operations Center) real-time visibility into failures across the entire infrastructure.

Conclusion

Syslog is the nervous system of network monitoring — without it, engineers are blind to what’s actually happening across their infrastructure. Understanding severity levels (0–7) tells you how urgent an event is, while facilities help categorize where a message came from, especially in mixed-vendor environments. Combined with centralized collection via tools like rsyslog, syslog transforms scattered device logs into a searchable, correlatable record that is essential for both day-to-day troubleshooting and long-term security auditing.

References

1. RFC 5424 – The Syslog Protocol — https://datatracker.ietf.org/doc/html/rfc5424
2. Cisco Troubleshooting and Logging Guide — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/netmgmt/configuration/xe-16/nm-xe-16-book/nm-syslog-xe.html
3. rsyslog Documentation — https://www.rsyslog.com/doc/
4. Cisco System Message Guide — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/system/messages/guide/sm_book.html
5. RFC 3164 – The BSD Syslog Protocol — https://datatracker.ietf.org/doc/html/rfc3164