Syslog Configuration

Every Cisco IOS device generates log messages as it operates — interface state changes, authentication failures, ACL hits, routing adjacency events, and hardware errors all produce entries. By default these messages only appear on the console or are stored in a small in-memory buffer that is lost on reload. Syslog solves both problems: it forwards log messages in real time to a centralised syslog server where they are stored persistently, timestamped, and searchable. This enables audit trails, security incident investigation, and capacity planning across an entire network from a single location.

IOS syslog integrates with severity levels (0–7) to filter which messages are forwarded — a busy core router might send only warnings and above to the server while retaining all levels locally in the buffer. Timestamps are added by service timestamps so that correlated events across multiple devices are correctly sequenced.

Before starting, review Syslog Severity Levels to understand the 0–7 scale and which events map to which level. For reviewing the local log buffer on a device see show logging. For NTP — which must be configured to make timestamps meaningful across devices — see NTP Synchronisation and NTP Configuration.

1. Syslog — Core Concepts

How IOS Syslog Works

IOS generates log messages internally and passes them to the logging subsystem, which distributes each message to one or more logging destinations simultaneously. Each destination has its own independently configurable severity threshold — messages at or below the configured level are forwarded; messages above it are silently discarded:

Destination	Command to Enable	Default State	Persistent?	Use Case
Console	`logging console [level]`	ON (debugging — all levels)	No	Live monitoring during hands-on lab or initial config
VTY (terminal)	`logging monitor [level]` + `terminal monitor`	ON — but off per-session until `terminal monitor`	No	SSH/Telnet session monitoring — see messages on remote login
Buffer	`logging buffered [size] [level]`	ON (debugging)	No (cleared on reload)	Short-term local review via `show logging`
Syslog Server	`logging host [IP]`	OFF	Yes (on server)	Centralised, persistent long-term storage and correlation

Syslog Severity Levels

IOS uses the standard RFC 5424 severity scale. Lower numbers are more severe — a router configured to send level 3 (errors) will also send levels 0, 1, and 2 (emergencies, alerts, critical). See Syslog Severity Levels for the full reference:

Level	Keyword	Description	Example IOS Event
0	`emergencies`	System unusable	Kernel panic, critical hardware failure
1	`alerts`	Immediate action needed	Temperature threshold exceeded
2	`critical`	Critical condition	Memory allocation failure
3	`errors`	Error condition	Interface error, OSPF neighbour down
4	`warnings`	Warning condition	Interface flap, ACL log match
5	`notifications`	Normal but significant	Interface up/down state change, config change. See show interfaces.
6	`informational`	Informational message	Neighbour adjacency established, DHCP lease
7	`debugging`	Debug-level messages	All debug output — very verbose

Memory tip — "Every Awesome Cisco Engineer Will Need Ice Daily": Emergencies (0), Alerts (1), Critical (2), Errors (3), Warnings (4), Notifications (5), Informational (6), Debugging (7). On the CCNA exam, severity level numbers and their keywords are frequently tested.

Syslog Message Format

Every IOS syslog message follows a consistent structure. Understanding the fields helps you quickly identify what happened, when, and where:

*Mar  7 14:22:31.452: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down

 └──────────────────┘  └──────────┘└─┘└──────┘  └──────────────────────────────────────────────────────────┘
       Timestamp        Facility   Sev  Mnemonic              Message text
                        (module)   (5)

Field breakdown:
  Timestamp   — Date and time of the event (requires service timestamps)
  Facility    — IOS module that generated the message (LINEPROTO, OSPF, SEC, etc.)
  Severity    — 0–7 numeric level (5 = notifications in this example)
  Mnemonic    — Short unique identifier for this specific event type (UPDOWN)
  Message     — Human-readable description of what happened

Syslog Transport — UDP 514

IOS sends syslog messages to the server using UDP port 514 by default. UDP is connectionless — if the server is unreachable, messages are silently lost with no retransmission. IOS also supports TCP syslog (typically port 1468 or 6514 for TLS) which provides reliable delivery — configure with logging host [IP] transport tcp port [port] if your syslog server supports it.

2. Lab Topology & Scenario

This lab configures centralised syslog on two routers — an edge router (NetsTuts_R1) and a distribution router (NetsTuts_R2) — forwarding all log messages to a dedicated syslog server on the management network. NTP is already configured so timestamps are synchronised:

    192.168.10.0/24 — Staff VLAN          10.0.12.0/30 — WAN Link
    [PC1: .10.10]                          
          |                               
     Gi0/1 (192.168.10.1)                 
          |                               
     NetsTuts_R1 ─────────────────── NetsTuts_R2
     Gi0/0: 203.0.113.2 (WAN)        Gi0/1: 192.168.30.1
          |                               |
          |                          192.168.30.0/24
          |                          [Syslog Server: 192.168.30.50]
          |                          [NTP Server:    192.168.30.51]
          |
     192.168.20.0/24 — Guest VLAN
     [Laptop1: .20.10]

  Lab Goals:
    Step 1 — Configure logging destinations (buffer + syslog server)
    Step 2 — Set severity thresholds per destination
    Step 3 — Enable timestamps with msec precision
    Step 4 — Set source interface for syslog traffic
    Step 5 — Configure syslog on R2
    Step 6 — Verify with show logging and test event generation

Device	Syslog Server IP	Trap Level (to server)	Buffer Level	Buffer Size	Source Interface
NetsTuts_R1	192.168.30.50	informational (6)	debugging (7)	16384 bytes	Loopback0
NetsTuts_R2	192.168.30.50	warnings (4)	informational (6)	8192 bytes	Loopback0

3. Step 1 — Configure Logging Destinations

Begin by enabling the logging subsystem and defining where messages are sent. By default, console logging is on at debugging (all messages) — on production devices this should be reduced to avoid console flooding causing high CPU:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Enable logging globally (on by default, explicit is best practice)
NetsTuts_R1(config)#logging on

! ── Reduce console logging to warnings only (level 4 and below)
! ── Prevents console flooding from info/debug messages on live routers
NetsTuts_R1(config)#logging console warnings

! ── Configure local buffer — larger size retains more history
NetsTuts_R1(config)#logging buffered 16384 debugging

! ── Forward messages to the centralised syslog server ────
NetsTuts_R1(config)#logging host 192.168.30.50

Three destinations are now active: console (warnings and above only), local buffer (all levels), and syslog server (default level until logging trap is configured in the next step). logging host accepts either an IPv4 address or hostname — using an IP directly avoids DNS dependency. Multiple logging host commands can be configured to send to more than one syslog server simultaneously.

4. Step 2 — Set Severity Thresholds

The logging trap command controls which severity levels are forwarded to syslog servers. The name "trap" is legacy terminology — in IOS, "trap" refers to the syslog server destination specifically (it is unrelated to SNMP traps). Setting it to informational (level 6) sends levels 0–6 to the server, excluding only debugging (level 7) which is extremely verbose and not useful in persistent storage:

! ── Set syslog server threshold to informational (levels 0–6) ──
NetsTuts_R1(config)#logging trap informational

! ── Confirm buffer threshold (set in Step 1, confirming explicitly)
NetsTuts_R1(config)#logging buffered 16384 debugging

! ── VTY monitor threshold — messages shown on SSH sessions ──────
! ── User must also run 'terminal monitor' in their SSH session
NetsTuts_R1(config)#logging monitor informational

logging trap informational sets the threshold for the syslog server destination. All messages from emergency (0) through informational (6) are forwarded — this captures interface state changes, config changes, routing adjacency events, and DHCP/NTP events. Debugging (7) is excluded — debug output is only useful during active troubleshooting and would fill the syslog server rapidly. Use logging trap debugging temporarily during a specific investigation if needed.

Threshold Comparison — What Each Level Captures

Recommended Setting	Levels Forwarded	Typical Use	Volume
`logging trap errors` (3)	0, 1, 2, 3	Minimal — critical failures and errors only	Very low
`logging trap warnings` (4)	0–4	Production minimum — failures + ACL hits + interface flaps	Low
`logging trap notifications` (5)	0–5	Recommended baseline — adds interface up/down and config events	Medium
`logging trap informational` (6)	0–6	Full operational visibility — standard for most environments	Medium-high
`logging trap debugging` (7)	0–7	Temporary troubleshooting only — floods server rapidly. See debug commands.	Very high

5. Step 3 — Configure Timestamps

Without timestamps, log messages show only a sequence number and uptime counter — useless for correlating events across devices. The service timestamps command adds the actual date and time to every message. Adding msec includes milliseconds — essential for correlating rapid events like a link flap triggering OSPF reconvergence within milliseconds:

! ── Add timestamps to log messages — date, time, and milliseconds ──
NetsTuts_R1(config)#service timestamps log datetime msec localtime show-timezone

! ── Add timestamps to debug output as well ───────────────────────
NetsTuts_R1(config)#service timestamps debug datetime msec localtime show-timezone

The full keyword breakdown: datetime — use actual calendar date/time (not uptime); msec — append milliseconds to the timestamp; localtime — use the device's local timezone (set by clock timezone) rather than UTC; show-timezone — append the timezone abbreviation (e.g., GST) to the timestamp so analysts know which timezone applies when reviewing logs from multiple regions. The service timestamps debug line also timestamps debug command output.

Timestamp Format Comparison

Configuration	Example Timestamp in Log	Notes
`no service timestamps log`	`00:04:31: %LINK-3-UPDOWN...`	Uptime only — no date/time. Default before NTP sync
`service timestamps log uptime`	`1d02h: %LINK-3-UPDOWN...`	Days and hours since boot — resets on reload
`service timestamps log datetime`	`Mar 7 14:22:31: %LINK-3-UPDOWN...`	Absolute date/time — requires NTP or manual clock set
`service timestamps log datetime msec`	`Mar 7 14:22:31.452: %LINK-3-UPDOWN...`	Adds milliseconds — best for event correlation
`...msec localtime show-timezone`	`Mar 7 14:22:31.452 GST: %LINK-3-UPDOWN...`	Full format — recommended for production environments

NTP dependency: Timestamps are only meaningful if the device clock is accurate. Always configure NTP before enabling service timestamps log datetime — without NTP, the device clock starts at epoch (Jan 1 2002) on reload, producing incorrect timestamps. See NTP Synchronisation and NTP Configuration for the full NTP configuration process.

6. Step 4 — Set Source Interface

By default, IOS uses the IP address of the outgoing interface as the source of syslog UDP packets — this changes if the routing path changes, making it difficult to identify which device sent a message on the syslog server. Pinning syslog to a Loopback interface gives it a stable, always-up source IP regardless of physical link state:

! ── Create Loopback0 if not already configured ────────────────────
NetsTuts_R1(config)#interface Loopback0
NetsTuts_R1(config-if)#ip address 1.1.1.1 255.255.255.255
NetsTuts_R1(config-if)#description Management Loopback — syslog/NTP source
NetsTuts_R1(config-if)#exit

! ── Pin syslog source to Loopback0 ───────────────────────────────
NetsTuts_R1(config)#logging source-interface Loopback0

! ── (Optional) Set facility code for this device ─────────────────
! ── Helps syslog server categorise messages by device type
NetsTuts_R1(config)#logging facility local6

logging source-interface Loopback0 sets the source IP of all syslog UDP packets to the Loopback0 address (1.1.1.1 here). The syslog server sees every message from R1 as coming from 1.1.1.1 regardless of which physical interface the packet actually exits. This same principle applies to NTP and SNMP source interfaces for consistent management traffic identification. logging facility local6 sets the syslog facility code — IOS supports local0 through local7. Using different facility codes for different device types (local5 for routers, local6 for switches) allows the syslog server to apply separate rules and storage paths per facility.

Syslog Facility Codes

Facility	Code	Common Assignment
`local0`	16	Custom use — often edge routers
`local1`	17	Custom use — often WAN routers
`local2–4`	18–20	Custom assignment by team convention
`local5`	21	Common for Cisco routers
`local6`	22	Common for Cisco switches
`local7`	23	Common for Cisco access points / misc

7. Step 5 — Configure Syslog on NetsTuts_R2

R2 uses a more conservative threshold — warnings (level 4) to the server — because it is a distribution router generating higher volume routing protocol messages that would flood the syslog server at informational. The local buffer retains level 6 for local troubleshooting:

NetsTuts_R2>en
NetsTuts_R2#conf t

! ── Timestamps first — always configure before enabling syslog ────
NetsTuts_R2(config)#service timestamps log datetime msec localtime show-timezone
NetsTuts_R2(config)#service timestamps debug datetime msec localtime show-timezone

! ── Logging destinations ──────────────────────────────────────────
NetsTuts_R2(config)#logging on
NetsTuts_R2(config)#logging console warnings
NetsTuts_R2(config)#logging buffered 8192 informational
NetsTuts_R2(config)#logging host 192.168.30.50

! ── Server threshold — warnings only (levels 0–4) ────────────────
NetsTuts_R2(config)#logging trap warnings

! ── Source interface ─────────────────────────────────────────────
NetsTuts_R2(config)#interface Loopback0
NetsTuts_R2(config-if)#ip address 2.2.2.2 255.255.255.255
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#logging source-interface Loopback0
NetsTuts_R2(config)#logging facility local6

NetsTuts_R2(config)#end
NetsTuts_R2#wr
Building configuration...
[OK]
NetsTuts_R2#

Note that service timestamps is configured before logging host — this ensures that from the moment the syslog server connection is established, all forwarded messages already carry accurate timestamps. If timestamps are added after the syslog server is configured, a gap of timestampless messages may appear in the server logs. Save the configuration with wr to preserve the syslog settings across a reload.

8. Step 6 — Verification

show logging — Full Logging Status

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

No Active Message Discriminator.
No Inactive Message Discriminator.

    Console logging: level warnings, 12 messages logged, xml disabled,
                     filtering disabled
    Monitor logging: level informational, 0 messages logged, xml disabled,
                     filtering disabled
    Buffer logging:  level debugging, 47 messages logged, xml disabled,
                    filtering disabled
    Logging Exception size (8192 bytes)
    Count and timestamp logging messages: disabled
    Persistent logging: disabled

No active filter modules.

    Trap logging: level informational, 47 message lines logged
        Logging to 192.168.30.50  (udp port 514,  audit disabled,
              link up),
              47 message lines logged,
              0 message lines rate-limited,
              0 message lines dropped-by-MD,
              xml disabled, sequence number disabled
              filtering disabled
        Logging Source-Interface:       Loopback0 (1.1.1.1)

Log Buffer (16384 bytes):

Mar  7 14:20:15.123 GST: %SYS-5-CONFIG_I: Configured from console by admin on vty0 (192.168.10.10)
Mar  7 14:21:02.847 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to up
Mar  7 14:22:31.452 GST: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from LOADING to FULL, Loading Done

The output confirms the full logging configuration in one command. Key fields to check: console level (warnings), buffer level (debugging) and size (16384 bytes), trap level (informational), syslog server IP (192.168.30.50, UDP 514, link up), and source interface (Loopback0, 1.1.1.1). The buffer shows the three most recent messages with full timestamps and timezone. The "link up" status for the syslog server confirms the device can reach 192.168.30.50 and the UDP session is established. The OSPF adjacency event in the buffer (level 5) confirms routing protocol events are being captured.

Generate a Test Event — Interface Shutdown

! ── Shut and re-enable an unused interface to generate syslog events
NetsTuts_R1(config)#interface GigabitEthernet0/3
NetsTuts_R1(config-if)#shutdown
Mar  7 14:25:10.001 GST: %LINK-5-CHANGED: Interface GigabitEthernet0/3, changed state to administratively down
Mar  7 14:25:11.001 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to down

NetsTuts_R1(config-if)#no shutdown
Mar  7 14:25:45.332 GST: %LINK-3-UPDOWN: Interface GigabitEthernet0/3, changed state to up
Mar  7 14:25:46.332 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to up
NetsTuts_R1(config-if)#exit

These four messages appear on the console (level 5 and 3 — both meet the warnings threshold), in the buffer (all levels captured), and on the syslog server (informational threshold — levels 5 and 3 qualify). On the syslog server, check the log file or GUI for entries from source IP 1.1.1.1 (Loopback0) timestamped around 14:25. Verify interface state independently with show interfaces GigabitEthernet0/3.

show logging — Check After Test Event

NetsTuts_R1#show logging | include UPDOWN
Mar  7 14:21:02.847 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to up
Mar  7 14:25:10.001 GST: %LINK-5-CHANGED: Interface GigabitEthernet0/3, changed state to administratively down
Mar  7 14:25:11.001 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to down
Mar  7 14:25:45.332 GST: %LINK-3-UPDOWN: Interface GigabitEthernet0/3, changed state to up
Mar  7 14:25:46.332 GST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to up

The | include pipe filter reduces output to only lines containing "UPDOWN" — useful for quickly finding interface events in a buffer that may contain hundreds of other messages. The full timestamps confirm NTP is working and the timezone abbreviation confirms show-timezone is active.

Verification Command Summary

Command	What It Shows	Primary Use
`show logging`	All logging destinations, their thresholds, message counts, syslog server IP and status, source interface, and the log buffer contents	Primary verification — confirm all settings and review recent events
`show logging \| include [keyword]`	Filters buffer output to lines matching a string — interface name, facility, severity mnemonic	Quickly find specific event types in a large buffer
`show running-config \| section logging`	All active logging configuration lines from running-config	Audit configuration — confirm `logging host`, `logging trap`, `logging source-interface`, and facility are all present
`clear logging`	Clears the local log buffer — does not affect syslog server history	Reset buffer before a test to get a clean baseline
`show logging` (reference)	Full command output field reference including buffer, trap counters, and rate-limit statistics	Detailed field-by-field explanation of show logging output

9. Troubleshooting Syslog Issues

Problem	Symptom	Cause	Fix
No messages reaching syslog server	`show logging` shows 0 messages logged to the server despite active events	Routing issue — router cannot reach the syslog server IP. Or `logging host` not configured, or the source interface has no route to the server	Ping the syslog server from the router: `ping 192.168.30.50 source Loopback0`. If ping fails, fix routing first. Verify `logging host` is present with `show running-config \| section logging`.
Messages arrive with wrong source IP	Syslog server shows messages from varying IP addresses for the same router — breaks host-based filtering and alerting rules	`logging source-interface` not configured — router uses the exit interface IP which changes with routing	Configure `logging source-interface Loopback0` — all syslog UDP packets will then use the stable Loopback IP regardless of routing path
Timestamps show wrong time or epoch (Jan 2002)	Log entries show `*Jan 1 00:00:05` or incorrect date/time in syslog server records	NTP not configured or not synchronised — device clock is at default epoch. Or `service timestamps log datetime` not configured	Configure NTP with `ntp server [IP]` and verify sync with `show ntp status`. Then set `service timestamps log datetime msec`. See NTP Synchronisation and NTP Configuration.
Missing expected messages on server	Interface flaps appear in the local buffer but not on the syslog server	`logging trap` threshold is too high (too restrictive) — e.g., set to `errors` (3) which blocks level 5 notifications like interface state changes	Run `show logging` and check the "Trap logging: level" line. Adjust with `logging trap informational` or `logging trap notifications` as appropriate
Console flooding — high CPU	Router console is overwhelmed with debug-level messages causing slow response or high CPU	Console logging left at default `debugging` (level 7) — all messages including verbose debug output appear on console	Reduce console threshold: `logging console warnings` limits console to level 4 and below. Never leave console at debugging on a production device
Log buffer overwriting too quickly	`show logging` buffer does not show events from more than a few minutes ago	Buffer size too small for the volume of messages being generated — older entries are overwritten by newer ones	Increase buffer size: `logging buffered 65536 informational`. Consider raising the buffer threshold from `debugging` to `informational` to reduce volume

Key Points & Exam Tips

IOS has four logging destinations — console, VTY monitor, buffer, and syslog server — each with independently configurable severity thresholds. Only the syslog server provides persistent, centralised storage.
Severity levels run 0 (emergencies) to 7 (debugging) — lower numbers are more severe. logging trap informational (level 6) sends levels 0–6 to the server; logging trap warnings (level 4) sends only levels 0–4. See Syslog Severity Levels.
The logging trap command controls the syslog server threshold — its name is legacy IOS terminology, not related to SNMP traps.
service timestamps log datetime msec localtime show-timezone adds date, time, milliseconds, and timezone to every message — required for cross-device event correlation. Meaningless without NTP.
logging source-interface Loopback0 pins the source IP of syslog UDP packets to the stable Loopback address — prevents the syslog server from seeing multiple source IPs for the same device. Use the same Loopback for NTP and SNMP sources.
IOS uses UDP port 514 for syslog by default — connectionless, no delivery guarantee. TCP syslog (port 1468 or 6514 with TLS) provides reliable delivery if the server supports it.
logging facility local0 through local7 sets the facility code sent in syslog messages — allows the syslog server to categorise and route messages to different storage or alerting rules by device type.
show logging is the primary verification command — it shows all destination states, thresholds, message counts, syslog server connectivity status, source interface, and the buffer contents.
On the CCNA exam: know all eight severity levels (0–7) with their keywords and mnemonics, the logging trap and logging host commands, the purpose of service timestamps, and the difference between logging destinations.
VTY monitor logging requires two steps: logging monitor [level] in global config AND terminal monitor in each VTY session — without terminal monitor, no messages appear even if monitor logging is enabled. See SSH Configuration for VTY session setup.
Key events that generate syslog entries: interface state changes (show interfaces), ACL log matches, OSPF adjacency changes, authentication failures, and port security violations.

Next Steps: With syslog forwarding configured, review the full field breakdown of the output at show logging. To understand the severity level reference in detail see Syslog Severity Levels. For NTP configuration that makes timestamps accurate, see NTP Synchronisation and NTP Configuration. For SNMP-based monitoring alongside syslog, see SNMP Community Strings, SNMP Traps, and SNMP v2c/v3 Configuration. For traffic-flow visibility that complements event logging, see NetFlow Configuration. For forwarding authentication failure events, see Login Brute-Force Protection and AAA Authentication Methods.

TEST WHAT YOU LEARNED

1. A network engineer runs `show logging` and sees "Trap logging: level warnings, 0 message lines logged" and "Logging to 192.168.30.50 (udp port 514, audit disabled, link up)". An interface flapped (level 5 — notifications) ten minutes ago. Why did the event not reach the syslog server?

A. The syslog server is unreachable — "link up" only confirms the interface is up, not that UDP 514 is open on the server B. Interface state events are always logged locally only — they cannot be forwarded to a syslog server C. The trap level is set to warnings (4) — this forwards levels 0–4 only. An interface flap generates a level 5 (notifications) message, which is above the threshold and is therefore not forwarded to the syslog server D. service timestamps is not configured — events without timestamps cannot be forwarded

Correct answer is C. Syslog severity works as a threshold — logging trap warnings (level 4) forwards only messages at level 4 (warnings) and below, i.e. levels 0, 1, 2, 3, and 4. An interface flap generates a %LINEPROTO-5-UPDOWN message at level 5 (notifications), which is numerically higher than 4 and therefore does not meet the threshold. To capture interface state events on the syslog server, increase the trap threshold: logging trap notifications (5) or logging trap informational (6). The event still appears in the local buffer if the buffer threshold is set to notifications or higher. See show interfaces to confirm the current interface state.

2. What is the correct IOS command to forward log messages to a syslog server at 192.168.30.50 and set the forwarding threshold to informational?

A. logging 192.168.30.50 informational B. logging host 192.168.30.50 followed by logging trap informational — two separate commands are required: one to define the server and one to set the threshold C. logging server 192.168.30.50 level informational D. logging host 192.168.30.50 trap informational

Correct answer is B. IOS syslog configuration uses two separate commands: logging host [IP] to define the destination server, and logging trap [level] to set the severity threshold for what is forwarded to all configured syslog servers. These cannot be combined in a single command on standard IOS. Verify with show running-config | section logging after configuring.

3. An engineer configures `logging monitor informational` but sees no messages in their SSH session during a test. What is the missing step?

A. The engineer must also configure logging console informational — monitor logging depends on console logging being active B. The SSH session must be from an IP in the same subnet as the router — remote sessions cannot receive monitor logging C. Monitor logging only works with Telnet sessions, not SSH D. The engineer must run terminal monitor in their VTY session — logging monitor enables the feature globally but each VTY session must individually activate it with terminal monitor before messages appear

Correct answer is D. VTY (monitor) logging is a two-step process. logging monitor [level] in global config enables the feature and sets the threshold — but this does not automatically send messages to all VTY sessions. Each individual SSH session must run terminal monitor to opt in to receiving log messages. This is intentional — engineers who are not actively monitoring may not want their terminal flooded with log messages. To disable in the session: terminal no monitor. This setting is session-scoped and resets when the session ends.

4. Why should `logging source-interface Loopback0` be configured on routers sending syslog to a central server?

A. Without it, IOS uses the outgoing interface IP as the syslog source — this changes if the routing path changes, causing the syslog server to see messages from different source IPs for the same device. Loopback0 is always up and always has a consistent IP, making device identification reliable B. Syslog over UDP requires a Loopback source — physical interfaces do not support UDP syslog transmission C. It encrypts syslog traffic when sent from a Loopback interface D. It prevents syslog messages from being forwarded if the Loopback goes down, protecting the server from incomplete data

Correct answer is A. IOS syslog packets are sourced from the IP address of whichever interface the routing table selects as the exit interface for the destination. If that interface changes (due to link failure, routing reconvergence, or ECMP load balancing), the source IP changes. The syslog server may then fail to correlate messages to the correct device, or host-based alert rules may miss events because they are filtering on a specific source IP. A Loopback interface never goes down (unless explicitly shut), always has the same IP, and is reachable as long as any physical interface is up — making it the ideal stable source for management traffic like syslog, NTP, and SNMP.

5. Which syslog severity level captures interface state changes, OSPF adjacency established events, and configuration changes — but excludes DHCP lease assignments and other purely informational messages?

A. Level 4 — warnings B. Level 6 — informational C. Level 5 — notifications. Interface up/down (%LINEPROTO-5-UPDOWN), config changes (%SYS-5-CONFIG_I), and OSPF adjacency events (%OSPF-5-ADJCHG) are all generated at level 5. Setting logging trap notifications captures these while excluding the higher-volume level 6 informational messages like DHCP leases D. Level 3 — errors

Correct answer is C. IOS generates interface state change messages (%LINEPROTO-5-UPDOWN), configuration change notifications (%SYS-5-CONFIG_I), and routing protocol adjacency events (%OSPF-5-ADJCHG, %EIGRP-5-NBRCHANGE) all at severity level 5 (notifications). These are "normal but significant" events. DHCP lease assignments and other routine operational events are generated at level 6 (informational). Setting logging trap notifications captures everything at level 5 and below (levels 0–5) — including all the operationally important events — while excluding the higher-volume level 6 messages. See Syslog Severity Levels for the full event-to-level mapping.

6. A syslog server shows messages from a router with timestamps of `*Jan 1 00:04:22`. What is the most likely cause and fix?

A. The router is in the UTC+0 timezone — configure clock timezone GST 4 to fix the timestamp B. NTP is not configured or not yet synchronised — the device clock is at the IOS default epoch (Jan 1 2002, or relative to boot time). Configure ntp server [IP] and wait for sync, then verify with show ntp status. The asterisk (*) prefix confirms the clock is unsynchronised C. service timestamps log datetime is not configured — the router is using uptime format D. The syslog server's clock is wrong — the router timestamp is correct

Correct answer is B. The asterisk (*) at the start of a timestamp in IOS log messages is a critical indicator — it means the device clock is not synchronised with NTP. When a Cisco router has no NTP source, its clock starts at a default epoch (historically Jan 1 2002 00:00:00) and counts up from boot. The 00:04:22 time represents 4 minutes and 22 seconds since boot, not the actual time of day. All log entries will have meaningless timestamps until NTP synchronises the clock. Fix: configure ntp server [IP], verify with show ntp status (look for "Clock is synchronized"), and the asterisk prefix will disappear from timestamps once sync is achieved. See NTP Synchronisation.

7. What is the purpose of `logging facility local6` and when would you use different facility values for different devices?

A. It sets the TCP port that syslog uses — local6 corresponds to port 516 B. It restricts which VLANs syslog messages are forwarded from — local6 refers to VLAN 6 C. It sets the encryption level for syslog transmission — local6 enables AES-128 D. The facility code is a field in the syslog message header that identifies the source category. The syslog server uses it to route, store, or alert differently per source type. Using local5 for routers and local6 for switches allows the server to write them to separate log files, apply different retention policies, or trigger different alert rules without relying on source IP alone

Correct answer is D. Syslog facility codes are part of the standard syslog protocol (RFC 5424). They are a numeric value embedded in each syslog message that categorises the source. Standard facilities include kernel (0), mail (2), and system daemon (3). Facilities local0–local7 (codes 16–23) are reserved for custom use by administrators. Cisco IOS supports local0 through local7. By assigning consistent facility codes across the network — for example, all routers send local5, all switches send local6 — the syslog server can apply separate rules per device type. Verify the current facility setting with show running-config | section logging.

8. An engineer configures syslog but the buffer fills up within an hour and older events are lost. The current config is `logging buffered 4096 debugging`. What are the two best adjustments?

A. Increase the buffer size (logging buffered 65536) AND raise the buffer threshold from debugging to informational — this reduces the volume of messages stored by excluding verbose debug-level entries while retaining all operationally significant messages B. Disable console logging — it consumes the same buffer as the local store C. Reduce the syslog server threshold — fewer messages sent to the server means more space in the local buffer D. Configure a second logging host — distributing messages to two servers reduces buffer usage

Correct answer is A. The problem has two dimensions: the buffer is too small, and the threshold is too broad. 4096 bytes at debugging (level 7) means every single message — including extremely verbose debug output — is stored locally. The combined fix is to increase the size (logging buffered 65536 or larger, depending on available memory) and raise the threshold to informational (logging buffered 65536 informational). Level 7 (debugging) generates enormous volumes during active debug sessions. Changing to informational (level 6) retains all operationally relevant messages while excluding the verbose debug flood. Console and syslog server destinations have no effect on buffer size — they are completely independent destinations.

9. Which command adds millisecond-precision timestamps with timezone to IOS log messages, and why is the `localtime` keyword important in a multi-region network?

A. logging timestamps msec timezone — localtime ensures all devices use the same timezone B. service timestamps log msec show-timezone — localtime is the default and does not need to be specified C. service timestamps log datetime msec localtime show-timezone — localtime displays the event time in the device's configured local timezone rather than UTC. In a network spanning multiple regions, an analyst reviewing logs from devices in different timezones needs the timezone label (show-timezone) to correctly sequence events without manually converting UTC offsets D. clock set datetime msec timezone — this sets both the clock and timestamp format simultaneously

Correct answer is C. The full command is service timestamps log datetime msec localtime show-timezone. Without localtime, IOS displays timestamps in UTC regardless of the configured timezone — a device in UTC+4 (Gulf Standard Time) shows events at 10:22 UTC instead of 14:22 GST, which is confusing when the analyst is working in local time. The show-timezone keyword appends the timezone abbreviation (e.g., GST, EST, PST) to every timestamp — critical in multi-region networks. Best practice: ensure NTP is synchronised before relying on these timestamps. See NTP Synchronisation.

10. A security audit requires that all authentication failures on network devices be captured on the syslog server with accurate timestamps. The current syslog config has `logging trap errors`. Authentication failure messages are generated at severity level 5 (notifications). What changes are required?

A. No changes needed — logging trap errors (level 3) captures all events including level 5 B. Two changes: (1) logging trap notifications — raise the server threshold from errors (3) to notifications (5) so level 5 authentication failure messages are forwarded; (2) verify service timestamps log datetime msec is configured so each authentication failure has an accurate, auditable timestamp on the syslog server C. Configure logging trap debugging — this is the only level that captures authentication messages D. Authentication failures are not logged by IOS syslog — a separate RADIUS/TACACS server is required for authentication audit trails

Correct answer is B. The audit has two requirements: capture the events AND timestamp them accurately. Currently, logging trap errors (level 3) only forwards levels 0–3. Authentication failure messages (%SEC-6-IPACCESSLOGP, %LOGIN-5-LOGIN_FAILED, etc.) are generated at level 5 (notifications) or level 6 (informational) depending on the specific event — both above the current threshold of 3. Raising to logging trap notifications (level 5) captures level 5 auth failures. The timestamp requirement is addressed by service timestamps log datetime msec. For comprehensive authentication audit trails, also see Login Brute-Force Protection and AAA Authentication Methods.

Back to Home