This chapter covers Syslog severity levels and management, a core topic in CompTIA Network+ N10-009 Domain 3.0 (Network Operations), Objective 3.3: 'Given a scenario, use network monitoring tools and protocols.' Syslog questions appear on approximately 8-12% of the exam, often testing your ability to interpret severity levels, configure logging, and identify misconfigurations. You will learn the eight severity levels (0-7), how syslog messages are generated and forwarded, best practices for log management, and how to troubleshoot using syslog. Mastery of syslog is essential for network monitoring, security auditing, and compliance.
Jump to a section
Imagine a large hospital emergency department with a triage nurse at the front desk. Every patient (log message) arrives with a severity level from 0 (cardiac arrest) to 7 (minor paper cut). The triage nurse reads each patient's complaint and assigns a priority code: 0-1 are immediately rushed to the trauma bay (console alerts), 2-3 are sent to rapid assessment (critical notifications), 4-5 go to the waiting room (error/warning logs), and 6-7 are directed to the pharmacy or self-care (informational/debug). The nurse records each patient's arrival time, complaint, and assigned priority in a logbook (syslog server). Different departments (log consumers) subscribe to specific priority levels: the trauma team only receives level 0-1 patients, the urgent care team sees 2-3, and the general practitioners review 4-5. If the triage nurse mislabels a cardiac arrest as level 5, the patient may die in the waiting room—just as a misconfigured syslog severity threshold can cause critical network failures to be ignored. The hospital also has a policy that all level 0-1 patients must be documented within 5 minutes (alerting SLA), and the logbook is periodically audited (log review) to ensure no patient was missed.
What is Syslog and Why Does It Exist?
Syslog is a standard protocol for message logging, defined in RFC 5424 (and earlier RFC 3164). It allows network devices—routers, switches, firewalls, servers, and other appliances—to send event messages to a central logging server (syslog server). The primary purpose is to provide a centralized, consistent method for collecting, storing, and analyzing log data. Without syslog, each device would store logs locally, making it nearly impossible to correlate events across the network, troubleshoot issues, or meet compliance requirements (e.g., PCI-DSS, HIPAA).
How Syslog Works Internally – The Mechanism
Syslog operates over UDP port 514 by default, though TCP port 6514 is used for reliable delivery (RFC 6587). The protocol is connectionless and unacknowledged when using UDP, meaning messages can be lost if the network is congested or the server is overwhelmed. Each syslog message consists of three parts: a PRI header (priority), a TIMESTAMP, and a MSG (message body). The PRI header encodes the facility (device type) and severity level using the formula: Priority = Facility × 8 + Severity. For example, a kernel message (facility 0) with severity 3 (error) has priority 3 (0×8+3). The severity level is a number from 0 to 7, where 0 is the most critical (Emergency) and 7 is the least (Debug).
The syslog message format (RFC 5424) is:
<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MSGA typical log entry looks like:
<134>1 2025-03-15T10:30:00Z router1.example.com NETMGMT 1234 - [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] Interface GigabitEthernet0/1 changed state to upThe priority 134 corresponds to facility 16 (local use 0) and severity 6 (informational).
The Eight Syslog Severity Levels (0-7)
The severity level indicates the urgency of the message. The exam expects you to know these by number, name, and keyword:
Level 0 – Emergency (emerg): System is unusable. Example: kernel panic, power failure. These messages are rare but indicate immediate action required.
Level 1 – Alert (alert): Immediate action needed. Example: critical temperature threshold exceeded, device overheating.
Level 2 – Critical (crit): Critical conditions. Example: hard drive failure, interface down causing loss of connectivity.
Level 3 – Error (err): Error conditions. Example: configuration file corrupted, authentication failure.
Level 4 – Warning (warning): Warning conditions. Example: interface utilization above 80%, certificate expiring soon.
Level 5 – Notice (notice): Normal but significant conditions. Example: interface up/down, user login/logout.
Level 6 – Informational (info): Informational messages. Example: configuration change applied, DNS query resolved.
Level 7 – Debug (debug): Debug-level messages. Example: packet header details, internal function calls. This level generates high volume and should be used only for troubleshooting.
Syslog Facilities
The facility identifies the source of the message. Common facilities include: - kern (0): Kernel messages - user (1): User-level messages - mail (2): Mail system - daemon (3): System daemons - auth (4): Security/authorization messages - syslog (5): Messages generated internally by syslogd - lpr (6): Line printer subsystem - news (7): Network news subsystem - uucp (8): UUCP subsystem - cron (9): Clock daemon - authpriv (10): Security/authorization messages (private) - ftp (11): FTP daemon - ntp (12): NTP subsystem - logaudit (13): Log audit - logalert (14): Log alert - clock (15): Clock daemon - local0 to local7 (16-23): Reserved for local use. Network administrators often configure devices to use local0-local7 for custom logging.
Configuring Syslog on Cisco IOS (Example)
To send syslog messages from a Cisco router to a server:
Router(config)# logging host 192.168.1.100
Router(config)# logging trap informational
Router(config)# logging source-interface GigabitEthernet0/0
Router(config)# logging onlogging host specifies the syslog server IP (default port 514). Use logging host 192.168.1.100 transport tcp port 6514 for TCP.
logging trap sets the severity threshold: only messages at that level and higher (lower number) are sent. For example, logging trap informational sends levels 0-6 (debug is excluded).
logging source-interface ensures all syslog messages have a consistent source IP.
logging on enables syslog output.
To verify:
Router# show loggingThis displays the logging configuration, buffer contents, and statistics.
Syslog Server Management
A syslog server (e.g., rsyslog, syslog-ng, Kiwi Syslog Server) receives and stores messages. Key management tasks include: - Log rotation: Prevent disk exhaustion by rotating logs daily or when they reach a certain size (e.g., 100 MB). - Log retention: Retain logs according to compliance requirements (e.g., 90 days to 7 years). - Log analysis: Use tools like grep, awk, or SIEM (Security Information and Event Management) to search for patterns (e.g., failed logins, interface flapping). - Alerting: Configure triggers for severity 0-2 messages to send email or SMS alerts.
Syslog vs. Other Logging Protocols
Syslog is often compared with SNMP traps. While both are used for monitoring, syslog provides detailed text messages, whereas SNMP traps are structured variables defined in MIBs. Syslog is simpler to configure but less structured; SNMP traps are more efficient for automated processing but require MIB knowledge. The exam may ask you to choose between them based on scenario: syslog for detailed troubleshooting, SNMP for performance monitoring.
Best Practices
Set appropriate severity thresholds to avoid log flooding. For production, use logging trap notifications (levels 0-5) to exclude debug and informational noise.
Use a dedicated syslog server with redundancy (primary and secondary).
Synchronize time across all devices using NTP to ensure accurate timestamps.
Secure syslog traffic over VPN or use TLS (TCP 6514) to prevent tampering.
Regularly review logs for anomalies and automate pattern matching.
Common Pitfalls
Missing timestamps: If NTP is not configured, timestamps may be incorrect, making correlation impossible.
UDP packet loss: High-volume environments should use TCP or implement reliable syslog (e.g., RELP).
Overwhelmed server: A single syslog server may be insufficient for thousands of devices; use load balancers or multiple servers.
Misconfigured severity: Setting logging trap debugging on a busy router can generate gigabytes of logs per day, filling storage rapidly.
Device Generates Event
A network device (router, switch, firewall) experiences an event—an interface goes down, a user authenticates, a temperature sensor triggers. The device's operating system or application creates a log message. The message includes a severity level based on the event's urgency. For example, an interface down event is typically severity 3 (Error) or 5 (Notice) depending on the device. The syslog daemon on the device assigns a facility (e.g., local0 for custom applications). The message is formatted according to RFC 5424 with a PRI header, timestamp, hostname, and message text. The device checks its logging configuration to determine whether to send this message to a syslog server based on the severity threshold (e.g., only messages with severity <= 4 are forwarded).
Message Transmitted via UDP/TCP
If the message meets the severity threshold, the device encapsulates it in a UDP datagram (default port 514) or TCP segment (port 6514) and sends it to the configured syslog server IP address. With UDP, there is no acknowledgment—the device sends and forgets. If the server is unreachable or the packet is dropped, the message is lost. With TCP, the device waits for a TCP handshake and ACK, ensuring delivery but adding overhead. The device may also buffer messages locally (in a logging buffer) in case of network failure. The source IP of the packet is typically the management interface or the interface specified by `logging source-interface`.
Syslog Server Receives and Stores
The syslog server (e.g., rsyslog) listens on UDP 514 or TCP 6514. Upon receiving a message, it parses the PRI header to extract facility and severity. It then writes the message to a log file, typically organized by hostname, facility, or date. For example, rsyslog can be configured to write all messages from a specific host to `/var/log/hosts/router1.log`. The server may also apply filters: for example, messages with severity 0-2 are written to a separate 'critical.log' file. The server timestamps the message upon receipt (if the device timestamp is unreliable). If disk space is low, older logs may be rotated or compressed according to the log rotation policy.
Log Analysis and Alerting
Network administrators or automated tools (SIEM) analyze the stored logs. They search for specific patterns using tools like grep, awk, or specialized software. For example, a search for 'GigabitEthernet0/1.*down' identifies interface failures. Alerting rules are configured: if a severity 0-2 message is received, an email or SMS alert is sent to the NOC. For compliance, logs are archived and retained for a defined period (e.g., 1 year). The analysis may reveal recurring issues (e.g., frequent authentication failures) that prompt configuration changes. The syslog server itself generates syslog messages about its own operations (e.g., log rotation, disk full) which are also logged.
Log Review and Troubleshooting
When a network problem occurs, engineers review syslog messages to determine the root cause. They correlate timestamps across devices to reconstruct the sequence of events. For example, if a user reports intermittent connectivity, the engineer checks syslog for interface flaps, spanning-tree changes, or routing protocol neighbor resets. The severity level helps prioritize: focus on errors and warnings first. Debug-level logs (severity 7) may be enabled temporarily to capture granular details, but this increases log volume significantly. After troubleshooting, debug logging is disabled to prevent performance impact and disk flooding.
In a large enterprise with thousands of network devices, syslog is indispensable for centralized monitoring. Consider a multinational corporation with data centers in three regions. Each region has hundreds of routers, switches, and firewalls all sending syslog to a pair of redundant syslog servers in the primary data center. The servers run syslog-ng and forward critical messages (severity 0-2) to a SIEM platform (e.g., Splunk) for real-time alerting. The SIEM correlates messages across devices: for instance, if a switch loses power, the syslog server receives 'interface down' messages from dozens of devices, triggering an alert to the NOC. The logs are retained for one year to meet compliance requirements. One common problem is that during a DDoS attack, the syslog server gets overwhelmed by the sheer volume of messages from many devices, causing legitimate critical messages to be dropped. To mitigate this, the team implements rate limiting on each device (e.g., logging rate-limit 100 on Cisco IOS) and uses separate servers for high-volume devices.
Another scenario is a managed service provider (MSP) monitoring hundreds of customer networks. The MSP uses a multi-tenant syslog server that segregates logs by customer. Each customer device sends syslog to a specific port or uses a unique facility. The MSP configures alerts for each customer based on their SLA: severity 0-2 alerts within 5 minutes, severity 3-4 within 30 minutes. A common misconfiguration is setting the severity threshold too low on a customer's router, causing debug messages to flood the server and consume disk space, which then causes older logs to be rotated prematurely. The MSP has automated scripts that check each device's logging configuration daily and flag deviations from the standard template.
In a cloud environment, syslog is often sent from virtual appliances (e.g., virtual firewalls) to a central logging service like AWS CloudWatch Logs or Azure Monitor. The challenge here is that the syslog messages are sent over the internet, so using TCP with TLS is critical to ensure delivery and confidentiality. Engineers must configure the cloud logging endpoint and ensure that the virtual appliance's security group allows outbound UDP 514 or TCP 6514. A common issue is that the cloud logging service has a ingestion rate limit; if the appliance sends too many messages, they are throttled and lost. Engineers then adjust the severity threshold to reduce volume.
The CompTIA Network+ N10-009 exam tests syslog under Objective 3.3: 'Given a scenario, use network monitoring tools and protocols.' You must know the eight severity levels (0-7) by name and number, and understand how the threshold works (i.e., if you set logging trap informational, you receive levels 0-6, not 0-7). A common wrong answer is that setting a threshold to 'warning' includes debug messages—it does not; debug (level 7) is only included if you set 'debug'. Another trap: candidates confuse severity with facility. The exam may give a PRI value (e.g., 134) and ask you to determine the severity. Remember: Priority = Facility × 8 + Severity, so 134 = 16×8 + 6 → severity 6 (informational). You will not need to calculate on the exam, but understanding the relationship helps.
The exam loves to test edge cases: for example, what happens if the syslog server is unreachable? With UDP, messages are lost; with TCP, they are buffered until the server becomes available (though buffers can overflow). Also, know that syslog uses UDP 514 by default, but TCP 6514 is used for reliable delivery. Another frequent question: 'You need to receive only critical and higher messages. What severity level should you configure?' The answer is 'alert' (level 1) because critical is level 2, and you want levels 0 and 1 (emergency and alert). But many candidates pick 'critical' (level 2), which would include levels 0,1,2—that's too broad if the requirement is only critical and higher. 'Critical and higher' means levels 0,1,2, so threshold 'critical' is correct. Wait, careful: 'critical and higher' includes emergency (0), alert (1), and critical (2). So setting threshold to 'critical' (2) includes 0,1,2. That is correct. If the requirement is 'only emergency and alert', threshold should be 'alert' (1).
Common wrong answers: (1) Thinking that syslog uses TCP 514 by default. (2) Confusing syslog with SNMP traps. (3) Believing that setting threshold to 'debug' includes all messages—it does, but it's rarely used. (4) Forgetting that syslog messages are unacknowledged with UDP. (5) Misidentifying severity levels: level 0 is Emergency, not level 7. To eliminate wrong answers, always ask: 'What is the default transport? UDP 514. What does the threshold mean? It includes that level and all lower-numbered (more severe) levels.'
Syslog severity levels: 0 (Emergency), 1 (Alert), 2 (Critical), 3 (Error), 4 (Warning), 5 (Notice), 6 (Informational), 7 (Debug).
Default syslog transport is UDP port 514; TCP port 6514 is used for reliable delivery.
A logging threshold includes the specified level and all lower-numbered (more severe) levels.
Syslog messages use the format: <PRI>VERSION TIMESTAMP HOSTNAME APP-NAME MSG.
Priority = Facility × 8 + Severity.
Common facilities: local0 to local7 (16-23) for custom use.
NTP synchronization is critical for accurate timestamps in logs.
Syslog is unacknowledged with UDP; messages can be lost without notification.
Debug logging (level 7) generates high volume and should be used only temporarily for troubleshooting.
Syslog servers should have log rotation and retention policies to manage disk space.
These come up on the exam all the time. Here's how to tell them apart.
Syslog (UDP)
Default transport protocol (UDP port 514).
Connectionless and unacknowledged; messages can be lost.
Lower overhead and faster transmission.
Suitable for low-volume, non-critical logging.
No built-in flow control; can overwhelm a slow server.
Syslog (TCP)
Optional transport protocol (TCP port 6514).
Connection-oriented with acknowledgment; ensures delivery.
Higher overhead due to connection setup and ACKs.
Suitable for high-volume or critical logging.
Provides flow control and congestion avoidance.
Mistake
Syslog always uses TCP for reliable delivery.
Correct
Syslog defaults to UDP on port 514. TCP (port 6514) is used for reliable delivery but is not the default. Many devices require explicit configuration to use TCP.
Mistake
Setting the logging threshold to 'warning' includes debug messages.
Correct
The threshold includes the specified level and all lower-numbered (more severe) levels. Warning is level 4, so it includes levels 0-4. Debug is level 7 and is not included unless the threshold is set to 'debug' (level 7).
Mistake
Syslog severity level 7 is the most critical.
Correct
Severity level 0 (Emergency) is the most critical. Level 7 (Debug) is the least critical and generates the most verbose output.
Mistake
Syslog messages are always stored on the device that generates them.
Correct
Syslog messages can be stored locally (in a buffer or file) but are typically forwarded to a central syslog server for centralized management. Local storage is limited and often overwritten.
Mistake
The facility code indicates the severity of the message.
Correct
The facility code identifies the source type (e.g., kernel, mail, local use), not the severity. Severity is a separate field encoded in the PRI header along with the facility.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The eight severity levels are: 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, 7 Debug. Level 0 is the most severe (system unusable), and level 7 is the least severe (debugging messages). For the exam, memorize both the number and the keyword (e.g., 'emerg' for Emergency).
Setting 'logging trap warnings' sends messages with severity levels 0-4 (Emergency, Alert, Critical, Error, Warning). Warning is level 4, and the threshold includes that level and all lower-numbered (more severe) levels. Levels 5-7 (Notice, Informational, Debug) are not sent. Use 'show logging' to verify the configured threshold.
Syslog sends text-based event messages to a central server, typically for troubleshooting and security auditing. SNMP traps are structured notifications sent from an agent to a manager, defined in MIBs, used for performance monitoring and fault management. Syslog is simpler and more human-readable; SNMP traps are more efficient for automated processing. The exam may ask you to choose based on scenario: use syslog for detailed logs, SNMP for performance data.
Common causes: (1) The server IP or port is misconfigured on the device. (2) Firewall rules block UDP 514 or TCP 6514. (3) The severity threshold is set too high (e.g., 'logging trap critical' excludes warnings and notices). (4) The device's logging is disabled ('no logging on'). (5) NTP is not synchronized, causing timestamps to be rejected. Check with 'show logging' on the device and verify connectivity with telnet or nc.
The PRI value is calculated as Facility × 8 + Severity. For 134, divide by 8: 134 ÷ 8 = 16 remainder 6. Facility 16 is 'local0', and severity 6 is 'Informational'. So the message is an informational message from a local use facility. The exam may ask you to interpret PRI values, but more often you'll be given the severity directly.
Use UDP for low-volume, non-critical logs where some loss is acceptable. Use TCP for critical logs that must be delivered reliably, especially across WAN links. TCP adds overhead but ensures delivery. Many modern implementations support TCP with TLS for encryption. The exam expects you to know that UDP is default and TCP is optional for reliability.
Enter global configuration mode and issue: 'logging host 192.168.1.100' (replace with your server IP). Optionally set the severity threshold: 'logging trap informational'. Set the source interface: 'logging source-interface Vlan1'. Enable logging: 'logging on'. Verify with 'show logging'. For TCP, add 'transport tcp port 6514' to the logging host command.
You've just covered Syslog Severity Levels and Management — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?