Exam Objective 5.6: Interpret syslog message content, severity levels, and facilities.
Syslog is the standard mechanism Cisco devices (and virtually every other network and IT system) use to generate and export log messages documenting events — interface changes, configuration edits, security violations, hardware issues, routing protocol state changes, and more. This objective builds directly on the show logging content introduced back in objective 2.4, going deeper into the actual structure of a syslog message, the full severity level scale, and the concept of facilities — and expects you to be able to read a raw syslog message and correctly interpret every one of its components.
Syslog is a standardized logging protocol/message format that allows network devices to generate structured log messages describing events, and to send those messages either to a local log buffer (as covered in objective 2.4's show logging) or to a centralized external syslog server, where messages from many devices across the network can be aggregated, searched, correlated, and retained for far longer than any single device's limited local memory would allow.
Why centralized syslog matters for network operations: A local device's log buffer is limited in size and is lost on reload unless separately saved; a centralized syslog server aggregates messages from every device in the network into one searchable location, supports long-term retention for auditing/compliance purposes, and makes it possible to correlate related events happening across multiple different devices at roughly the same time — exactly the kind of cross-device pattern recognition that's difficult to do by checking each device's local log individually.
Syslog transport: Syslog messages are traditionally sent via UDP port 514 (with a newer, more reliable TCP-based option also available on modern implementations, though UDP remains extremely common in practice) — the same lightweight, connectionless design philosophy seen with SNMP, prioritizing simple, low-overhead message delivery across potentially many devices.
A typical Cisco IOS syslog message follows a consistent structural pattern. A representative example:
*Mar 15 14:22:07.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down
Breaking this down piece by piece:
*Timestamp (Mar 15 14:22:07.123): When the event occurred, according to the device's own clock — accuracy here depends directly on the device having correct time, commonly synchronized via NTP; a device with incorrect or unsynchronized time will generate misleading timestamps that complicate correlating events across multiple devices.
Facility (LINK): Identifies the general category/source of the message — which subsystem or process on the device generated it. Facilities are covered in detail in section 4 below.
Severity (3): A numeric value (0–7) indicating how serious the event is, following the same syslog severity scale referenced back in objective 2.4. Severity is covered in full detail in section 3 below.
Mnemonic (UPDOWN): A short, human-readable code identifying the specific type of event within that facility — UPDOWN specifically indicates an interface state transition, distinct from other possible LINK-facility mnemonics that might indicate a different type of link-related event.
Message text (Interface GigabitEthernet0/1, changed state to down): The actual human-readable description of what happened, providing the specific details of the event.
General format pattern: %FACILITY-SEVERITY-MNEMONIC: Message-text — this exact structure (facility, then severity, then mnemonic, separated by hyphens, followed by a colon and the descriptive message) is standard across virtually all Cisco IOS syslog messages, and recognizing this pattern is foundational to interpreting any syslog message correctly.
Exam Alert: Expect to be shown a raw syslog message and asked to identify one specific component — most commonly the severity level or the facility — directly from the %FACILITY-SEVERITY-MNEMONIC pattern. Recognizing this exact structural format is the single most important skill this objective tests.
Severity levels run from 0 (most severe) to 7 (least severe, most routine/verbose) — this ascending-severity, descending-detail relationship was introduced back in objective 2.4 and is expanded here with the complete, specific meaning of every level.
0 — Emergency: the system is completely unusable
1 — Alert: immediate action is required
2 — Critical: a critical condition exists
3 — Error: an error condition has occurred
4 — Warning: a warning condition exists
5 — Notification: a normal but significant condition (noteworthy, but not itself an error)
6 — Informational: purely informational message, no action needed
7 — Debugging: detailed debug-level output, the most granular and verbose level
Practical examples mapped to realistic severity levels:
Severity 0 (Emergency) — a catastrophic hardware failure rendering the device completely inoperable
Severity 2 (Critical) — a critical hardware component failure (such as a failed power supply in a redundant configuration) that degrades but doesn't fully disable the device
Severity 3 (Error) — a common, frequently seen error-level message, such as the %LINK-3-UPDOWN example above, indicating an interface state change
Severity 5 (Notification) — a routine but noteworthy event, such as a configuration change being saved
Severity 6 (Informational) — a purely informational status message with no action implied
Severity 7 (Debugging) — the highly detailed, verbose output generated when a debug command (as referenced in objective 2.4) is active
Configuring the logging severity threshold: Cisco IOS allows an administrator to configure the minimum severity level that should actually be logged (to the buffer, console, or a remote syslog server) — for example, logging trap notifications (used for messages sent to a remote syslog server; not related to SNMP traps despite the shared terminology) set to level 4 would capture severity 0 through 4 (Emergency through Warning), while suppressing the less severe/more verbose levels 5 through 7.
logging trap warnings
This example configures the device to send messages of severity 4 (Warning) and more severe (lower-numbered) to the configured remote syslog server, while not forwarding routine Notification, Informational, or Debugging-level messages.
Exam Alert: The full eight-level severity scale (0 Emergency through 7 Debugging), and the specific one-word name of each individual level, is very likely to be tested directly — memorize the exact names and their exact numeric order, not just the general "lower is worse" concept. Also remember that configuring a logging threshold at a given severity level captures that level and everything more severe (lower-numbered), not less severe.
A facility identifies which general subsystem, process, or functional area of the device actually generated a given syslog message — essentially categorizing where the message came from, distinct from severity's indication of how serious the message is.
Common Cisco IOS facility examples:
LINK — messages related to physical/data-link layer interface state (matching the UPDOWN example already shown)
LINEPROTO — messages specifically related to Layer 2 line protocol status changes
SYS — general system-level messages (reloads, configuration changes, and other broad system events)
SEC or SEC-6-IPACCESSLOGP (and similar) — security-related messages, such as ACL violations being logged
OSPF — messages generated by the OSPF routing protocol process specifically (neighbor state changes, for example)
SPANTREE — messages generated by the Spanning Tree Protocol process (topology changes, guard features triggering, and so on, tying directly back to objective 2.5)
CDP — messages related to CDP neighbor discovery events
Why facility matters for troubleshooting: Recognizing the facility of a message immediately tells you which functional subsystem to focus your investigation on, even before reading the full message text or mnemonic in detail — a message with facility SPANTREE points you toward spanning tree troubleshooting concepts, while a message with facility OSPF points you toward routing protocol troubleshooting, entirely independent of the message's specific severity level.
Exam Alert: Facility and severity are two entirely independent pieces of information within the same message — a high-severity message and a low-severity message can both come from the exact same facility, and messages from completely different facilities can share the exact same severity level. Don't confuse the two; expect a question specifically testing whether you can correctly identify each one separately from a sample message.
Example 1:
%SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port GigabitEthernet0/5 on VLAN0010.
Facility: SPANTREE (this message originated from the Spanning Tree Protocol process)
Severity: 2 (Critical)
Mnemonic: ROOTGUARD_BLOCK
Interpretation: Root Guard (covered in objective 2.5) has detected a superior BPDU on a port where it should never appear, and has placed that port into the root-inconsistent blocking state to protect the intended root bridge.
Example 2:
%OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.2 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
Facility: OSPF (this message originated from the OSPF routing process)
Severity: 5 (Notification — noteworthy, but not itself flagged as an error/warning-level problem in isolation, though clearly still operationally significant and worth investigating)
Mnemonic: ADJCHG (adjacency change)
Interpretation: An OSPF neighbor relationship that was previously Full has transitioned to Down because the Dead timer expired (tying back to objective 3.3's neighbor adjacency concepts) — worth investigating as a potential Layer 1/2 problem, timer mismatch, or genuine neighbor failure.
Example 3:
%SEC-6-IPACCESSLOGP: list 110 denied tcp 192.168.1.50(1025) -> 10.1.1.100(23), 1 packet
Facility: SEC (security-related)
Severity: 6 (Informational)
Mnemonic: IPACCESSLOGP (IP access list logging, for a packet-level TCP/UDP entry specifically)
Interpretation: ACL number 110 (tying back to objective 4.6) denied a specific TCP connection attempt from 192.168.1.50 toward 10.1.1.100 on port 23 (Telnet) — this particular log entry exists because the ACL statement that matched this traffic included the log keyword, which specifically generates this kind of informational syslog entry each time that statement is hit.
Exam Alert: Practice deconstructing complete sample messages exactly like the three examples above — identify the facility, the severity (both the number and its correct name), the mnemonic, and correctly interpret the plain-English meaning of the message text, connecting it back to the underlying feature/protocol referenced elsewhere in the blueprint where relevant.
Building on the show logging content from objective 2.4, syslog messages can be sent to several different destinations simultaneously, each independently configurable:
Console — messages displayed directly on a console-connected terminal session (logging console)
Buffer — messages stored in the device's local memory log buffer (logging buffered [size]), viewable with show logging
Terminal (VTY sessions) — messages displayed on a remote Telnet/SSH session, requiring terminal monitor to be enabled on that specific session (as covered in objective 2.4)
Remote syslog server — messages forwarded to an external, centralized syslog server (logging host [address] or logging trap [severity-level] combined with logging [server-address])
Each destination can independently be configured with its own severity threshold — for example, sending only high-severity messages to the console/terminal (to avoid overwhelming an interactive session with routine informational noise) while forwarding a broader range of severities to a centralized remote syslog server for comprehensive long-term retention and analysis.
Exam Alert: Recognize that different destinations (console, buffer, terminal/VTY, remote server) can each have independently configured severity thresholds — a message might be captured in the local buffer and sent to a remote server, while being intentionally suppressed from ever appearing on an active console/terminal session, depending entirely on how each individual destination's threshold was configured.
Identify the timestamp, and confirm whether it appears reliable (a device with incorrect or unsynchronized time, via NTP, will produce misleading timestamps).
Identify the facility, pinpointing which general subsystem generated the message (LINK, OSPF, SPANTREE, SEC, and so on).
Identify the severity level by its exact number, and recall its corresponding one-word name (0 Emergency through 7 Debugging), to correctly gauge how serious the event actually is.
Identify the mnemonic, which names the specific type of event within that facility.
Read the full message text for the specific, human-readable details of what actually happened.
Connect the facility and message content back to the relevant underlying feature/protocol covered elsewhere in the blueprint (spanning tree, OSPF, ACLs, interface status, and so on) to correctly interpret the operational significance of the event and determine appropriate next steps.
Q1. In the syslog message "%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down," what does the number 3 represent?
A. The facility
B. The severity level (Error)
C. The mnemonic
D. The VLAN number
Answer: B. In the standard %FACILITY-SEVERITY-MNEMONIC message format, the number 3 represents the severity level, which corresponds to Error on the syslog severity scale. LINK is the facility (indicating the message originated from the interface/link subsystem), and UPDOWN is the mnemonic identifying this specific type of event.
Q2. Which syslog severity level corresponds to "Notification" — a normal but significant condition, worth noting but not itself flagged as an error?
A. Severity 2
B. Severity 4
C. Severity 5
D. Severity 7
Answer: C. Severity level 5 corresponds to Notification, indicating a normal but significant condition. The full scale runs 0 (Emergency) through 7 (Debugging), with severity 2 being Critical, severity 4 being Warning, and severity 7 being Debugging — the most detailed, verbose level.
Q3. What does the "facility" component of a syslog message specifically identify?
A. How severe the event is
B. Which general subsystem or process on the device generated the message
C. The exact timestamp of the event
D. The remote syslog server's IP address
Answer: B. The facility identifies which general subsystem or functional area of the device generated the message — for example, LINK for interface-related events, OSPF for routing protocol events, or SPANTREE for spanning tree events — distinct from severity, which independently indicates how serious the event is, regardless of which facility generated it.
Q4. A device is configured with "logging trap warnings" for messages sent to a remote syslog server. Which severity levels will actually be forwarded to that server?
A. Only severity 4 (Warning) messages
B. Severity 0 through 4 (Emergency through Warning)
C. Severity 4 through 7 (Warning through Debugging)
D. All severity levels equally
Answer: B. Configuring a logging severity threshold captures that specified level and every level more severe (lower-numbered) than it. Setting the threshold to warnings (severity 4) means severities 0 through 4 (Emergency, Alert, Critical, Error, and Warning) will be forwarded, while the less severe, more routine levels 5 through 7 (Notification, Informational, Debugging) are suppressed from being sent to that destination.
Q5. An administrator sees the message "%SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port GigabitEthernet0/5 on VLAN0010." What can be correctly interpreted from this message?
A. This is a routine, informational message requiring no attention
B. This message originated from the Spanning Tree Protocol process at Critical severity, and indicates Root Guard has blocked a port after detecting a superior BPDU where one should never appear
C. This message indicates a successful OSPF neighbor adjacency
D. This message is unrelated to any spanning tree feature covered elsewhere in the blueprint
Answer: B. The SPANTREE facility identifies this as originating from the Spanning Tree Protocol process, severity 2 indicates a Critical-level event, and the ROOTGUARD_BLOCK mnemonic combined with the message text indicates that Root Guard (covered in objective 2.5) has placed the port into a root-inconsistent blocking state after detecting a superior BPDU on a port where it should never have appeared, protecting the intended root bridge from being displaced.
Q6. Can two syslog messages originating from completely different facilities share the exact same severity level?
A. No, each facility is permanently tied to exactly one specific severity level
B. Yes, facility and severity are independent pieces of information within a syslog message, so messages from different facilities can share the same severity level
C. Only if both messages also share the same mnemonic
D. Only OSPF and SPANTREE messages can share severity levels
Answer: B. Facility and severity are two entirely independent components of a syslog message. Facility indicates which subsystem generated the message, while severity independently indicates how serious that specific event is — meaning messages from very different facilities (such as OSPF and SPANTREE) can absolutely share the same severity level, and messages from the same facility can just as easily have differing severity levels depending on the specific event.