Learning Objectives
- Explain the role of syslog in centralized network logging
- Identify the eight syslog severity levels
- Understand syslog facility codes and message format
- Configure syslog for effective network monitoring
The Central Nervous System of Network Logging
Every network device generates log messages — interface state changes, authentication failures, configuration changes, error conditions, and security events. Without a centralized logging system, you'd have to log into each device individually to check its logs, making incident response slow and error prone.
Syslog is a standard protocol for message logging. It allows network devices (routers, switches, firewalls, servers) to send log messages to a central syslog server, also called a log collector or SIEM (Security Information and Event Management) system. Syslog runs over UDP (port 514) by default, though TCP (port 6514) is used when reliable delivery is needed.
Syslog Message Format
A standard syslog message follows this format:
<PRI>TIMESTAMP HOSTNAME APP[PID]: MESSAGE
The PRI (priority) value encodes both the facility and severity into a single number: PRI = facility × 8 + severity. For example, a kernel message (facility 0) at error level (severity 3) has PRI = 0 × 8 + 3 = 3.
A real syslog message:
<189>Jul 8 10:15:30 router1 bgpd[2456]: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Down BGP Notification sent
This tells us: facility 23 (BGP daemon), severity 5 (Notice), hostname router1, process bgpd, PID 2456, and the message describes a BGP adjacency change.
Severity Levels
Syslog defines eight severity levels, from 0 (Emergency — system unusable) to 7 (Debug — detailed debugging information). In practice, most production environments log at severity 5 (Notice) or 6 (Info) and above. Debug-level logging (7) generates enormous volumes and is only enabled temporarily for troubleshooting.
Match each syslog severity level with its description and numeric code.
Facility Codes
The facility code identifies which subsystem generated the message. Common facilities include kern (0) for kernel messages, mail (2) for mail system, daemon (3) for system daemons, syslog (5) for syslog internal messages, local0 through local7 (16–23) for custom use by applications and network devices.
Most network equipment uses the local0–local7 facilities. Cisco IOS, for example, sends all log messages with facility local7 by default. This lets you configure different handling rules per facility on your syslog server — store local7 in a router archive, forward local4 (firewall logs) to the SIEM, and discard debug-level noise.
A network engineer wants to log only messages severity 3 (Error) and above from Cisco routers. All Cisco syslog messages use facility local7 (code 21). What PRI value and above should the syslog server filter for?
Syslog in Practice
Production syslog deployments often use a SIEM platform like Splunk, ELK Stack (Elasticsearch, Logstash, Kibana), or Graylog. These systems ingest syslog from hundreds or thousands of devices, parse the messages, index them for search, and generate alerts on patterns matching security or operational conditions.
Best practices: use reliable transport (TCP/TLS) for critical logs, synchronize all device clocks with NTP so timestamps are meaningful, use structured logging (syslog RFC 5424 format includes structured data fields), and implement log rotation to prevent disk exhaustion on the collector.
A syslog message has PRI 134. If facility code 16 (local0) is being used, what is the severity level?
What port and transport protocol does syslog use by default?
Key Takeaways
- Syslog provides a standardized way to centralize logging from network devices
- Eight severity levels (0=Emergency through 7=Debug) indicate message urgency
- Facility codes identify the source subsystem (local0–local7 for custom use)
- PRI = facility × 8 + severity, encoding both fields in a single number
- NTP synchronization is essential for meaningful log correlation
- SIEM platforms parse, index, and alert on syslog data at scale