Syslog – Logging Overview

1. What Is Syslog?

Syslog is a standardised protocol and message format (defined in RFC 5424, with the original RFC 3164 still widely used) that network devices use to generate, store, and transmit event log messages. Every significant event on a Cisco router or switch — interface state changes, login attempts, configuration changes, routing protocol events, hardware failures — produces a syslog message describing what happened, when, and at what severity.

Syslog is the foundation of network visibility. Without it, administrators have no record of what happened on a device in the past, no way to correlate events across multiple devices, and no audit trail for compliance. Syslog messages can be stored locally (in RAM buffer or flash) or forwarded to a remote syslog server for centralised, persistent, searchable log management.

Syslog Capability	What It Provides
Event logging	Records interface up/down events, authentication failures, configuration changes, routing adjacency changes, and hardware alerts
Severity filtering	Administrators control which severity levels are recorded — reducing noise by logging only events that matter
Centralised storage	Remote syslog servers aggregate logs from hundreds of devices into a single, searchable, persistent store — essential for troubleshooting and compliance
Timestamping	Messages include timestamps (when NTP is configured) enabling accurate event sequencing and correlation across devices
Security auditing	Provides an audit trail of who logged in, what commands were run (with AAA logging), and when changes were made

2. Syslog Severity Levels 0–7

Every syslog message is assigned a severity level from 0 (most critical) to 7 (least critical — debug). The severity level determines whether the message is stored or forwarded, depending on the configured logging threshold. When a logging level is set to a given number, all messages at that level and more critical (lower numbers) are logged.

Level	Keyword	Description	Example Event
0	emergencies	System is unusable — most critical; device cannot function	Software failure causing a complete system crash
1	alerts	Immediate action required — serious condition needing urgent attention	Temperature sensor critical threshold exceeded; power supply failure
2	critical	Critical condition — major hardware or software failure	Hardware error; memory allocation failure
3	errors	Error conditions — significant operational errors	Interface error counters exceeded threshold; routing process error
4	warnings	Warning conditions — not immediately harmful but worth attention	Interface flapping; high CPU or memory utilisation warning
5	notifications	Normal but significant conditions — expected events of note	Interface going up or down; OSPF neighbour adjacency change
6	informational	Informational messages — routine operational events	Successful login; ACL permit/deny log entry; DHCP lease assigned
7	debugging	Debug-level messages — very verbose; only for active troubleshooting	Packet-by-packet debug output; routing table calculation detail

Memory aid — "Every Awful Crisis Eventually Warns Naive Individuals Doing debug": The first letter of each word maps to Emergencies, Alerts, Critical, Errors, Warnings, Notifications, Informational, Debugging (levels 0–7). Another common mnemonic: E A C E W N I D.

2.1 How the Logging Level Threshold Works

  Example: logging buffered 6  (informational)

  This logs severity levels 0, 1, 2, 3, 4, 5, AND 6 to the local buffer.
  Level 7 (debugging) is NOT logged — too verbose for normal operations.

  Example: logging trap 4  (warnings)

  This sends only levels 0, 1, 2, 3, AND 4 to the remote syslog server.
  Levels 5, 6, 7 are NOT forwarded — reducing network traffic and server load.

  Rule: Setting level N logs all messages where severity ≤ N
        (0 = most critical, 7 = least critical)

  ┌─────────────────────────────────────────────────────────┐
  │ Logging level 7 (debug):  ALL messages logged           │
  │ Logging level 6 (info):   Levels 0–6 logged            │
  │ Logging level 5 (notif):  Levels 0–5 logged            │
  │ Logging level 4 (warn):   Levels 0–4 logged  ← common  │
  │ Logging level 3 (errors): Levels 0–3 logged            │
  │ Logging level 0 (emerg):  Only level 0 logged           │
  └─────────────────────────────────────────────────────────┘

3. Syslog Message Format

Understanding the format of a syslog message is essential for reading log output on Cisco devices and on syslog servers. Each message follows a predictable structure that encodes the device, time, severity, source facility, and the human-readable description of the event.

3.1 Cisco IOS Syslog Message Format

  Example syslog message:
  *Mar  1 12:34:56.789: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down

  Field breakdown:
  ┌────────────────────┬──────────────────────────────────────────────────────┐
  │ *Mar  1 12:34:56   │ Timestamp — date and time of the event               │
  │                    │ * = time not synchronised via NTP (no leading space  │
  │                    │     = NTP-synchronised and reliable)                 │
  ├────────────────────┼──────────────────────────────────────────────────────┤
  │ %                  │ Percent sign — indicates start of syslog message body│
  ├────────────────────┼──────────────────────────────────────────────────────┤
  │ LINEPROTO          │ Facility — the Cisco IOS process/component that      │
  │                    │ generated the message (e.g., LINEPROTO, OSPF, SYS,   │
  │                    │ SEC_LOGIN, LINK, DUAL for EIGRP)                     │
  ├────────────────────┼──────────────────────────────────────────────────────┤
  │ 5                  │ Severity level — 5 = NOTIFICATION in this example    │
  ├────────────────────┼──────────────────────────────────────────────────────┤
  │ UPDOWN             │ Mnemonic — short code identifying the specific event │
  │                    │ type within the facility                             │
  ├────────────────────┼──────────────────────────────────────────────────────┤
  │ Line protocol on   │ Message text — human-readable description of the     │
  │ Interface ...      │ event with specific details (interface name, state)  │
  └────────────────────┴──────────────────────────────────────────────────────┘

  Full format: %FACILITY-SEVERITY-MNEMONIC: Message text

  More examples:
  %SYS-5-CONFIG_I: Configured from console by admin on vty0
  %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/0 from FULL to DOWN
  %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: baduser] [Source: 10.1.1.99]
  %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

3.2 Syslog Message Fields Explained

Field	Example	Notes
Timestamp	`*Mar 1 12:34:56.789`	Leading `` = not NTP-synchronised; no `` = NTP time, reliable for correlation. Requires `service timestamps log datetime msec` to include milliseconds
Facility	`LINEPROTO`	The IOS subsystem generating the message — helps identify the source component without reading the full text
Severity	`5`	Numeric severity 0–7; higher = less critical; controls filtering and routing to different log destinations
Mnemonic	`UPDOWN`	Short all-caps event code; used in monitoring tools and alerts to match specific event types across different devices
Message text	`Line protocol on Interface...`	Human-readable description; includes specific identifiers (interface name, IP address, username) that vary per event

4. Local vs Remote Logging

Cisco IOS supports four logging destinations, each with its own purpose and trade-offs. These destinations are independent — enabling or disabling one does not affect the others, and each can be configured to a different severity level.

Destination	Command	Description	Persists After Reboot?
Console	`logging console <level>`	Messages printed to the console terminal in real time; visible only during an active console session; high volume can cause console to become unresponsive	N/A — real time only
VTY Lines (Monitor)	`logging monitor <level>` `terminal monitor` (per session)	Messages sent to active SSH/Telnet sessions; requires both the global `logging monitor` setting AND `terminal monitor` on the active session to receive messages	N/A — real time only
Buffer (Local RAM)	`logging buffered <size> <level>`	Messages stored in a circular RAM buffer on the device; viewable with `show logging`; lost on reboot; default buffer is typically 4096–8192 bytes on most Cisco platforms	No — RAM cleared on reboot
Remote Syslog Server	`logging host <ip>` `logging trap <level>`	Messages forwarded to an external syslog server (Splunk, ELK, SolarWinds, SIEM) via UDP 514 (default) or TCP 6514 (secure); persistent, searchable, centralised — the enterprise standard	Yes — stored on the remote server

4.1 The Four Logging Destinations in Context

  Cisco Router / Switch
  ┌─────────────────────────────────────────────────────────────────┐
  │                      Syslog Message Generator                  │
  │                             │                                   │
  │          ┌──────────────────┼──────────────────┐               │
  │          ▼                  ▼                  ▼               │
  │   Console terminal    VTY/SSH Session     RAM Buffer            │
  │   (real-time)         (with terminal      (circular, ~8KB      │
  │                        monitor)            lost on reboot)     │
  └──────────────────────────────────────────────────────────────┬──┘
                                                                 │
                                                    UDP 514 (or TCP 6514)
                                                                 │
                                                                 ▼
                                               ┌─────────────────────────┐
                                               │  Remote Syslog Server   │
                                               │  (Splunk / ELK / SIEM)  │
                                               │  Persistent, searchable │
                                               │  Centralised, all devices│
                                               └─────────────────────────┘

VTY logging requires two steps: Simply configuring

logging monitor
              informational

globally is not enough. Each individual SSH or Telnet session must also run terminal monitor to receive log messages. Without this, the session will not display syslog output even if global monitor logging is enabled. The terminal no monitor command stops messages for the current session only.

5. Syslog Transport – UDP vs TCP

Syslog was originally designed to use UDP port 514 — a connectionless, unreliable transport. This means messages can be lost in transit with no notification. For security-conscious and compliance-driven environments, syslog over TCP port 514 or 6514 (with TLS) provides reliable delivery and encryption.

Transport	Port	Reliability	Encryption	Use Case
UDP	514	Unreliable — messages can be silently lost during congestion	None — plaintext	Standard syslog; internal networks; low-sensitivity logs
TCP	514 or 601	Reliable — connection-oriented; lost messages trigger retransmission	None — plaintext	Environments requiring message delivery guarantee
TLS (TCP)	6514	Reliable — TCP with TLS	Yes — encrypted and authenticated	Compliance environments (PCI-DSS, HIPAA); security-sensitive logs

UDP 514 is the default on Cisco IOS. For critical security logs (authentication failures, privilege escalation), consider configuring TCP syslog or directing these events to a SIEM via an encrypted channel. Note that standard Cisco IOS logging host uses UDP; TCP syslog requires the logging host <ip> transport tcp port 514 syntax.

6. Cisco IOS Syslog Configuration

The following is a complete, production-ready syslog configuration covering all four logging destinations, timestamps, source interface, and remote server forwarding.

! ══════════════════════════════════════════════════════════════════
! Step 1: Enable logging and set global log level
! ══════════════════════════════════════════════════════════════════
logging on ! Enabled by default; explicit is cleaner

! ══════════════════════════════════════════════════════════════════
! Step 2: Add timestamps to log messages (NTP must also be configured)
! ══════════════════════════════════════════════════════════════════
service timestamps log datetime msec localtime show-timezone
! datetime = include date and time
! msec = include milliseconds (important for event sequencing)
! localtime = use local timezone offset rather than UTC
! show-timezone = include timezone name in the timestamp

! ══════════════════════════════════════════════════════════════════
! Step 3: Console logging (level 4 = warnings and above)
! ══════════════════════════════════════════════════════════════════
logging console 4

! ══════════════════════════════════════════════════════════════════
! Step 4: VTY / Monitor logging (level 6 = informational)
! ══════════════════════════════════════════════════════════════════
logging monitor 6
! Remember: each SSH session must also run 'terminal monitor' to see messages

! ══════════════════════════════════════════════════════════════════
! Step 5: Local RAM buffer (store recent events on device)
! ══════════════════════════════════════════════════════════════════
logging buffered 65536 6 ! 64 KB buffer, informational level
! Buffer size in bytes — increase on busy devices; default is 4096–8192

! ══════════════════════════════════════════════════════════════════
! Step 6: Remote syslog server
! ══════════════════════════════════════════════════════════════════
logging host 10.0.0.200 ! IP of syslog server (UDP 514 default)
logging trap 6 ! Send levels 0–6 to syslog server
logging source-interface Loopback0 ! Use loopback IP as source (stable)

! Optional — TCP syslog for reliable delivery:
logging host 10.0.0.200 transport tcp port 514

! Optional — second syslog server for redundancy:
logging host 10.0.0.201

! ══════════════════════════════════════════════════════════════════
! Step 7: Suppress duplicate messages (avoid log flooding)
! ══════════════════════════════════════════════════════════════════
logging rate-limit 100 ! Max 100 messages/sec to console
no logging console ! Or disable console logging on busy devices
! to prevent console flooding

! ══════════════════════════════════════════════════════════════════
! Step 8: Enable AAA command logging (audit trail)
! ══════════════════════════════════════════════════════════════════
archive
log config
logging enable
notify syslog contenttype plaintext
hidekeys ! Hides passwords in logged config commands

6.1 NTP and Syslog – Why They Must Work Together

Syslog timestamps are only meaningful if the device clock is accurate. Without NTP, each device has its own uncorrected clock — log timestamps from different devices cannot be correlated. A message showing 09:14:22 on Router-A and 11:32:07 on Router-B for the same event makes troubleshooting nearly impossible. Always configure NTP before enabling remote syslog.

  Without NTP:
  Router-A syslog: *Mar 1 00:12:34 %LINK-5-UPDOWN: Gi0/0 down
  Router-B syslog: *Mar 1 04:57:12 %OSPF-5-ADJCHG: Nbr down
  (same event, completely different reported times — uncorrelated)

  With NTP (both devices synced to NTP server):
  Router-A syslog:  Mar 14 09:14:22.412 %LINK-5-UPDOWN: Gi0/0 down
  Router-B syslog:  Mar 14 09:14:22.630 %OSPF-5-ADJCHG: Nbr down
  (200ms apart — clearly the interface going down caused OSPF to drop ✓)

7. Syslog vs SNMP Traps

Both syslog and SNMP traps are used to alert administrators and management systems about network events. They are complementary — not mutually exclusive — and serve different purposes in a network management architecture.

Feature	Syslog	SNMP Traps
Purpose	Human-readable log messages for troubleshooting, auditing, and compliance; narrative description of events	Structured alerts for automated monitoring systems; triggers actions in NMS (Network Management Systems) such as SolarWinds, Nagios, PRTG
Format	Free-form text — readable by humans; searchable in log management tools (Splunk, ELK)	Structured binary (ASN.1 BER) — machine-readable; parsed by NMS using MIB definitions
Protocol / Port	UDP 514 (default) or TCP 514/6514	UDP 162 (SNMP trap receiver)
Reliability	UDP — unreliable by default; TCP option available	UDP — unreliable; SNMP Inform (SNMPv2c/v3) adds acknowledgement
Security	Plaintext (UDP/TCP); encrypted with TLS (port 6514)	SNMPv1/v2c: community string (weak); SNMPv3: authentication + encryption
Granularity	Very granular — every event type generates a distinct syslog message with full detail; 8 severity levels	Limited to defined OIDs — only events with a corresponding MIB trap definition are reported
Volume	Can be very high — level 6/7 generates thousands of messages per hour on active devices	Lower — traps only for significant state changes defined in MIBs
Best used for	Troubleshooting, security auditing, compliance logging, forensic investigation, configuration change tracking	Real-time automated alerting — interface down, threshold exceeded, device unreachable; triggers paging/email/ticketing systems

7.1 The Recommended Combined Approach

  Network Device (Router / Switch)
          │
          ├── Syslog (UDP 514) ────────────────► SIEM / Log Server (Splunk, ELK)
          │   Levels 0–6 — all significant events    Human-readable, searchable,
          │   Full narrative event descriptions       compliance archive
          │
          └── SNMP Traps (UDP 162) ───────────► NMS (SolarWinds, Nagios, PRTG)
              Critical state changes only            Automated alerting, dashboards
              Interface down, threshold crossed       Paging, email, tickets

  ─────────────────────────────────────────────────────────────────────────────
  Rule of thumb:
  Use SYSLOG when you need to know WHAT happened and WHY (troubleshooting)
  Use SNMP TRAPS when you need to know IMMEDIATELY that something went wrong
  (automated alerting and remediation)
  ─────────────────────────────────────────────────────────────────────────────

8. Verification Commands

Command	What It Shows
`show logging`	Full logging configuration — enabled destinations, configured levels, buffer size, syslog server IPs, and the contents of the local log buffer
`show logging \| include OSPF`	Filters the log buffer output to show only lines containing "OSPF" — useful for finding specific events in a busy log
`show logging \| begin Mar 14`	Shows log buffer output starting from a specific date — useful for finding events around a known incident time
`show running-config \| section logging`	Shows all logging-related configuration lines in the running config
`clear logging`	Clears the local RAM log buffer — use with caution, as this permanently removes recent event history from the device
`debug logging`	Enables real-time display of logging messages being generated — use in lab only; very verbose in production
`terminal monitor`	Enables syslog output to the current VTY (SSH/Telnet) session; required in addition to the global `logging monitor` setting
`terminal no monitor`	Stops syslog output to the current session only; does not affect global logging configuration

8.1 Sample Output – show logging

  Router# show logging

  Syslog logging: enabled (0 messages dropped, 0 messages rate-limited,
                  0 flushes, 0 overruns, xml disabled, filtering disabled)

  No Active Message Discriminator.
  No Inactive Message Discriminator.

      Console logging: level warnings, 47 messages logged, xml disabled,
                       filtering disabled
      Monitor logging: level informational, 0 messages logged, xml disabled,
                       filtering disabled
      Buffer logging:  level informational, 1842 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, 1842 message lines logged
          Logging to 10.0.0.200  (udp port 514, audit disabled,
               link up),
               1842 message lines logged,
               0 message lines rate-limited,
               0 message lines dropped-by-MD,
               xml disabled, sequence number disabled
               filtering disabled

  Log Buffer (65536 bytes):
  Mar 14 09:14:22.412 TZ: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down
  Mar 14 09:14:22.630 TZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
  Mar 14 09:14:23.105 TZ: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/1 from FULL to DOWN
  Mar 14 09:15:01.004 TZ: %SYS-5-CONFIG_I: Configured from console by admin on vty0

9. Troubleshooting Syslog

Symptom	Likely Cause	Fix
No log messages visible during SSH session	`terminal monitor` not run in the current session; or `logging monitor` level is too restrictive for the event	Run `terminal monitor` in the session; verify `logging monitor 6` is configured globally
Log timestamps show `*Mar 1 00:...` (wrong time)	NTP is not configured or not synchronised; device is using its hardware clock which starts from a default value on reboot	Configure NTP: `ntp server <ip>`; verify with `show ntp status`; ensure `service timestamps log datetime msec` is configured
Remote syslog server not receiving messages	Wrong syslog server IP; firewall blocking UDP 514; `logging trap` level set too high (e.g., level 0 — only emergencies sent); or `logging host` not configured	Verify `show logging` shows the correct server IP and trap level; test connectivity with `ping 10.0.0.200 source Loopback0`; check firewall rules for UDP 514
Console floods with log messages making CLI unusable	Console logging level set to 6 (informational) or 7 (debugging) on a busy device; or `debug` commands still active	Reduce console level: `logging console 4`; or disable console logging entirely: `no logging console`; stop debug with `undebug all`
Log buffer fills up too quickly; oldest events lost	Buffer size too small for the volume of events being generated; default 4096 bytes fills in minutes on a busy device	Increase buffer size: `logging buffered 262144 6` (256 KB); and configure a remote syslog server for persistent storage
Messages logged without source IP — hard to identify device	`logging source-interface` not configured; messages use the outbound interface IP as the source — which may change with routing	Configure a stable loopback: `logging source-interface Loopback0` — ensures all syslog messages from this device arrive at the server with the same consistent source IP

10. Key Terms Quick Reference

Term	Definition
Syslog	A standardised protocol (RFC 5424 / RFC 3164) for generating, storing, and forwarding event log messages from network devices; uses UDP 514 by default
Severity Level	A numeric rating 0–7 assigned to each syslog message indicating its urgency; 0 = most critical (Emergency), 7 = least critical (Debug); logging level N captures all messages where severity ≤ N
Facility	The IOS subsystem or process that generated the message (e.g., LINEPROTO, OSPF, SEC_LOGIN, SYS); appears in the `%FACILITY-SEVERITY-MNEMONIC` message format
Mnemonic	A short all-caps event code within a facility (e.g., UPDOWN, ADJCHG, CONFIG_I) that identifies the specific event type; used in monitoring tools to match and alert on specific event patterns
logging buffered	Stores syslog messages in a circular RAM buffer on the device; viewable with `show logging`; contents are lost on reboot
logging host	Forwards syslog messages to a remote syslog server IP address; the enterprise standard for persistent, centralised log storage
logging trap	Sets the severity level threshold for messages forwarded to the remote syslog server; "trap" refers to syslog forwarding (not to be confused with SNMP traps)
logging console	Controls which severity levels are printed to the physical console terminal; can overload the console on busy devices if set too low (verbose)
logging monitor	Controls severity levels sent to VTY (SSH/Telnet) sessions; requires `terminal monitor` on each individual session to activate
terminal monitor	Enables syslog message display for the current SSH/Telnet session only; does not change global logging configuration
service timestamps log datetime msec	Adds accurate date, time, and millisecond timestamps to syslog messages; requires NTP synchronisation to be meaningful for cross-device event correlation
logging source-interface	Specifies which interface IP address is used as the source of syslog messages sent to remote servers; Loopback0 is recommended for stability
SNMP Trap	A structured alert sent from a network device to an NMS (Network Management System) via UDP 162; complements syslog — traps trigger automated alerts while syslog provides detailed narrative logs

11. Syslog – Practice Quiz

1. A network administrator configures `logging buffered 6` on a Cisco router. Which severity levels will be stored in the local log buffer?

A. Only severity level 6 (informational) B. Severity levels 6 and 7 only C. Severity levels 0 through 6 — the logging level sets the maximum severity to capture; all messages at that level and more critical (lower number) are stored D. All severity levels 0 through 7 — level 6 means capture everything except debugging

Correct answer is C. The logging level works as a threshold: configuring level 6 (informational) means "capture all messages with severity 6 or more critical." Since severity numbers run from 0 (most critical) to 7 (least critical), level 6 captures levels 0, 1, 2, 3, 4, 5, and 6. Level 7 (debugging) is NOT captured. Option D is incorrect because level 6 specifically excludes level 7 debug messages — that is the most common reason to stop at level 6, as debug output would fill the buffer almost instantly on an active device.

2. An engineer SSHes into a router and runs `logging monitor 6` globally, but no syslog messages appear in the SSH session. What is the most likely reason?

A. SSH sessions cannot display syslog messages — use the console port instead B. The engineer has not run terminal monitor in the current session — global logging monitor enables VTY logging but each session must individually activate it with terminal monitor C. The log buffer is full — clear it with clear logging before messages will appear in the VTY session D. The logging level 6 is too high — change it to logging level 3 to make messages appear

Correct answer is B. VTY logging requires two separate steps to work. First, the global command

logging monitor
                  <level>

must be configured — this enables the monitor logging destination and sets the severity filter. Second, within each active SSH or Telnet session, the user must run terminal monitor. Without this second command, the session will not receive messages even if the global setting is correct. terminal monitor only affects the current session and is not saved to the configuration.

3. What does the asterisk (`*`) at the beginning of a Cisco syslog timestamp indicate?

A. The device clock is not synchronised with an NTP server — the timestamp may be inaccurate and should not be relied upon for precise event correlation B. The message is a critical alert (severity 0 or 1) that requires immediate attention C. The message was generated by a debug command and may be suppressed D. The message was received from a remote syslog source rather than generated locally

Correct answer is A. The leading asterisk in a Cisco syslog timestamp is a warning flag indicating the device's clock has not been synchronised via NTP. Without NTP synchronisation, the device clock starts from a default hardware value on reboot (typically *Mar 1 00:00:00) and drifts over time. Messages with this asterisk cannot be reliably correlated with messages from other devices. A message without the asterisk means the timestamp came from an NTP-synchronised clock and is accurate.

4. In the syslog message `%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/0 from FULL to DOWN`, what do the three components `OSPF`, `5`, and `ADJCHG` represent?

A. Protocol name, OSPF process ID, and event type B. Destination, port number, and source address C. Interface, VLAN ID, and routing table code D. Facility (the IOS subsystem that generated the message), severity level (5 = notification), and mnemonic (the specific event type code within the facility)

Correct answer is D. Cisco syslog messages follow the format %FACILITY-SEVERITY-MNEMONIC: message text. In this example: OSPF is the facility (the OSPF routing process generated this message), 5 is the severity level (notifications — normal but significant condition), and ADJCHG is the mnemonic identifying the specific event type (adjacency change). The message text that follows provides the human-readable detail: which OSPF process, which neighbour, on which interface, and what the state transition was.

5. What is the main disadvantage of using the default UDP transport for syslog messages to a remote server?

A. UDP limits syslog messages to 512 bytes, truncating long log entries B. UDP is connectionless and unreliable — syslog messages can be silently lost during network congestion with no notification or retransmission C. UDP cannot traverse firewalls, making remote syslog impossible on segmented networks D. UDP syslog encrypts messages by default, requiring the server to decrypt them before storing

Correct answer is B. The original syslog protocol (RFC 3164) was designed to use UDP 514 — a lightweight, fire-and-forget transport. UDP provides no delivery confirmation, sequencing, or retransmission. During periods of network congestion or when the syslog server is overloaded, messages are silently dropped with no indication to the sender or receiver. For environments where complete log capture is required (security audits, PCI-DSS compliance), TCP syslog (port 514 or 601) or TLS syslog (port 6514) should be used instead.

6. What is the key operational difference between syslog and SNMP traps for network monitoring?

A. Syslog uses TCP; SNMP traps use UDP — syslog is therefore more reliable B. Syslog is used only for security events; SNMP traps handle all other device events C. Syslog provides human-readable narrative logs for troubleshooting and auditing; SNMP traps provide structured machine-readable alerts that trigger automated actions in NMS platforms — both are complementary and used together D. SNMP traps carry more detailed information than syslog because they include the full MIB object tree of the device

Correct answer is C. Syslog and SNMP traps serve complementary roles. Syslog generates free-text event narratives that humans read when troubleshooting or investigating incidents — the format is designed for readability, searchability, and audit trails. SNMP traps generate structured binary alerts (ASN.1 BER format defined by MIBs) that Network Management Systems (NMS) parse programmatically to trigger dashboards, alerts, and automated remediation. Enterprise networks typically run both simultaneously — syslog to a SIEM for investigation, SNMP traps to an NMS for real-time alerting.

7. Why is it best practice to configure `logging source-interface Loopback0` on a Cisco router?

A. Without a source interface, syslog packets use the outbound interface IP as the source — which can change if routes change. A loopback interface always has the same IP regardless of which physical path is used, giving the syslog server a stable, consistent identifier for this device B. Loopback interfaces have lower latency than physical interfaces, improving syslog delivery speed C. Syslog UDP packets cannot be sent from physical interfaces — only from logical loopback interfaces D. The syslog server requires a loopback source IP to decrypt the messages before processing

Correct answer is A. Without logging source-interface, the router uses the IP address of whichever interface the syslog UDP packet exits from as the source address. If that interface goes down and the syslog packet exits via a different path, the source IP changes — the syslog server now sees messages from a different IP and may not correlate them to the same device. A loopback interface (e.g., Loopback0 with IP 1.1.1.1/32) is always up as long as the router is running, and its IP never changes — providing a stable, permanent identity for the device in all syslog messages.

8. An engineer wants to investigate a network outage that occurred two hours ago. The router's local log buffer shows no relevant events from that time. What is the most likely cause?

A. Syslog was disabled two hours ago by a scheduled maintenance task B. The logging level was set to 0 (emergencies) so the relevant events were not captured C. The events occurred on a different router that was not part of the investigation D. The local log buffer is circular — new messages overwrite old ones when the buffer fills; two hours of high-activity logging may have overwritten the relevant events. A remote syslog server would have retained the complete history

Correct answer is D. The local RAM log buffer is a circular buffer — when it fills, the oldest entries are overwritten by new ones. On a busy device, a default 4096-byte buffer might fill in minutes. Even a 64 KB buffer can fill in hours during a network event that generates many log messages. The events from two hours ago are simply gone — overwritten. This is precisely why remote syslog servers are essential in production: they provide persistent, long-term storage that survives the device's buffer cycling. It also highlights the importance of sizing the local buffer appropriately and configuring a remote server.

9. What is the purpose of the `service timestamps log datetime msec` command?

A. It encrypts syslog message timestamps to prevent tampering B. It adds accurate date, time, and millisecond precision timestamps to every syslog message — critical for correlating events across multiple devices when investigating an incident C. It configures the device to send syslog messages every millisecond for real-time monitoring D. It synchronises the device clock with an NTP server automatically when syslog events occur

Correct answer is B. Without service timestamps, Cisco IOS syslog messages include only a basic uptime counter (e.g., 00:12:34) which is useless for absolute event correlation. The

service timestamps log datetime
                  msec

command adds the full date and time with millisecond precision to every message. The msec option is particularly important — many network events (interface flaps, routing changes) happen in milliseconds, and without sub-second precision it is impossible to determine the exact sequence of events across devices. This command works best when NTP is also configured to keep the device clock accurate.

10. A security team needs to be automatically alerted within seconds when a core router's interface goes down, with an alert sent to their monitoring platform that can trigger a page. Separately, they need a full searchable log of all authentication attempts for compliance. Which combination of technologies best meets both requirements?

A. Syslog for both — configure syslog to the monitoring platform and a SIEM; the monitoring platform can parse syslog messages and trigger alerts B. SNMP traps for both — SNMP traps include authentication details and can be stored in the NMS for compliance purposes C. SNMP traps to the NMS for immediate automated alerting on interface-down events; syslog to a SIEM for the complete searchable authentication audit trail — each technology is used for what it does best D. Debug logging to the console for real-time alerts; TFTP backups of the running config for compliance records

Correct answer is C. This question captures the real-world complementary relationship between SNMP traps and syslog. SNMP traps are ideal for the interface-down alert: they fire immediately, are structured for NMS parsing, and can trigger automated paging/email/ticketing workflows. Syslog is ideal for the compliance audit trail: it captures every authentication event (login success/failure, privilege escalation) in a human-readable, searchable format that regulators and auditors can review. Running both simultaneously is the enterprise standard — each handles what it does best, and neither replaces the other.

← Back to Home