Syslog Server Configuration – Complete Setup and Troubleshooting Guide

1. What Is a Syslog Server?

A syslog server is a centralised host that receives, stores, indexes, and manages log messages sent by network devices (routers, switches, firewalls), servers, and applications using the Syslog protocol (RFC 5424/3164). Rather than each device keeping its own local buffer — which is small, volatile (lost on reload), and inaccessible remotely — a syslog server aggregates all logs from the entire infrastructure into one searchable, persistent archive.

  Without centralised syslog:
  Router1 buffer (4 KB) — lost on reload, only 1 engineer can view at a time
  Switch1 buffer (4 KB) — inaccessible remotely without SSH
  Firewall buffer — separate system, no correlation with other devices

  With centralised syslog server:
  Router1 ──→
  Switch1 ──→  Syslog Server (192.168.1.100)  → persistent storage
  Firewall──→                                  → searchable across all devices
  Server1 ──→                                  → correlation by timestamp
                                               → automated alerts

Benefits of a centralised syslog server: long-term log retention beyond the device buffer; simultaneous visibility for multiple engineers; cross-device event correlation by timestamp; automated alerting on severity thresholds; compliance with regulatory requirements (PCI-DSS, HIPAA, SOX); tamper-resistant log storage (an attacker who clears device logs cannot erase the server copies).

2. Syslog Protocol Fundamentals

Transport and Ports

Transport	Port	Characteristics	Use Case
UDP	514	Connectionless; fire-and-forget; no delivery acknowledgement; fast but messages can be silently lost if the network is congested or the server is overloaded	Default for most Cisco IOS devices; LAN environments where occasional loss is acceptable; low-overhead bulk logging. See Syslog Severity Levels
TCP	514	Connection-oriented; guaranteed delivery; messages are not lost; requires a persistent connection between device and server	Environments where log completeness is critical; security-sensitive deployments; when combined with TLS for encrypted transport
TCP+TLS	6514	Encrypted and authenticated transport; standard port for syslog over TLS (RFC 5425); prevents eavesdropping and tampering on the log stream	Compliance environments (PCI-DSS, HIPAA); WAN log forwarding; any environment where log data is sensitive

Syslog Message Format — PRI Value Decoded

  Full syslog message:
  <134>Dec 15 10:30:45 Router1 %SYS-3-CRITICAL: Temperature threshold exceeded
  │    │               │        │
  │    │               │        └─ Message text (IOS format: %FACILITY-SEV-MNEMONIC)
  │    │               └─ Hostname of the sending device
  │    └─ Timestamp (when the event occurred on the device)
  └─ PRI (Priority) value — calculated as: (Facility × 8) + Severity

  Decoding PRI=134:
  Severity = 134 mod 8 = 6 (Informational)
  Facility  = 134 / 8  = 16 (local0)

  Common Syslog Facility values:
  0  = kern    (kernel messages)
  1  = user    (user-level messages)
  4  = auth    (security/authorisation)
  16 = local0  (locally defined — Cisco uses local0–local7)
  17 = local1
  ...
  23 = local7

  The PRI value encodes both facility and severity in a single number,
  allowing syslog servers to route and filter on either dimension.

3. Installing a Syslog Server

Linux — rsyslog (Most Common)

  # Install rsyslog (Ubuntu/Debian):
  sudo apt update
  sudo apt install rsyslog -y

  # Install rsyslog (RHEL/CentOS/Rocky):
  sudo dnf install rsyslog -y

  # Enable and start the service:
  sudo systemctl enable rsyslog
  sudo systemctl start rsyslog

  # Check service status:
  sudo systemctl status rsyslog

  # Verify version:
  rsyslogd -v

macOS

  brew install rsyslog
  # macOS ships with its own syslog daemon (syslogd);
  # rsyslog is installed separately for network reception.

Windows — Options

Tool	Type	Best For	Notes
Kiwi Syslog Server	Free / Paid	Small to medium networks; easy GUI setup	Free tier limited to 5 inputs; paid version includes filtering, alerting, database logging
SolarWinds Syslog Server	Free (standalone) or bundled	Enterprise networks already using SolarWinds NPM	Integrates with SolarWinds dashboards and alerting
Graylog (on Windows via Docker)	Open-source	Search, dashboards, stream rules across many sources	Most powerful option; requires Docker or full install

4. Configuring the rsyslog Server (Linux)

Step 1 — Enable UDP and TCP Listening

Edit /etc/rsyslog.conf to enable network reception. By default rsyslog only listens for local messages; these lines activate it as a network syslog receiver:

  # /etc/rsyslog.conf

  # ── Enable UDP reception (port 514) ──────────────────────────────
  module(load="imudp")
  input(type="imudp" port="514")

  # ── Enable TCP reception (port 514) ──────────────────────────────
  module(load="imtcp")
  input(type="imtcp" port="514")

  # ── Apply the configuration ───────────────────────────────────────
  sudo systemctl restart rsyslog

  # ── Verify the server is listening ────────────────────────────────
  sudo ss -tulnp | grep 514
  # Should show: udp UNCONN 0.0.0.0:514   LISTEN rsyslogd
  #              tcp LISTEN 0.0.0.0:514   LISTEN rsyslogd

Step 2 — Configure Per-Host Log Storage

  # Store each device's logs in a separate file by hostname:
  $template RemoteLogs,"/var/log/remote/%HOSTNAME%.log"
  *.* ?RemoteLogs

  # This creates files like:
  # /var/log/remote/Router1.log
  # /var/log/remote/Switch1.log
  # /var/log/remote/Firewall1.log

  # Create the directory first:
  sudo mkdir -p /var/log/remote
  sudo chown syslog:adm /var/log/remote

  # Restart to apply:
  sudo systemctl restart rsyslog

  # Live tail of a device's log:
  tail -f /var/log/remote/Router1.log

Step 3 — Configure Log Rotation

  # /etc/logrotate.d/rsyslog-remote
  /var/log/remote/*.log {
      daily              # rotate every day
      rotate 30          # keep 30 days of logs
      compress           # gzip old files
      delaycompress      # keep most recent rotation uncompressed
      missingok          # don't fail if log is missing
      notifempty         # don't rotate empty files
      postrotate
          /usr/lib/rsyslog/rsyslog-rotate
      endscript
  }

  # Test rotation configuration:
  sudo logrotate --debug /etc/logrotate.d/rsyslog-remote

Step 4 — Filter Logs by Severity

  # Store only critical and above (levels 0–2) in a dedicated file:
  if $syslogseverity <= 2 then /var/log/critical.log

  # Store warnings and above (levels 0–4) in a warning file:
  if $syslogseverity <= 4 then /var/log/warnings.log

  # Store all logs from a specific device:
  if $fromhost-ip == '192.168.1.1' then /var/log/remote/Router1.log

  # Drop debug messages (level 7) to reduce noise:
  if $syslogseverity == 7 then ~

5. Configuring Network Devices to Forward Logs

Cisco IOS — Router or Switch

! ── Point to the syslog server ──────────────────────────────────
Router(config)# logging host 192.168.1.100
! Sends syslog UDP messages to 192.168.1.100 (default port 514)

! ── Set severity level filter for server ────────────────────────
Router(config)# logging trap informational
! Sends levels 0–6 (Emergency through Informational) to the server
! Common choices: warnings (0–4), informational (0–6), debugging (0–7)

! ── Set a stable source interface ───────────────────────────────
Router(config)# logging source-interface GigabitEthernet0/0
! All syslog UDP packets originate from this interface's IP address.
! Use a loopback for maximum stability:
Router(config)# logging source-interface Loopback0

! ── Add precise timestamps ───────────────────────────────────────
Router(config)# service timestamps log datetime msec

! ── Optional: use TCP for reliable delivery ─────────────────────
Router(config)# logging host 192.168.1.100 transport tcp port 514

! ── Verify the configuration ─────────────────────────────────────
Router# show logging
! Look for: "Trap logging: level informational, N message lines logged"
! And: "Logging to 192.168.1.100 (udp port 514, ..., link up)"

Linux Client Forwarding

  # Edit /etc/rsyslog.conf on the CLIENT machine:

  # Forward all messages to syslog server via UDP:
  *.* @192.168.1.100:514

  # Forward all messages via TCP (more reliable):
  *.* @@192.168.1.100:514
  # Single @ = UDP, Double @@ = TCP

  # Forward only critical and above via TCP:
  *.crit @@192.168.1.100:514

  # Restart the client rsyslog:
  sudo systemctl restart rsyslog

Windows Event Forwarding

  Windows Event Forwarding (WEF) to a Windows Collector:
  1. Open Event Viewer → Subscriptions → Create Subscription
  2. Set subscription type: Collector Initiated or Source Initiated
  3. Add source computers (the machines that will forward events)
  4. Select event types to forward (Security, System, Application)

  For forwarding Windows events to a Linux syslog server:
  Use NXLog or Winlogbeat (part of the Elastic stack):
  - NXLog Community Edition is free and supports syslog output
  - Configure output module to send to 192.168.1.100:514 (UDP)

6. Verifying Syslog Communication

  ── On the syslog server ─────────────────────────────────────────────
  # Watch live messages arriving from a specific device:
  tail -f /var/log/remote/Router1.log

  # Search for specific events:
  grep "UPDOWN" /var/log/remote/Router1.log

  # Count messages received in the last 5 minutes:
  awk -v d="$(date --date='5 minutes ago' '+%b %e %H:%M')" \
    '$0 >= d' /var/log/remote/Router1.log | wc -l

  # Check if the server port is open and receiving:
  sudo ss -tulnp | grep 514
  sudo tcpdump -i eth0 udp port 514 -vv      ← captures arriving packets
  (stop with Ctrl+C after seeing expected traffic)

  ── On the Cisco device ──────────────────────────────────────────────
  Router# show logging
  ! Check output for:
  ! "Trap logging: level informational, 47 message lines logged"
  ! "Logging to 192.168.1.100 (udp port 514, audit disabled, link up)"
  ! "link up" confirms the server is reachable

  Router# show logging | include sending
  ! Filters output to show only lines referencing outbound log delivery

  ── Test from Linux client ────────────────────────────────────────────
  # Send a manual test message using the logger command:
  logger -p local3.err "Test message from Linux client"
  # -p local3.err = facility local3, severity error (level 3)
  # Verify receipt on server: grep "Test message" /var/log/remote/$(hostname).log

7. Securing Syslog

Firewall Rules — Allow Only Trusted Sources

  # UFW (Ubuntu): allow syslog only from the LAN subnet:
  sudo ufw allow from 192.168.1.0/24 to any port 514 proto udp
  sudo ufw allow from 192.168.1.0/24 to any port 514 proto tcp

  # Block syslog from untrusted networks:
  sudo ufw deny from any to any port 514

  # Check the rules:
  sudo ufw status verbose

  # iptables equivalent (permanent via iptables-persistent):
  sudo iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 514 -j ACCEPT
  sudo iptables -A INPUT -p udp --dport 514 -j DROP

Enable TLS Encryption (Syslog over TCP+TLS)

Plain-text UDP syslog sends log messages in clear text over the network — anyone capturing traffic can read them. For security-sensitive environments, encrypt syslog using TLS (RFC 5425, standard port TCP 6514).

  ── On the syslog server (rsyslog + TLS) ──────────────────────────

  # Install required TLS module:
  sudo apt install rsyslog-gnutls -y

  # Add to /etc/rsyslog.conf:
  module(load="gtls")                          # load TLS module

  # TLS listener on port 6514:
  input(type="imtcp"
        port="6514"
        StreamDriver.Name="gtls"
        StreamDriver.Mode="1"
        StreamDriver.AuthMode="x509/name")

  # TLS certificate paths:
  global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/ssl/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/ssl/certs/server.pem"
    DefaultNetstreamDriverKeyFile="/etc/ssl/private/server.key"
  )

  ── Client (rsyslog + TLS to server) ──────────────────────────────
  # Forward using TLS (@@= TCP, add StreamDriver settings):
  action(type="omfwd"
         Target="192.168.1.100"
         Port="6514"
         Protocol="tcp"
         StreamDriver="gtls"
         StreamDriverMode="1"
         StreamDriverAuthMode="x509/name"
         StreamDriverPermittedPeers="syslog-server.example.com")

Security Best Practices Summary

Control	Why It Matters	Implementation
Restrict UDP/TCP 514 to trusted IPs	Prevents log injection from untrusted sources — an attacker could flood the server with false logs to hide real events	Firewall rules allowing only management subnet to reach port 514
Use TLS for WAN log forwarding	Logs crossing untrusted networks are readable without encryption — can expose device types, credentials in messages, network topology	TCP+TLS on port 6514 with certificate authentication
Set `logging source-interface Loopback0`	If the source IP changes (due to routing), the syslog server may attribute logs to the wrong device or fail to match them to a known sender	Loopback interface is always up and its IP never changes
Write-protect log storage	A compromised admin account clearing logs on the device cannot also delete the server copies if the storage is append-only or write-protected	Use immutable storage, WORM drives, or cloud write-once buckets for compliance logs

8. Centralised Log Management Tools

rsyslog is excellent for collecting and storing logs, but it has no search UI, dashboards, or real-time alerting. For production environments, logs collected by rsyslog are typically forwarded to a log management platform.

Tool	Type	Key Capabilities	Best For
Graylog	Open-source (community) / Enterprise	Syslog/GELF input, full-text search, stream rules, dashboards, alerting, LDAP auth	SME and enterprise networks; free community edition handles millions of messages per day
Splunk	Commercial (free tier to 500 MB/day)	Extremely powerful SPL query language, SIEM capabilities, machine learning, app marketplace, pre-built dashboards for network devices	Enterprise SOC, security monitoring, compliance reporting; industry standard for SIEM
ELK Stack	Open-source	Elasticsearch (indexing + search), Logstash (log pipeline + transformation), Kibana (visualisation + dashboards)	High-volume environments; highly customisable; strong DevOps ecosystem integration
Loki + Grafana	Open-source	Label-based log indexing (lightweight), Grafana dashboards, LogQL query language, integrates with Prometheus metrics	Cloud-native and containerised environments; lower resource footprint than ELK

Graylog Flow Example

  Network devices → syslog UDP/TCP 514 → rsyslog (collector)
                                            │
                                            ▼
                                        Graylog GELF input (port 12201)
                                            │
                                            ▼
                                        Stream rules (route by severity / source)
                                            │
                        ┌───────────────────┼────────────────────┐
                        ▼                   ▼                    ▼
                   Dashboard           Alert email/Slack    Archive (long-term)
                   (live view)         (CRITICAL events)    (compliance)

9. NTP Time Synchronisation

Accurate timestamps are not optional — they are the foundation of useful log analysis. Without NTP, each device has its own drifted clock, making cross-device event correlation impossible. When investigating an incident, you need to see that Router1's interface went down at 14:03:12.001 and the OSPF adjacency dropped at 14:03:12.345 — a 344 ms gap that tells a clear causal story. Without NTP, those events might show 6 hours apart on different devices.

── NTP on the syslog server (Linux) ──────────────────────────────
# Install chrony (recommended over ntpd on modern Linux):
sudo apt install chrony -y
sudo systemctl enable chrony
sudo systemctl start chrony

# Check sync status:
chronyc tracking
# Look for: "System time: X.XXXXXXX seconds slow/fast of NTP time"
# Reference ID should match your configured NTP server

chronyc sources -v
# ^ = selected NTP source; * = currently synced

── NTP on Cisco devices ──────────────────────────────────────────
Router(config)# ntp server pool.ntp.org ! use public NTP pool
Router(config)# ntp server 192.168.1.200 ! or internal NTP server

! Verify sync:
Router# show ntp status
! Look for: "Clock is synchronised, stratum X"
! Stratum = number of hops from the atomic reference; lower = more accurate

Router# show ntp associations
! * prefix = selected source (clock is synced to this one)

── Add timestamp precision to Cisco logs ─────────────────────────
Router(config)# service timestamps log datetime msec
! Adds: date, time, milliseconds to every syslog message
! Without this, messages show only device uptime, making correlation hard

── Signs of an NTP problem in show logging output ────────────────
*Mar 1 00:05:14.231: %OSPF-5-ADJCHG: ...
│
└─ The * before the date means the clock is NOT synced with NTP.
"Mar 1" at system startup is the default time.
Fix: configure NTP and wait for sync.

10. Monitoring and Alerting

Linux Command-Line Alerting

  # Send an email when a CRITICAL message is logged:
  grep -i "CRITICAL" /var/log/remote/Router1.log | \
    mail -s "ALERT: Critical event on Router1" [email protected]

  # Continuous monitoring — alert on new CRITICAL lines:
  tail -f /var/log/remote/Router1.log | grep --line-buffered "CRITICAL" | \
    while read line; do echo "$line" | mail -s "SYSLOG ALERT" [email protected]; done

  # Watch for interface flapping:
  grep "UPDOWN" /var/log/remote/*.log | grep "changed state to down" | \
    tail -20
  # Shows the 20 most recent interface-down events across all devices

Enterprise Alerting Tools

Tool	Alert Trigger Example	Notification Method
SolarWinds	Alert when `%LINK-3-UPDOWN` appears on any device; alert on severity 0–2 messages	Email, SMS, SNMP trap, ServiceNow ticket creation
PRTG	Alert when log contains "High CPU" or "Temperature" above threshold	Email, push notification, Slack webhook
Graylog	Stream condition: severity level ≤ 3 AND facility = local0 (Cisco); triggers on count > 0 in 60s window	Email, HTTP callback, PagerDuty integration
Splunk	Saved search: `index=syslog severity<=3 \| stats count by host` scheduled every 5 minutes	Email, Slack, ServiceNow, custom scripts

11. Troubleshooting Common Issues

Symptom	Likely Cause	Diagnostic Steps and Fix
No logs received on the server from a Cisco device	Firewall blocking UDP 514; `logging host` not configured; wrong server IP; no IP connectivity between device and server	1. `Router# ping 192.168.1.100` — if this fails, IP routing is the issue; 2. `show logging` — look for "Logging to 192.168.1.100 (link up)"; 3. On server: `sudo tcpdump -i eth0 udp port 514` — watch for arriving packets; 4. Check firewall rules
Server receives some logs but they appear under wrong hostname or IP	`logging source-interface` not set; different interface IP used per packet depending on routing	Configure `logging source-interface Loopback0` on the Cisco device; verify with `show logging` — the source IP shown should match the Loopback0 IP
Timestamps in logs are wrong or show "Mar 1 00:xx"	Device clock not synchronised with NTP; syslog timestamps using uptime instead of real time	Configure NTP: `ntp server pool.ntp.org`; verify: `show ntp status` should show "synchronised"; configure: `service timestamps log datetime msec`
Logs truncated or messages missing	UDP packet loss under load; messages exceeding UDP datagram size limit	Switch to TCP: `logging host <IP> transport tcp port 514`; verify on server that imtcp is loaded in rsyslog; increase rsyslog input queue size for high-volume sources
rsyslog service fails to start or stops listening on 514	Syntax error in rsyslog.conf; port 514 already in use; SELinux or AppArmor blocking the bind	`sudo rsyslogd -N1` — syntax check; `sudo journalctl -u rsyslog -n 50` — check error messages; `sudo ss -tulnp \| grep 514` — check if another process owns the port
Log files grow unbounded, filling disk	Log rotation not configured or not working; high-volume debug-level logging enabled	Verify logrotate config: `sudo logrotate --debug /etc/logrotate.d/rsyslog-remote`; ensure the logging trap level on devices is not set to `debugging` unless actively troubleshooting

Packet Capture for Syslog Verification

  # On the syslog server — capture arriving syslog UDP packets:
  sudo tcpdump -i eth0 udp port 514 -vv

  # Sample captured packet output:
  # IP 192.168.1.1.50214 > 192.168.1.100.514: UDP
  # <134>Dec 15 10:30:45 Router1 %LINK-3-UPDOWN: Interface Gi0/1, down
  #
  # Source IP 192.168.1.1 = Router1 (or its source-interface IP)
  # Destination 192.168.1.100 = syslog server

  # Filter for a specific source device:
  sudo tcpdump -i eth0 udp port 514 and src host 192.168.1.1 -vv

  # Save capture to a file for analysis:
  sudo tcpdump -i eth0 udp port 514 -w /tmp/syslog-capture.pcap

  # If no packets appear: the device is not sending,
  # or a firewall is blocking before reaching this interface.

12. Exam Tips & Key Points

Syslog uses UDP port 514 by default (fire-and-forget, no delivery guarantee). TCP 514 provides reliable delivery. TCP 6514 adds TLS encryption (RFC 5425). See Syslog Overview.
The syslog PRI value encodes both facility and severity: PRI = (Facility × 8) + Severity.
On Cisco IOS: logging host <IP> specifies the server; logging trap <level> sets the severity filter for the server; logging source-interface ensures a consistent source IP.
logging trap informational sends levels 0–6. logging trap warnings sends levels 0–4. Setting a level sends that level AND all more severe (lower-numbered) levels. See Syslog Severity Levels.
A leading asterisk (*) on a Cisco syslog timestamp means the clock is not NTP-synchronised — timestamps are unreliable. Fix with ntp server <IP>. Verify with show ntp status.
rsyslog stores remote logs in /var/log/remote/ by hostname when configured with the RemoteLogs template.
Use logging source-interface Loopback0 on Cisco devices so syslog messages always originate from the stable loopback IP — prevents log attribution problems when physical interfaces change.
The Linux logger command sends a test syslog message: logger -p local3.err "Test message"; the -p facility.severity flag sets the priority.
Popular centralised log management platforms: Graylog (open-source), Splunk (commercial SIEM), ELK Stack (open-source, high-volume), Loki+Grafana (cloud-native).
Always verify syslog reception with show logging on the Cisco device (look for "link up" next to the server IP) and tail -f /var/log/remote/Router1.log on the server.

13. Summary Reference Table

Topic	Key Detail
Default syslog transport	UDP port 514 (fire-and-forget)
Reliable syslog transport	TCP port 514
Encrypted syslog	TCP+TLS port 6514 (RFC 5425)
PRI value formula	(Facility × 8) + Severity
Cisco: set syslog server	`logging host <IP>`
Cisco: set severity filter	`logging trap <level>`
Cisco: stable source IP	`logging source-interface Loopback0`
Linux rsyslog config file	`/etc/rsyslog.conf`
Per-host log storage path	`/var/log/remote/<HOSTNAME>.log`
Linux test message	`logger -p local3.err "Test message"`
Verify Cisco syslog forwarding	`show logging` — look for "link up" at server IP
Packet capture verification	`sudo tcpdump -i eth0 udp port 514 -vv`
NTP sync indicator	Absence of * on timestamps in show logging

Syslog Server Configuration Quiz

1. What is the primary purpose of a syslog server, and what key advantage does it provide over relying on individual device log buffers?

A. Managing user accounts across the network — it centralises authentication so devices can reference a single user database B. Sending automated emails to administrators — it converts device events into email notifications C. Routing network traffic — it acts as a Layer 3 device for log-related packets D. Centralised collection and long-term storage of log messages from all devices — device buffers are small, volatile (lost on reload), and isolated; a syslog server provides persistence, cross-device correlation, and tamper-resistant storage

Correct answer is D. A syslog server solves the fundamental limitations of per-device log buffers. Individual device buffers: (1) are typically small (4–16 KB by default) and wrap around, losing old messages when full; (2) are lost entirely when the device reloads; (3) can be cleared by anyone with privileged access, covering up security incidents; (4) require separate logins to each device to access. A centralised syslog server aggregates logs from every device into a single, persistent, searchable store. This enables cross-device event correlation by timestamp (e.g., linking an interface failure on Switch1 to an OSPF adjacency loss on Router1), automated alerting, and compliance log retention. Critically, clear logging on a device does not affect copies already forwarded to the server.

2. What is the default transport protocol and port for syslog, and what is its key limitation compared to TCP?

A. UDP port 514 — it is connectionless (fire-and-forget) with no delivery acknowledgement; messages can be silently lost under network congestion or server overload without the sender knowing B. TCP port 80 — HTTP is used as the transport to simplify firewall traversal C. TCP port 514 — TCP is the default because it guarantees delivery; the limitation is higher overhead D. UDP port 80 — using port 80 allows syslog traffic to pass through web proxies

Correct answer is A. The default syslog transport is UDP port 514 (RFC 3164 / RFC 5424). UDP is connectionless — the sender transmits the packet and does not check whether it arrived. If the network drops the packet or the syslog server is overloaded and cannot process it in time, the log message is silently lost. The sender receives no error and has no way to retransmit. This is the fundamental trade-off: UDP is very lightweight (no connection setup, no acknowledgements, minimal overhead) but unreliable. For environments where log completeness is critical, TCP port 514 should be used — it provides guaranteed delivery through TCP's acknowledgement and retransmit mechanism. For encrypted transport, TCP port 6514 with TLS (RFC 5425) is the standard. Cisco IOS uses UDP 514 by default; specify TCP with logging host <IP> transport tcp port 514.

3. Which Cisco IOS command specifies the syslog server's IP address, and what additional command controls which severity levels are forwarded to it?

A. logging trap — this command both specifies the server IP and sets the severity filter in a single command B. logging host [IP address] specifies the server; logging trap [level] sets the severity filter — for example, "logging trap warnings" sends levels 0 through 4 to the server C. snmp-server host [IP] — SNMP traps are used for log forwarding on modern Cisco devices D. set syslog ip [address] — this is the correct global configuration command for syslog server configuration

Correct answer is B. Cisco IOS uses two separate commands for syslog server configuration. logging host <IP> (global config) specifies the destination syslog server — the device will forward syslog messages to this IP address via UDP port 514 (default).

logging trap
                  <level>

controls the minimum severity that is forwarded to the server — this works the same as the buffer and console level commands: setting a level sends that level and all more severe (lower-numbered) levels. For example, logging trap warnings (level 4) sends Emergency (0), Alert (1), Critical (2), Error (3), and Warning (4) to the server. logging trap informational (level 6) additionally sends Notice and Informational messages. A third useful command is logging source-interface <int> which ensures a consistent source IP regardless of which route the packet takes.

4. What is the recommended method for securing syslog traffic sent over untrusted networks, and what port does the encrypted standard use?

A. Using FTP to transfer log files — FTP encrypts the log data before transmission B. Disabling UDP and using only plain TCP port 514 — TCP provides encryption as part of its transport C. Changing the syslog port to 80 — using the standard web port allows the traffic to use HTTPS encryption automatically D. TLS encryption over TCP — configured using the gtls module in rsyslog; the standard encrypted syslog port is TCP 6514 (RFC 5425); this provides both confidentiality and server authentication via certificates

Correct answer is D. Plain-text syslog (UDP or TCP 514) sends log messages in clear text. Anyone capturing network traffic on the path between the device and the syslog server can read every log message — this can expose device types, interface names, IP addresses, error details, and potentially credentials mentioned in configuration-change log entries. The solution is syslog over TLS, defined in RFC 5425, which uses TCP with TLS encryption on standard port 6514. In rsyslog, this is implemented with the gtls (GnuTLS) driver module: module(load="gtls") and then configuring the TCP input with StreamDriver.Name="gtls". TLS provides: (1) encryption of the log stream; (2) server certificate authentication (prevents rogue syslog servers from accepting your logs); (3) optionally, mutual authentication where both client and server present certificates.

5. On a Linux rsyslog server configured for remote logging with the RemoteLogs template, where are logs from a device named Router1 typically stored?

A. /etc/rsyslog.conf — the configuration file itself is also used to store incoming log entries B. /var/log/syslog — all remote logs are merged into the main local syslog file alongside system logs C. /var/log/remote/Router1.log — the RemoteLogs template creates one file per device hostname in the /var/log/remote/ directory, enabling per-device log separation and monitoring D. /usr/local/logs/Router1/ — rsyslog stores remote device logs in a directory under the application installation path

Correct answer is C. When rsyslog is configured with the RemoteLogs template —

$template RemoteLogs,
                  "/var/log/remote/%HOSTNAME%.log"

followed by *.* ?RemoteLogs — it extracts the hostname from each incoming syslog message and creates (or appends to) a file named /var/log/remote/<HOSTNAME>.log. For a device with hostname Router1, all its syslog messages are written to /var/log/remote/Router1.log. This per-device file separation is a best practice because it makes it easy to monitor specific devices (tail -f /var/log/remote/Router1.log), apply device-specific log rotation policies, and quickly find events for a particular device during incident response without filtering through logs from all devices. The /var/log/remote/ directory must be created manually before restarting rsyslog.

6. Why is NTP synchronisation critical for syslog, and what Cisco IOS command adds millisecond precision to log timestamps?

A. NTP ensures all devices share the same accurate clock — without it, cross-device event correlation is impossible because each device shows events at its own drifted time; the command is "service timestamps log datetime msec" B. NTP disables logging during time zone changes to prevent duplicate timestamps — without it, daylight saving adjustments cause log gaps C. NTP is only needed for syslog servers using local file storage — remote forwarding uses the server's clock regardless of the device's time setting D. NTP changes the syslog facility code to ensure timestamps are transmitted as part of the PRI value rather than the message header

Correct answer is A. NTP (Network Time Protocol) is essential for meaningful syslog analysis across multiple devices. Without it, each device maintains its own internal clock that drifts at different rates. A syslog entry on Router1 might show an event at 14:03:12 while the same event causes a related entry on Switch2 at 08:03:12 — a 6-hour apparent gap that makes it impossible to determine causation. With NTP synchronisation, both devices show events within milliseconds of each other, revealing the true causal sequence. The Cisco IOS command service timestamps log datetime msec adds the full date, time, and millisecond precision to every log entry. Without this command, Cisco devices show only system uptime in log messages (e.g., 00:05:14.231 = 5 minutes since last boot) rather than the actual calendar date and time. The leading asterisk (*) on a timestamp in show logging output is the indicator that NTP is not currently synchronised.

7. Which open-source centralised log management tool provides full-text search, stream rules, dashboards, and alerting for syslog messages collected from network devices?

A. SolarWinds — an open-source tool with a large community edition that provides free dashboards and alerting for unlimited devices B. Graylog — an open-source log management platform with syslog input support, full-text search across all messages, stream-based routing, dashboards, and alert notifications; the community edition is free and handles enterprise-scale volumes C. Windows Event Viewer — a built-in Windows tool that provides centralised syslog collection from Linux and Cisco devices D. Microsoft Exchange — the email server platform also functions as a network syslog collector and analysis tool

Correct answer is B. Graylog is a widely-deployed open-source log management platform. It natively accepts syslog (UDP/TCP) input, indexes all messages in Elasticsearch, and provides: a web-based search interface for querying across all devices simultaneously; streams (routing rules based on message content or severity) for classifying logs; dashboards for real-time and historical visualisation; and an alerting system that can notify via email, Slack, HTTP callbacks, or PagerDuty. The community edition is completely free and production-ready. The typical Graylog deployment flow is: network devices → rsyslog (collector, UDP 514) → Graylog (GELF input, port 12201) → Elasticsearch → Kibana/Graylog UI. Splunk is commercial (with a free 500 MB/day tier) and is the dominant SIEM in enterprise security operations. The ELK Stack (Elasticsearch+Logstash+Kibana) is open-source and handles very high volumes.

8. How can you verify that a Cisco device is successfully forwarding logs to the syslog server, and what does "link up" in the show logging output indicate?

A. show interfaces — this command shows the physical interface state which confirms syslog connectivity B. show ip route — verifying a route to the syslog server IP confirms logs are being forwarded C. show logging — look for the line showing the server IP with "link up" which confirms the syslog server is reachable and messages are being sent; also shows the trap level and total messages forwarded D. debug logging — enables real-time debug output for the logging subsystem which confirms or denies packet transmission

Correct answer is C. show logging on a Cisco device shows the complete logging configuration and status including the syslog server section. The key line to look for is: "Logging to 192.168.1.100 (udp port 514, audit disabled, link up), N message lines logged". "Link up" means the device has confirmed IP connectivity to the syslog server — the device can reach the server and is actively forwarding messages. "Link down" would indicate the server is unreachable (firewall, routing issue, server offline). The command also shows: "Trap logging: level informational, N message lines logged" — confirming the severity level and total count forwarded. You can also filter with show logging | include sending to quickly find the forwarding status lines. On the server side, use tail -f /var/log/remote/Router1.log to confirm actual message arrival.

9. What firewall rule must be in place on the syslog server to allow UDP syslog traffic from LAN devices, and why is it important to restrict by source subnet?

A. Allow TCP port 80 from any source — web traffic must be permitted for syslog management interface access B. Allow UDP port 443 from any source — HTTPS is required for encrypted syslog transmission C. Allow TCP port 514 from all sources — TCP provides enough security that source filtering is unnecessary D. Allow UDP port 514 from only the trusted LAN subnet (e.g., 192.168.1.0/24) — restricting by source subnet prevents log injection attacks where an attacker from outside the network sends false syslog messages to flood or manipulate the log database

Correct answer is D. Syslog uses UDP port 514 by default. The firewall on the syslog server should allow UDP port 514 inbound — but only from trusted source addresses. Without source restriction, any device on the internet (or any internal device in untrusted VLANs) could send fabricated syslog messages to the server. An attacker could use this to: flood the server with fake critical alerts (obscuring real events), inject false configuration-change log entries to mislead incident responders, or fill the disk to cause log storage failure. The Linux UFW rule is: sudo ufw allow from 192.168.1.0/24 to any port 514 proto udp followed by sudo ufw deny from any to any port 514 to block all other sources. This restricts syslog reception to only the management subnet where the network devices reside.

10. Which Linux command sends a test syslog message, and what does the -p local3.err flag specify?

A. logger -p local3.err "Test message from Linux" — the -p flag sets the priority as facility.severity; local3 is syslog facility 19 and err is severity 3 (Error), giving PRI value (19×8)+3 = 155 B. syslogctl -t "Test message" — syslogctl is the standard Linux tool for sending test syslog messages to both local and remote destinations C. logsend "Test message" — this command is available on all Linux distributions and sends a syslog message using the default facility and severity D. sendlog -p local3.err "Test message" — this is the equivalent of the logger command on Red Hat-based distributions

Correct answer is A. The logger command is a standard Linux utility available on all distributions that sends a message to the local syslog system (which then forwards it to any configured remote syslog servers based on its rules). The -p facility.severity flag sets the syslog priority for the message. local3.err means: facility = local3 (one of the eight locally-defined syslog facilities, local0 through local7; Cisco uses these for its own messages), severity = err (level 3, Error). The PRI value would be (19 × 8) + 3 = 155. This is the standard way to test whether syslog forwarding is working without waiting for a real network event: send the test message, then check the syslog server for receipt with grep "Test message" /var/log/remote/$(hostname).log. It can also be used from scripts to inject application-level events into the syslog stream for centralised monitoring.