Imagine your network is a busy city, and devices are constantly shouting about their status. Syslog is the central 911 dispatch that logs every shout, from a minor traffic jam to a five-alarm fire. For the CCNA 200-301 exam (objective 4.6), understanding syslog severity levels is essential for configuring logging, filtering noise, and troubleshooting efficiently. In real networks, syslog is the first place engineers look when something breaks—mastering severity levels turns a firehose of data into actionable intelligence.
Jump to a section
Think of a hospital emergency room. Patients arrive with different levels of urgency, and a triage nurse assigns a severity level from 1 (immediate life threat) to 5 (non-urgent). Level 1 patients (e.g., heart attack) get a crash cart and a team of doctors. Level 2 (severe bleeding) gets rapid attention. Level 3 (broken bone) waits a bit. Level 4 (mild fever) waits longer. Level 5 (small cut) might wait hours or be sent to a clinic. The hospital doesn't waste crash carts on level 5 patients. In networking, syslog severity levels work exactly the same way. A router generates messages with levels 0 (Emergency) to 7 (Debugging). Level 0 means the router is on fire—literally, a hardware failure that requires immediate action. Level 7 is a debug message that tells you every packet that passes. Just as a hospital filters out level 5 patients from the trauma team, a network engineer configures the router to only log messages at or above a certain severity (e.g., level 3 for production). This prevents the log from being flooded with debug noise while ensuring critical alerts are captured. The triage nurse uses a chart; the router uses the "logging console" or "logging trap" command with a severity level. If you set the trap level to 4 (Warning), the router sends messages of levels 0-4 to the syslog server, discarding levels 5-7. This is exactly how a hospital reserves its trauma bay for levels 1-3 and sends level 4-5 patients to the waiting room.
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) to send event messages to a central syslog server. The purpose is to centralize logs for monitoring, troubleshooting, and compliance. Without syslog, you'd have to log into each device individually and check its local buffer—a nightmare in a network with hundreds of devices.
Cisco IOS implements syslog with eight severity levels. Each message has a facility (e.g., local0, syslog) and a severity level. The severity level indicates how urgent the message is. The levels are:
0 – Emergency: System is unusable. Example: a hardware failure causing a crash.
1 – Alert: Immediate action needed. Example: a critical temperature threshold exceeded.
2 – Critical: Critical conditions. Example: a major interface failure.
3 – Error: Error conditions. Example: a routing protocol neighbor down.
4 – Warning: Warning conditions. Example: a configuration change that might cause issues.
5 – Notification: Normal but significant conditions. Example: an interface coming up.
6 – Informational: Informational messages. Example: a user login.
7 – Debugging: Debug-level messages. Example: output from the debug command.
How Syslog Severity Levels Work Step by Step
When a Cisco device generates a log message, it assigns a severity level based on the event. The device then checks its logging configuration to decide what to do with the message. The key commands are:
logging console <level>: Messages sent to the console (directly connected terminal) are filtered by this level. Default is debugging (level 7), meaning all messages appear on the console. In production, this is often set to warnings (level 4) to reduce noise.
logging monitor <level>: Messages sent to VTY (Telnet/SSH) sessions. Default is debugging.
logging trap <level>: Messages sent to a syslog server (using logging <server-ip>). Default is informational (level 6).
logging buffered <level>: Messages stored in the device's local RAM buffer. Default is debugging.
logging history <level>: Messages stored in the device's history table (used for SNMP). Default is warnings.
When a message is generated, the device compares its severity level to the configured threshold for each output destination. If the message level is less than or equal to the threshold, it is sent. For example, if logging trap 4 is configured, messages of levels 0-4 are sent; levels 5-7 are dropped.
Key States, Timers, and Defaults
Default severity for console: 7 (debugging)
Default severity for monitor: 7 (debugging)
Default severity for trap: 6 (informational)
Default severity for buffered: 7 (debugging)
Default severity for history: 4 (warnings)
Syslog uses UDP port 514 by default. It can also use TCP (port 1468) for reliable delivery, but UDP is more common.
Syslog messages are unacknowledged – there is no confirmation from the server. This means messages can be lost if the network is congested or the server is down.
Cisco devices generate syslog messages with a format: %FACILITY-SEVERITY-MNEMONIC: description. For example, %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up. The severity is the number after the facility (e.g., 3 means severity 3 – Error).
IOS CLI Verification Commands with Example Output
To view the current logging configuration:
Router# show logging
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, small buffer)
Console logging: level debugging, 32 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 32 messages logged, xml disabled,
filtering disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
No active filter modules.
Trap logging: level informational, 36 message lines logged
Logging to 10.1.1.100 (udp port 514, audit disabled,
link up),
36 message lines logged, xml disabled,
filtering disabledThis output shows that console, monitor, and buffer are set to debugging (level 7), while trap logging is set to informational (level 6). Messages are being sent to syslog server 10.1.1.100.
To see messages in the buffer:
Router# show logging | include %LINK-3-UPDOWNHow It Interacts with Related Protocols
Syslog is often used alongside SNMP. While SNMP is used for polling and traps (alerts), syslog provides a detailed log of events. Many network monitoring systems (e.g., SolarWinds, PRTG) collect both. Syslog can also be integrated with AAA (TACACS+/RADIUS) to log authentication events. For example, when a user logs in via SSH, the device can generate a syslog message at level 6 (Informational) with the username and IP address.
Syslog severity levels are also used in conjunction with the logging rate-limit command to prevent DoS attacks that flood the log. The logging source-interface command ensures all syslog messages have a consistent source IP, which is important for server filtering.
Enable Syslog Logging Globally
First, ensure that syslog logging is enabled on the device. By default, logging is enabled for console and buffer, but you need to explicitly configure a syslog server. Use the command `logging <server-ip> [vrf <vrf-name>]` to point to your syslog server. For example: `Router(config)# logging 10.1.1.100`. This tells the router to send syslog messages to that server. The default transport is UDP port 514. You can also specify a different port with `logging host <ip> transport udp port <port>`.
Set the Trap Severity Level
Configure the severity threshold for messages sent to the syslog server using `logging trap <level>`. The level can be a number (0-7) or a keyword (emergencies, alerts, critical, errors, warnings, notifications, informational, debugging). For production, a common setting is `logging trap warnings` (level 4). This means only messages of severity 0-4 (Emergency through Warning) are sent to the server. Debug messages (level 7) and informational (level 6) are suppressed, reducing log volume. Example: `Router(config)# logging trap warnings`.
Set Console and Monitor Severity Levels
To control what appears on the console (directly connected terminal) and on VTY lines (Telnet/SSH), use `logging console <level>` and `logging monitor <level>`. In a lab, you might leave these at `debugging` to see all messages. In production, set them to `warnings` or `errors` to avoid overwhelming the terminal. For example: `Router(config)# logging console warnings` and `Router(config)# logging monitor errors`. Remember that the console and monitor thresholds are separate from the trap threshold.
Configure Local Buffer Logging
The local buffer stores log messages in RAM. Use `logging buffered <level>` to set the severity threshold for the buffer. The buffer size can also be configured (default is 4096 bytes for most platforms, but can be increased with `logging buffered <size>`). For example: `Router(config)# logging buffered 16384 warnings`. This sets the buffer to 16KB and only stores messages of level 0-4. To view the buffer, use `show logging`. The buffer is cleared on reload, so for persistent logs, use a syslog server.
Verify Syslog Configuration
Use `show logging` to display the current logging configuration and the number of messages logged. Check that the trap level is set correctly and that the syslog server IP appears. Also use `show logging | include %SYS-5-CONFIG_I` to see configuration change messages. To confirm messages are reaching the server, generate a test message with `Router# debug ip packet` (careful—this can flood the console) or simply make a configuration change. Then check the syslog server for the incoming message. On the server, you should see messages like `<189>%LINK-3-UPDOWN: ...` where 189 is the priority (facility*8 + severity).
Troubleshoot Missing Syslog Messages
If messages are not appearing on the syslog server, check the following: (1) Ensure the syslog server is reachable via ping from the router. (2) Verify that the trap level is not too restrictive (e.g., set to `debugging` temporarily to test). (3) Check for ACLs blocking UDP port 514. (4) Use `debug logging` on the router to see if messages are being generated (but be cautious—this can produce a lot of output). (5) On the server, verify that the syslog service is running and that the firewall allows inbound UDP 514. Often, the issue is a mismatch in severity level or a network path problem.
In a typical enterprise, you might have hundreds of routers and switches generating syslog messages. A common deployment is to send all messages of severity Warning (level 4) and above to a central syslog server like Splunk or ELK stack. Lower severity messages (Notifications, Informational, Debug) are either sent to a separate server or dropped entirely to reduce storage costs. For example, a network team might configure:
logging host 192.168.1.50
logging trap warnings
logging console critical
logging buffered 32768 warningsThis ensures that only critical events (like interface flaps, OSPF neighbor changes, and hardware errors) are logged to the server. Console output is limited to Critical (level 2) and above, so the engineer doesn't get spammed when plugging in a console cable. The buffer stores the same critical events for quick local troubleshooting.
One real-world scenario: A core switch experiences intermittent connectivity. The engineer checks the syslog server and sees repeated %LINEPROTO-5-UPDOWN messages (severity 5 – Notification) for a trunk port. Because the trap level is set to warnings (level 4), these messages were not sent to the server. The engineer had to log into the switch and check the buffer (which was set to warnings as well) and found nothing. After changing the trap level to notifications (level 5), the intermittent flapping was captured. The lesson: choose the severity threshold carefully. Too restrictive, and you miss important clues; too permissive, and you drown in noise.
Another scenario: A security team wants to monitor all login attempts. They set logging trap informational to capture level 6 messages like %SEC_LOGIN-5-LOGIN_SUCCESS and %SEC_LOGIN-4-LOGIN_FAILED. This allows them to detect brute-force attacks. However, the massive volume of informational messages can overwhelm the syslog server if not rate-limited. Cisco provides logging rate-limit to limit the number of messages per second.
Misconfiguration example: An engineer sets logging trap 7 (debugging) on a production router, and then runs debug ip packet. The router sends thousands of debug messages per second to the syslog server, saturating the link and causing the server to crash. Always set appropriate severity levels and avoid debugging on production devices.
The CCNA 200-301 exam (objective 4.6: Configure and verify syslog) tests your understanding of syslog severity levels, default values, and how to interpret log messages. Expect at least one multiple-choice question on the severity level numbers and their keywords, and possibly a simulation where you must configure logging to a server.
Common Wrong Answers and Why Candidates Choose Them:
Confusing severity 0 with severity 7. Many candidates think Emergency (0) is the least severe because 0 is a small number. Actually, lower number = more severe. Emergency (0) is the most severe, Debugging (7) is the least.
Thinking the default trap level is 7. The default for logging trap is actually informational (6), not debugging (7). The default for console and buffer is debugging, but trap is informational. This is a classic trick.
Believing syslog uses TCP port 514 by default. It uses UDP. Some candidates confuse it with SNMP or other protocols. TCP is optional and must be explicitly configured.
Misinterpreting the priority value in syslog messages. The number inside the angle brackets (e.g., <189>) is not the severity. It is the priority = (facility * 8) + severity. For example, facility local7 (16) * 8 = 128, plus severity 3 = 131. The exam may ask you to derive the severity from the priority.
Specific Values to Memorize: - Severity levels: 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notification, 6 Informational, 7 Debugging. - Default trap level: 6 (Informational). - Default console level: 7 (Debugging). - Default buffer level: 7 (Debugging). - Syslog uses UDP port 514.
Decision Rule for Scenario Questions:
If the question says "An engineer wants to see only critical events on the console," set logging console critical (level 2). If they want to send only errors and above to the server, set logging trap errors (level 3). Remember: the threshold includes all levels equal to or lower (more severe) than the configured level. So logging trap 3 sends levels 0,1,2,3. Level 4 and above are dropped.
Syslog severity levels: 0 Emergency (most severe) to 7 Debugging (least severe).
Default trap level is 6 (Informational); default console and buffer are 7 (Debugging).
Syslog uses UDP port 514 by default (TCP optional on port 1468).
Configure logging server with `logging <ip>` and set threshold with `logging trap <level>`.
Use `show logging` to verify configuration and view buffered messages.
The priority in syslog messages is (facility * 8) + severity, not the severity alone.
Always set appropriate severity levels to avoid log flooding or missing critical events.
These come up on the exam all the time. Here's how to tell them apart.
Syslog
Uses UDP port 514 (default).
Message format is text-based, human-readable.
No acknowledgment; messages can be lost.
Severity levels 0-7, configured per destination.
Used for logging events and debugging.
SNMP Traps
Uses UDP port 162 (default).
Message format is binary (ASN.1).
No acknowledgment; traps are unconfirmed.
Uses OIDs and severity is not standardized.
Used for alerts and performance monitoring.
Mistake
Severity 0 is the least severe because it's the smallest number.
Correct
Severity 0 (Emergency) is the most severe; lower numbers indicate higher urgency.
Candidates often associate small numbers with low importance, but in syslog it's the opposite.
Mistake
The default syslog trap level is 7 (debugging).
Correct
The default for `logging trap` is 6 (informational), not 7. Console and buffer default to 7.
Many study materials mention default debugging for console, leading candidates to assume trap is the same.
Mistake
Syslog uses TCP port 514 for reliable delivery by default.
Correct
Syslog uses UDP port 514 by default. TCP can be used but must be explicitly configured.
Cisco's documentation mentions TCP, but the default is UDP. The exam tests the default.
Mistake
The number in angle brackets like <189> is the severity level.
Correct
The number is the priority = (facility * 8) + severity. To get severity, calculate priority % 8.
Candidates see a number and assume it's the severity, not realizing it includes the facility.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Level 5 is Notification, used for normal but significant events like an interface coming up. Level 6 is Informational, used for routine events like a user login. The key difference is that Notification events are considered more noteworthy. In practice, if you set your trap level to 5, you will get both levels 5 and below (0-5). If you set it to 6, you get levels 0-6. For exam purposes, remember the order: 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notification, 6 Informational, 7 Debugging.
Yes. Cisco IOS supports reliable syslog delivery using TCP. The command is `logging host <ip> transport tcp port <port>`. The default TCP port is 1468 (though some implementations use 601). However, the default and most common is UDP port 514. For the CCNA exam, assume UDP unless specified. TCP is useful when you cannot afford to lose log messages, but it adds overhead and may cause delays if the server is slow.
Set the console logging level to something higher than debugging. For example, `logging console warnings` will suppress debug messages (level 7) and only show levels 0-4. Alternatively, you can disable console logging entirely with `no logging console`. Another option is to use `logging console disabled` (but that is not a standard command). The best practice is to never run debug on a production device without first setting appropriate logging thresholds.
The priority value is calculated as (facility number * 8) + severity. For example, facility local7 (16) * 8 = 128, plus severity 3 (Error) = 131. The number in angle brackets is this priority. To find the severity, divide by 8 and take the remainder: severity = priority % 8. For <189>, 189 % 8 = 5, so severity 5 (Notification). The facility can be determined by integer division: 189 / 8 = 23 (truncated), which corresponds to facility 23 (local7). The exam may ask you to decode this.
Use the `show logging` command. This displays the logging configuration and then the buffered messages. You can use filters like `show logging | include %OSPF` to see only OSPF-related messages. The buffer is cleared when the device reloads, so it's not persistent. To keep logs across reboots, you must send them to a syslog server.
The default buffer size varies by platform, but it is typically 4096 bytes (4 KB) on many routers and switches. You can increase it with `logging buffered <size>`, where size is in bytes. For example, `logging buffered 32768` sets a 32 KB buffer. Larger buffers can store more messages but consume more RAM.
Yes. You can configure multiple `logging host` commands, each with its own severity level using `logging trap <level>` after specifying the host. For example: ``` logging host 10.1.1.100 logging trap warnings logging host 10.1.1.101 logging trap informational ``` This sends warnings and above to the first server, and all messages (including informational) to the second. This is useful for separating critical alerts from full logging.
You've just covered Syslog Severity Levels — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?