show logging – Syslog Messages, Severity Levels, and Troubleshooting

1. What Is Syslog?

Syslog is a standardised logging protocol (RFC 5424) used by network devices — routers, switches, firewalls, servers, and access points — to generate, store, and forward messages about events that occur on the device. Every time an interface goes up or down, a configuration change is made, an OSPF adjacency forms or breaks, or a security event occurs, the device generates a syslog message that describes what happened, when it happened, and how severe it was.

On Cisco IOS devices, syslog messages can be sent to four destinations simultaneously: the internal buffer (stored in RAM, viewed with show logging), the console (shown to anyone connected to the console port), monitor (shown to SSH/Telnet VTY sessions), and a remote syslog server (centralised, persistent, long-term storage).

  Syslog flow on a Cisco IOS device:

  Event occurs (interface down, config change, OSPF state change...)
       │
       ▼
  IOS generates syslog message
       │
       ├──→ Internal Buffer (RAM)   — viewed with: show logging
       │                              cleared with: clear logging
       │
       ├──→ Console port            — controlled by: logging console <level>
       │                              seen by anyone connected via console cable
       │
       ├──→ VTY/Monitor sessions    — controlled by: logging monitor <level>
       │                              must also run: terminal monitor on the session
       │
       └──→ Remote Syslog Server    — controlled by: logging host <IP>
                                       severity filter: logging trap <level>

2. Syslog Message Format — Field by Field

Every syslog message on a Cisco IOS device follows the same structured format. Being able to decode every component of a message instantly is a core CCNA skill and essential for real-world troubleshooting.

  Full syslog message example:

  *Jul 10 14:03:12.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
  │                    │ │    │ │        │
  │                    │ │    │ │        └─ Message text: human-readable description
  │                    │ │    │ │            of the event
  │                    │ │    │ └─ Mnemonic: SHORT_NAME describing the specific
  │                    │ │    │    event type within the facility (UPDOWN = the
  │                    │ │    │    interface changed operational state)
  │                    │ │    └─ Severity level: single digit (3 = Error)
  │                    │ └─ Facility: subsystem that generated the message
  │                    │    (LINK = the link layer / physical interface)
  │                    └─ % character: always present; marks start of the
  │                       facility-severity-mnemonic block
  └─ Timestamp: * = time NOT synchronised with NTP (may be inaccurate)
                Without *: time IS synchronised with NTP (reliable)

  Format breakdown:
  %FACILITY-SEVERITY-MNEMONIC: message text

  Examples:
  %LINK-3-UPDOWN        → facility=LINK, severity=3 (Error), mnemonic=UPDOWN
  %OSPF-5-ADJCHG        → facility=OSPF, severity=5 (Notice), mnemonic=ADJCHG
  %SYS-5-CONFIG_I       → facility=SYS,  severity=5 (Notice), mnemonic=CONFIG_I
  %SEC-6-IPACCESSLOGP   → facility=SEC,  severity=6 (Informational), ACL log

Field	Example	Description	Notes
Timestamp	`*Jul 10 14:03:12.123`	Date and time the event occurred; millisecond precision when `service timestamps log datetime msec` is configured	The leading `*` means the clock is NOT synchronised with NTP — timestamps may be unreliable; configure NTP to remove the asterisk
Facility	`%LINK`	The IOS subsystem that generated the message — identifies which component of the software or hardware the event relates to	Common facilities: LINK (interface layer), LINEPROTO (line protocol), OSPF, EIGRP, BGP, SYS (system), SEC (security/ACL), SW_MATM (MAC table), CDP, DHCP
Severity Level	`3`	Single digit 0–7 indicating how critical the event is; lower number = more severe	0=Emergency, 1=Alert, 2=Critical, 3=Error, 4=Warning, 5=Notice, 6=Informational, 7=Debug
Mnemonic	`UPDOWN`	Short uppercase label describing the specific event type within the facility — makes the message searchable and identifiable	Mnemonics are documented in Cisco's Error Message Decoder tool — always search by `%FACILITY-MNEMONIC` when researching an unfamiliar message
Message text	`Interface GigabitEthernet0/1, changed state to up`	Human-readable description of what happened, including device names, interface names, IP addresses, and other relevant specifics	This is the field you read for diagnostic details; the facility and mnemonic tell you the category, the text tells you the specifics

3. Syslog Severity Levels — All Eight Levels

Severity levels are the most tested aspect of syslog in the CCNA exam. There are eight levels, numbered 0 to 7. The lower the number, the more severe the condition. When you configure a logging destination with a severity level, the device sends that level and all lower-numbered (more severe) levels to that destination.

Level	Keyword	Meaning	Cisco IOS Examples	Typical Action
0	Emergency	System is completely unusable	System crash, hardware failure preventing boot	Immediate escalation — system is down
1	Alert	Immediate action required	Memory exhaustion, process crash affecting all services	Page on-call engineer immediately
2	Critical	Critical conditions; severe hardware or software failure	Module failure, supervisor failover, critical temperature threshold exceeded	Urgent investigation — service impact likely
3	Error	Error conditions requiring attention	`%LINK-3-UPDOWN` (interface state change), `%OSPF-3-NFSM` (OSPF FSM error), routing protocol errors	Investigate promptly — may impact connectivity
4	Warning	Warning conditions; not immediately harmful but may become so	Duplex mismatch detected, high CPU warning, HSRP state change	Review and plan corrective action
5	Notice	Normal but significant operational events	`%LINEPROTO-5-UPDOWN` (line protocol change), `%SYS-5-CONFIG_I` (config change), `%OSPF-5-ADJCHG` (adjacency change)	Log and monitor — part of normal operations
6	Informational	General informational messages about normal operations	ACL match logging (`%SEC-6-IPACCESSLOGP`), DHCP events, CDP neighbour changes	Log for auditing and compliance; low urgency
7	Debug	Highly detailed debugging output — not for production use	Packet-level traces, protocol state machine details; generated by `debug` commands	Use only during active troubleshooting; can cause high CPU; always run `undebug all` when finished

The "levels and below" rule: When you configure logging buffered warnings (level 4), the buffer receives levels 0, 1, 2, 3, and 4. It does NOT receive levels 5, 6, or 7. This is how you filter out informational noise and keep only the important messages for a given destination.

  Mnemonic to remember all 8 levels in order:
  "Every Awesome Cisco Engineer Will Need Debug Insight"
   0         1       2        3      4     5     6       (7=Debug)
  Emergency Alert  Critical Error Warning Notice Info   Debug

4. show logging Output — Full Annotation

The show logging command displays both the current logging configuration (buffer size, active destinations, severity filters) and the most recent messages stored in the buffer.

  Router# 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 debugging, 42 messages logged, xml disabled,
                       filtering disabled
      Monitor logging: level debugging, 0 messages logged, xml disabled,
                       filtering disabled
      Buffer logging:  level debugging, 107 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, 110 message lines logged
          Logging to 192.168.1.100  (udp port 514, audit disabled,
               link up),
               6 message lines logged

  Log Buffer (4096 bytes):

  *Mar  1 00:01:01.003: %SYS-5-CONFIG_I: Configured from console by admin on vty0 (192.168.1.50)
  *Mar  1 00:05:14.231: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/1 from LOADING to FULL
  *Jul 10 14:03:11.001: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to down
  *Jul 10 14:03:11.013: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to down
  *Jul 10 14:03:12.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to up
  *Jul 10 14:03:12.145: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to up

  Key observations from this output:
  ┌──────────────────────────────────────────────────────────────────┐
  │ Console logging: level debugging   → all 8 levels go to console  │
  │ Buffer logging:  level debugging   → all 8 levels stored in RAM  │
  │ Trap logging:    level informational → levels 0–6 sent to server  │
  │ Logging to 192.168.1.100 udp/514   → remote syslog server active │
  │ Log Buffer (4096 bytes)            → small; consider increasing   │
  │ * prefix on timestamps             → NTP NOT synchronised!        │
  └──────────────────────────────────────────────────────────────────┘

  Reading the log messages:
  Line 1: SYS-5-CONFIG_I   → config change from admin at 192.168.1.50
           (tracks who changed the config and from where)
  Line 2: OSPF-5-ADJCHG    → OSPF adjacency with 2.2.2.2 reached Full state
           (confirms OSPF neighbour came up successfully)
  Lines 3–6: LINK-3-UPDOWN + LINEPROTO-5-UPDOWN pair (down then up 1 second apart)
           → interface flapped once; investigate if repeated

5. Logging Destinations — Configuration and Severity Filters

Each logging destination is independently configured with its own severity filter. This allows you to store all levels locally in the buffer for troubleshooting while only forwarding critical messages to the syslog server to reduce traffic.

Destination	Configuration Command	Who Sees It	Key Notes
Buffer	`logging buffered <level> [size]`	Anyone running `show logging` on the device	Stored in RAM — lost on reload; the most useful destination for active troubleshooting; default 4096 bytes; increase with `logging buffered 65536`
Console	`logging console <level>`	Anyone connected on the physical console cable	Can slow IOS processing if debug-level is enabled; disable on production devices during debug: `no logging console`
Monitor (VTY)	`logging monitor <level>`	SSH/Telnet sessions that have run `terminal monitor`	Must run `terminal monitor` on each VTY session to see live logs; run `terminal no monitor` to stop
Syslog Server	`logging host <IP>`	The central syslog server (Splunk, Graylog, syslog-ng, ELK, etc.)	Uses UDP port 514 by default; set severity filter with `logging trap <level>`; use `logging source-interface` to ensure messages always originate from a stable IP

Severity Level Names vs Numbers in Commands

Cisco IOS accepts either the level number or the keyword in logging commands — they are equivalent:

  logging buffered warnings     ← by keyword (level 4 and below)
  logging buffered 4            ← by number (identical effect)

  logging console informational ← levels 0-6 to console
  logging trap errors           ← levels 0-3 to syslog server
  logging monitor notifications ← levels 0-5 to VTY sessions

  ! "notifications" is an alias for "notice" (level 5)

6. Complete Cisco IOS Syslog Configuration

! ── Step 1: Enable logging (on by default, shown for completeness) ──────
Router(config)# logging on

! ── Step 2: Configure buffer size and severity level ────────────────────
Router(config)# logging buffered 65536 ! 64 KB buffer (default 4 KB)
Router(config)# logging buffered debugging ! store all levels locally

! ── Step 3: Set console logging level ────────────────────────────────────
Router(config)# logging console warnings ! only levels 0–4 to console
! Use "no logging console" during debug sessions to prevent slowdown

! ── Step 4: Set monitor (VTY) logging level ──────────────────────────────
Router(config)# logging monitor informational ! levels 0–6 to SSH sessions
! On each VTY session, also run:
Router# terminal monitor

! ── Step 5: Configure remote syslog server ────────────────────────────────
Router(config)# logging host 192.168.1.100 ! primary syslog server IP
Router(config)# logging host 192.168.1.101 ! optional secondary server
Router(config)# logging trap informational ! send levels 0–6 to server
Router(config)# logging source-interface Loopback0 ! always use stable loopback IP

! ── Step 6: Add precise timestamps with milliseconds ─────────────────────
Router(config)# service timestamps log datetime msec localtime
! Adds: date, time, milliseconds, and local timezone to every log message
! Without this, timestamps may show only uptime (e.g., "00:05:14.231")

! ── Step 7: Synchronise time with NTP (critical for log correlation) ──────
Router(config)# ntp server 192.168.1.1
! NTP removes the * prefix from log timestamps, making them reliable
! See: NTP Overview

! ── Step 8: Prevent log messages from interrupting console input ──────────
Router(config)# line console 0
Router(config-line)# logging synchronous
! Syslog messages appearing mid-command are moved to a new line;
! the command you were typing is reprinted below — prevents confusion

! ── Verify the configuration ──────────────────────────────────────────────
Router# show logging

7. Common Syslog Messages — Decoded

Message	Severity	What It Means	What to Investigate
`%LINK-3-UPDOWN: Interface Gi0/1, changed state to down`	3 — Error	A physical interface has lost its link signal — the cable, transceiver, or connected device has lost connectivity at Layer 1	Check physical cable; inspect the SFP or transceiver; check the connected device's port; run `show interfaces Gi0/1` for error counters
`%LINEPROTO-5-UPDOWN: Line protocol on Interface Gi0/1, changed state to down`	5 — Notice	Layer 2 keepalives have stopped — the physical link may be up but the data-link layer protocol (HDLC, PPP, or Ethernet keepalives) is not running successfully	Almost always accompanies a LINK-3-UPDOWN; if physical is up but line protocol is down, check encapsulation mismatch on WAN links or duplex mismatch on Ethernet
`%SYS-5-CONFIG_I: Configured from console by admin on vty0 (192.168.1.50)`	5 — Notice	A configuration change was made — the message records who made it (username), from where (console/vty), and the source IP address	Audit trail — verify the change was authorised; compare `show running-config` before and after if something broke
`%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/1 from LOADING to FULL`	5 — Notice	An OSPF neighbour adjacency reached Full state — the two routers have exchanged their full LSDBs and routing can now occur	Normal healthy event; if it is followed by EXSTART or DOWN, the adjacency is flapping — check MTU mismatch, dead timer, or authentication
`%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/1 from FULL to DOWN`	5 — Notice	An established OSPF adjacency has been lost — the neighbour stopped sending Hello packets and the Dead timer expired	Check if the interface is still up; verify Hello/Dead timer match; check if the remote router is reachable; examine for MTU mismatch or authentication failure
`%SEC-6-IPACCESSLOGP: list ACL_IN permitted tcp 10.0.0.5(1234) -> 192.168.1.1(80)`	6 — Informational	An ACL with `log` keyword matched a packet — records the ACL name, action (permitted/ denied), protocol, source IP/port, and destination IP/port	Security audit; if unexpected IPs are being permitted or blocked, review the ACL entries
`%SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed`	2 — Critical	The router failed to allocate memory — system is under severe memory pressure; processes may crash or features may fail to initialise	Run `show processes memory sorted`; identify and remove memory-intensive processes; consider a hardware upgrade if memory is consistently exhausted
`%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on Gi0/1`	4 — Warning	CDPv2 detected that the native VLAN configured on each end of a trunk link does not match — this causes untagged VLAN traffic to be misassigned	Match the native VLAN on both ends of the trunk with `switchport trunk native vlan <n>` — see VLANs and 802.1Q Tagging

8. Buffer Management and the logging synchronous Command

  ! Check current buffer size and messages logged:
  Router# show logging
  Buffer logging: level debugging, 107 messages logged
  Log Buffer (4096 bytes):    ← only 4 KB default — easily overflows

  ! Increase buffer size:
  Router(config)# logging buffered 131072   ! 128 KB — stores many more messages

  ! Clear the buffer (removes all stored log messages):
  Router# clear logging
  Clear logging buffer [confirm]

  ! Suppress debug-level output from the console (prevents CPU overhead):
  Router(config)# no logging console
  ! or raise the level:
  Router(config)# logging console warnings

  ! logging synchronous — prevents syslog messages from interrupting
  ! command input at the console or VTY:
  Router(config)# line console 0
  Router(config-line)# logging synchronous

  Without logging synchronous (annoying):
  Router(config)# ip address 192.168
  *Jul 10 14:05:01.123: %LINK-3-UPDOWN: changed state to up
  .1.1 255.255.255.0    ← your command was split mid-entry

  With logging synchronous (clean):
  *Jul 10 14:05:01.123: %LINK-3-UPDOWN: changed state to up
  Router(config)# ip address 192.168.1.1 255.255.255.0
  ← command reprinted intact below the log message

9. NTP and Timestamp Accuracy

Accurate timestamps are the foundation of useful syslog. Without NTP, a router's clock may be wrong by hours or days, making it impossible to correlate events across multiple devices during an incident investigation. The leading * on every timestamp in show logging output is the tell-tale sign that the clock is not synchronised.

  Without NTP — unreliable timestamp:
  *Mar  1 00:05:14.231: %OSPF-5-ADJCHG: ...
  │
  └─ * means clock NOT synced with NTP
     "Mar 1" is the default time at boot — this could be any actual date

  With NTP — reliable timestamp:
  Jul 10 14:03:12.123: %OSPF-5-ADJCHG: ...
  │
  └─ No * means clock IS synced with NTP — timestamp is accurate

  NTP and timestamp configuration:
  Router(config)# ntp server 192.168.1.1
  Router(config)# ntp server 8.8.8.8 prefer       ! use Google's NTP
  Router(config)# service timestamps log datetime msec localtime

  Verify NTP synchronisation:
  Router# show ntp status
  Clock is synchronised, stratum 3, reference is 192.168.1.1

  Router# show ntp associations
  address         ref clock       st   when   poll reach  delay  offset  disp
  *~192.168.1.1   .GPS.            2     45     64   377   1.234  -0.123  0.456
  │
  └─ * means this is the selected NTP source (synchronised)
     ~ means configured as a peer

  Why accurate timestamps matter:
  Device A log: 14:03:12.001 — interface went down
  Device B log: 14:03:12.345 — OSPF adjacency lost
  → 344 ms gap confirms the OSPF loss was caused by the interface going down

  Without NTP, Device A might show 08:03:12 and Device B shows 14:03:12 —
  it looks like an 6-hour gap and the correlation is completely lost.

10. Remote Syslog Server — Integration and Security

The on-device buffer stores logs in RAM — they are lost on every reload and the buffer is small. For any production network, forwarding syslog messages to a remote server is essential for long-term retention, compliance, and security monitoring.

  ! Basic syslog server configuration:
  Router(config)# logging host 192.168.1.100
  Router(config)# logging trap informational      ! send levels 0–6
  Router(config)# logging source-interface Loopback0
  ! Using a loopback as source ensures messages always come from the
  ! same IP even if the physical interface used for routing changes.
  ! Without this, the source IP changes based on which interface the
  ! UDP packet exits — breaking log correlation with the device.

  ! Verify messages are reaching the syslog server:
  Router# show logging
  Trap logging: level informational, 110 message lines logged
      Logging to 192.168.1.100 (udp port 514, audit disabled, link up),
               110 message lines logged
  ! "link up" confirms the syslog server destination is reachable

  ! Check the UDP port 514 path:
  Router# ping 192.168.1.100   ← verify IP reachability first

Security Consideration	Risk	Mitigation
Plain-text UDP transmission	Standard syslog uses UDP port 514 with no encryption or authentication — messages can be intercepted or spoofed on the network path	Use syslog over TLS (TCP port 6514) for sensitive environments; restrict the syslog server to a dedicated management VLAN
Sensitive information in logs	Syslog messages may contain IP addresses, usernames, ACL match details, and routing information — useful intelligence for an attacker	Restrict access to the syslog server; use role-based access control on the syslog platform; log only the necessary severity levels
Log tampering	An attacker who compromises a device may clear the local log buffer (`clear logging`) to cover their tracks	Forward to a remote syslog server immediately — messages sent to the server cannot be deleted from the device; use write-once log storage on the server
Debug-level noise	Level 7 (Debug) generates enormous volumes of messages that can flood the syslog server and obscure important events	Never use `logging trap debugging` for remote servers in production; use `logging trap informational` or `logging trap warnings`

11. Step-by-Step Troubleshooting with show logging

Scenario A — Interface Flapping

  Engineer investigates intermittent internet loss on a core switch.
  Runs: show logging

  *Jul 20 10:12:05.789: %LINK-3-UPDOWN: Interface Gi1/0/24, changed state to down
  *Jul 20 10:12:08.799: %LINEPROTO-5-UPDOWN: Line protocol on Gi1/0/24, changed state to down
  *Jul 20 10:12:18.111: %LINK-3-UPDOWN: Interface Gi1/0/24, changed state to up
  *Jul 20 10:12:21.345: %LINEPROTO-5-UPDOWN: Line protocol on Gi1/0/24, changed state to up
  *Jul 20 10:15:30.021: %LINK-3-UPDOWN: Interface Gi1/0/24, changed state to down
  *Jul 20 10:15:33.099: %LINEPROTO-5-UPDOWN: Line protocol on Gi1/0/24, changed state to down

  Diagnosis:
  Interface Gi1/0/24 is FLAPPING — cycling up and down repeatedly.
  Each LINK-UPDOWN pair is followed by a LINEPROTO-UPDOWN pair.
  The 3-second gap between physical (LINK) and protocol (LINEPROTO) is normal.

  Investigation steps:
  1. show interfaces Gi1/0/24
     → Check "input errors", "CRC", "runts", "giants" for cable/hardware faults
  2. Physically inspect the cable — reseat both ends; try a replacement cable
  3. Check the device connected on the other end — is its port flapping too?
  4. If errors are high, move to a different port on the switch
  5. Consider errdisable: apply port security or storm control if the flapping
     is caused by a connected device

  Escalation indicator: if the same pattern repeats more than 5× in 10 minutes,
  escalate to hardware replacement.

Scenario B — Identifying Who Changed the Configuration

  Engineer investigates a routing outage that started at 14:05.
  Runs: show logging | include CONFIG

  *Jul 10 14:04:58.334: %SYS-5-CONFIG_I: Configured from console by netadmin on vty2 (10.0.0.50)

  Diagnosis:
  A configuration change was made 2 seconds before the outage began.
  User "netadmin" connected from 10.0.0.50 via SSH/Telnet (vty2).

  Next steps:
  1. show running-config → compare against last known-good backup
  2. show archive log config all → view exact commands entered (if archive
     logging is configured)
  3. Contact "netadmin" to determine what was changed and whether it was
     intentional

Scenario C — Tracking OSPF Adjacency Loss

  Engineer investigates missing routes in the routing table.
  Runs: show logging | include OSPF

  *Jul 10 13:58:01.001: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/1 from FULL to DOWN
  *Jul 10 13:58:01.012: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Gi0/2 from FULL to DOWN

  Diagnosis:
  Two OSPF adjacencies were lost simultaneously at 13:58:01.
  Simultaneous loss of multiple adjacencies often points to:
  → A problem on THIS router (not the neighbours) — CPU spike, memory
    allocation failure, or IOS bug caused the OSPF process to fail
  → A network-wide event (power outage, WAN failure)

  Cross-reference with hardware logs:
  *Jul 10 13:58:00.900: %SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed

  → Memory failure 100ms before both adjacencies dropped confirms the
    root cause: memory exhaustion caused the OSPF process to restart,
    dropping all adjacencies simultaneously.

  Fix: show processes memory sorted; identify and address memory issue.

See: OSPF Neighbor States | show interfaces | show ip protocols

12. Exam Tips & Key Points

Memorise all eight syslog severity levels in order — 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, 7 Debug. Lower number = more severe.
When you configure a logging level, it sends that level and all lower-numbered (more severe) levels. logging buffered warnings = levels 0, 1, 2, 3, and 4.
A leading asterisk (*) on a syslog timestamp means the clock is not synchronised with NTP — timestamps are unreliable. Fix with ntp server <IP>.
Know the four logging destinations and their commands: logging buffered (buffer), logging console (console port), logging monitor + terminal monitor (VTY sessions), logging host + logging trap (syslog server).
Know the syslog message format: %FACILITY-SEVERITY-MNEMONIC: message text
The most common CCNA syslog messages to know: %LINK-3-UPDOWN (physical interface change), %LINEPROTO-5-UPDOWN (line protocol change), %SYS-5-CONFIG_I (configuration change with who/where), %OSPF-5-ADJCHG (OSPF adjacency state change).
Interface flapping in logs = repeated %LINK-3-UPDOWN up/down cycles — suspect faulty cable, hardware, or connected device.
logging synchronous on a line prevents syslog messages from splitting console commands mid-entry.
service timestamps log datetime msec adds date, time, and milliseconds to every log entry — essential for event correlation.
Start troubleshooting with severity levels 0–3 (Emergency through Error) — these indicate conditions requiring immediate attention and are the most likely causes of outages.

13. Summary Reference Table

Topic	Key Detail
View buffer logs	`show logging`
Clear buffer	`clear logging`
Syslog message format	`%FACILITY-SEVERITY-MNEMONIC: message text`
Severity levels	0=Emergency, 1=Alert, 2=Critical, 3=Error, 4=Warning, 5=Notice, 6=Informational, 7=Debug
Buffer logging config	`logging buffered <level> [size]`
Syslog server config	`logging host <IP>` + `logging trap <level>`
See logs on SSH session	`logging monitor <level>` + `terminal monitor` on the session
Add timestamps	`service timestamps log datetime msec`
NTP for accurate time	`ntp server <IP>`
Unsynchronised clock indicator	Leading `*` on timestamp
Prevent command interruption	`logging synchronous` on console/VTY line
Interface flapping pattern	Repeated `%LINK-3-UPDOWN` down/up cycles
Config change audit trail	`%SYS-5-CONFIG_I` — logs username, session type, and source IP

Syslog and show logging Quiz

1. What is the primary purpose of syslog on a Cisco network device, and what are the four destinations logs can be sent to simultaneously?

A. To encrypt network traffic — syslog secures data in transit between devices using TLS B. To generate and store event log messages — the four destinations are: buffer (RAM, viewed with show logging), console port, monitor (VTY/SSH sessions), and a remote syslog server C. To manage user access control — syslog authenticates remote sessions and logs login attempts only D. To configure network interfaces — syslog provides a feedback mechanism when interface commands are entered

Correct answer is B. Syslog is the standardised logging protocol used by network devices to generate, store, and forward structured event messages. On Cisco IOS, log messages can be sent to four independent destinations simultaneously, each with its own severity filter: (1) Buffer — stored in RAM; viewed with show logging; lost on reload; configured with logging buffered; (2) Console — displayed to anyone connected on the console port; configured with logging console; (3) Monitor — sent to VTY/SSH sessions that have run terminal monitor; configured with logging monitor; (4) Syslog Server — forwarded remotely to a centralised log management platform; configured with logging host and severity filtered with logging trap.

2. What command shows the syslog messages stored in a Cisco device's internal buffer, and what does a leading asterisk (*) on a timestamp in that output indicate?

A. show syslog — displays all syslog messages; an asterisk means the message is high severity B. show log buffer — displays buffered syslog messages; an asterisk means the buffer is full and messages were overwritten C. show logging — displays buffered syslog messages and the logging configuration; an asterisk on a timestamp means the device clock is NOT synchronised with NTP, making the timestamp potentially inaccurate D. show logs — the correct Cisco IOS command; an asterisk means the message was generated by a debug command

Correct answer is C. show logging is the Cisco IOS command that displays both the current logging configuration (buffer size, active destinations and their severity levels) and the most recent messages stored in the internal buffer. The leading asterisk (*) on a timestamp is critically important: it indicates the device's clock has not been synchronised with an NTP server. Without NTP, the device uses its internal clock which starts at a default time on boot (often "Mar 1") and drifts over time. This makes it impossible to accurately correlate events across multiple devices during incident investigation. When the clock IS synchronised with NTP, the asterisk is absent and the timestamp is reliable. Fix with ntp server <IP> and verify with show ntp status.

3. Decode this syslog message: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down. What is the facility, severity level, and what does the message indicate?

A. Facility=LINK (interface layer subsystem), Severity=3 (Error), Mnemonic=UPDOWN — a physical interface has lost its link signal; severity 3 means this is an error condition requiring investigation B. Facility=UPDOWN (operational status system), Severity=3 (Warning), Mnemonic=LINK — a routing update was blocked C. Facility=LINK (interface layer), Severity=3 (Informational), Mnemonic=UPDOWN — a normal scheduled maintenance notification D. Facility=GIGABITETHERNET (hardware subsystem), Severity=0 (Emergency), Mnemonic=UPDOWN — the router is about to crash

Correct answer is A. The syslog message format is %FACILITY-SEVERITY-MNEMONIC: text. Breaking down %LINK-3-UPDOWN: the facility is LINK — the IOS subsystem responsible for the physical link layer (Layer 1 interface status); the severity is 3 — Error, indicating a condition that requires attention but is not system-critical; the mnemonic is UPDOWN — indicating an operational state change (the interface went up or down). The message text confirms the physical interface GigabitEthernet0/1 has gone down — the link signal has been lost. This is one of the most commonly seen syslog messages in production networks. It is almost always followed within milliseconds by a %LINEPROTO-5-UPDOWN message confirming the line protocol has also dropped.

4. Which syslog severity level represents a System Unusable condition, and if you configure "logging buffered warnings", which levels are stored in the buffer?

A. Level 1 (Alert) is System Unusable; "logging buffered warnings" stores only level 4 (Warning) B. Level 2 (Critical) is System Unusable; "logging buffered warnings" stores levels 4 through 7 C. Level 4 (Warning) is System Unusable; "logging buffered warnings" stores only Warning-level messages D. Level 0 (Emergency) is System Unusable; "logging buffered warnings" stores levels 0, 1, 2, 3, and 4 — the configured level AND all higher-severity (lower-numbered) levels

Correct answer is D. Severity level 0 (Emergency) represents the most severe condition — the system is completely unusable. The eight levels in order are: 0=Emergency, 1=Alert, 2=Critical, 3=Error, 4=Warning, 5=Notice, 6=Informational, 7=Debug. The critical rule for logging levels: when you set a logging destination to a particular level, the device sends that level and all numerically lower (more severe) levels. So logging buffered warnings (level 4) stores levels 0, 1, 2, 3, and 4 in the buffer — it does NOT store levels 5, 6, or 7 (Notice, Informational, Debug). This is how you filter out the routine informational noise while keeping all error-level and above messages. Setting logging buffered debugging (level 7) stores all 8 levels.

5. What is the purpose of configuring "logging host 192.168.1.100" on a Cisco device, and why should "logging source-interface Loopback0" be added alongside it?

A. To specify the buffer size for the 192.168.1.100 network segment; the source-interface ensures logs from that segment are tagged correctly B. To forward syslog messages via UDP port 514 to the remote syslog server at 192.168.1.100; adding logging source-interface Loopback0 ensures all syslog messages always originate from the stable loopback IP regardless of which physical interface the UDP packet exits C. To disable console logging and redirect all output to the specified IP; the source-interface setting disables the buffer D. To show the current logging configuration for the specified host; the source-interface specifies which log messages to display

Correct answer is B.

logging host
                  <IP>

configures the Cisco device to forward copies of syslog messages to a remote syslog server (e.g., Splunk, Graylog, syslog-ng) using UDP port 514. The severity filter for what gets sent is set separately with logging trap <level>. The logging source-interface command solves an important reliability issue: without it, the source IP address of the syslog UDP packet is determined by whichever interface the packet exits, which can change depending on routing table decisions. If a physical interface goes down and routes change, the source IP changes — the syslog server may treat messages from the new IP as coming from a different device, breaking log correlation. Using a loopback interface as the source provides a stable, always-up IP that remains constant regardless of physical interface state.

6. Which command clears the syslog buffer on a Cisco device, and what is important to understand about its relationship with a remote syslog server?

A. clear logs — also clears the remote syslog server database simultaneously B. clear syslog — deletes logs from both the buffer and any configured syslog servers C. clear logging — empties only the device's internal RAM buffer; messages already forwarded to a remote syslog server are NOT affected, which is why remote logging is important for security — an attacker who runs clear logging on a device cannot erase the server-side copies D. clear buffer — clears the logging buffer and also resets the syslog sequence counter

Correct answer is C. clear logging is the Cisco IOS privileged EXEC command that erases all messages currently stored in the device's internal logging buffer. After confirmation, the buffer is empty and show logging will show no stored messages. Critically, clear logging only affects the local on-device buffer — it has absolutely no effect on messages already forwarded to a remote syslog server. This has an important security implication: if an attacker or unauthorised user gains privileged access to a device and runs clear logging to cover their tracks (remove evidence of their activity), the remote syslog server still holds a complete copy of all messages that were forwarded before the clear. This is one of the primary security reasons for configuring remote syslog forwarding in production environments.

7. What is the effect of configuring "service timestamps log datetime msec" on a Cisco device, and why is this important for troubleshooting?

A. It enables syslog message encryption using AES — the msec parameter specifies 256-bit key strength B. It sets the logging severity filter to only store messages generated within the last millisecond C. It disables console logging and redirects all messages to the buffer with millisecond timestamps D. It adds the full date, time, and millisecond precision to every syslog message — without this, messages show only system uptime (e.g., "00:05:14"), making it impossible to determine when an event actually occurred relative to real time or to correlate events across devices

Correct answer is D. By default, Cisco IOS syslog messages show the system uptime (hours:minutes:seconds since last boot) rather than the actual date and time — for example, 00:05:14.231: %OSPF-5-ADJCHG tells you the event happened 5 minutes and 14 seconds after boot, but nothing about the actual calendar date or time. service timestamps log datetime msec changes this to include the full date and time with millisecond precision: Jul 10 14:03:12.123: %OSPF-5-ADJCHG. This is critical for troubleshooting because: (1) you can determine exactly when an event occurred in real time; (2) you can correlate events across multiple devices — if a cable was pulled at 14:03:12, you can see the interface going down at 14:03:12 and the OSPF adjacency dropping at 14:03:12 on different devices; (3) millisecond precision reveals the sequence of rapid events (which happened first when multiple things occurred almost simultaneously).

8. When troubleshooting a network outage using show logging, which severity levels should be examined first and why?

A. Levels 0 to 3 (Emergency through Error) — these indicate conditions that are directly causing failures: system crashes, memory exhaustion, interface outages, and routing errors; levels 4–7 represent warnings, notices, and informational messages that are less likely to be the direct cause of an outage B. Levels 4 to 7 (Warning through Debug) — these contain the most detail about what is happening on the device and are therefore more useful for troubleshooting C. Only level 7 (Debug) — this is the most detailed level and contains all the information needed to diagnose any problem D. Levels 5 and 6 (Notice and Informational) — these represent normal significant events and are the most useful for understanding network state changes

Correct answer is A. During active troubleshooting of an outage, the most productive starting point is the highest-severity messages. Levels 0–3 (Emergency, Alert, Critical, Error) indicate conditions that are directly causing failures: a level-0 Emergency means the system is unusable; level-2 Critical might be a module failure; level-3 Errors include interface outages (%LINK-3-UPDOWN), routing protocol errors, and other conditions that directly affect connectivity. These should be identified and investigated first because they are the most likely root cause of the outage. Levels 4–7 are progressively less urgent and should be reviewed after the critical events are understood. In particular, never start with level-7 Debug — debug output is extremely verbose and can obscure the important events you are looking for. Also note that enabling debug on a production router should be done very carefully as it can cause high CPU utilisation; always run undebug all when finished.

9. An engineer sees these repeated entries in show logging on a core switch: %LINK-3-UPDOWN down, %LINEPROTO-5-UPDOWN down, %LINK-3-UPDOWN up, %LINEPROTO-5-UPDOWN up — all on the same interface within seconds. What is this called and what are the likely causes?

A. Normal network operation — interface state changes are expected during normal OSPF or STP convergence events B. Interface flapping — the interface is cycling up and down rapidly; likely causes are a faulty cable, damaged SFP, failing NIC on the connected device, power issue on the connected device, or duplex/speed mismatch causing CRC errors that trigger the interface to reset C. Successful configuration changes — the interface is being reconfigured and the state changes reflect the new settings being applied D. A software update was applied to the device — the interface restarts multiple times as part of the update process

Correct answer is B. The pattern of repeated paired %LINK-3-UPDOWN down →

%LINK-3-UPDOWN
                  up

messages on the same interface within short time intervals is called interface flapping. The %LINEPROTO-5-UPDOWN pair always follows the physical LINK message because when the physical layer drops, the line protocol (Layer 2) necessarily also drops, and vice versa. Flapping is not normal operation — it indicates an unstable physical connection. Common causes: (1) a loose, damaged, or low-quality cable; (2) a failing SFP or transceiver; (3) the NIC or port on the connected device is failing; (4) power instability on the connected device causing it to reset repeatedly; (5) a severe duplex mismatch causing so many CRC errors that the interface resets. Investigation: show interfaces Gi1/0/24 and look for high input errors, CRC counts, or runts; physically inspect and replace the cable; try a different switch port.

10. Why is synchronising a device's clock with NTP critical for syslog, and what command adds millisecond precision to log timestamps?

A. NTP reduces log file size by compressing timestamp data; the command is "service timestamps log compress" B. NTP disables remote logging to prevent timestamp conflicts; the command is "ntp timestamps msec" C. NTP ensures all devices share the same accurate clock, making it possible to correlate events across multiple devices by timestamp — without NTP, each device has its own drifted clock making cross-device log analysis impossible; the command is "service timestamps log datetime msec" D. NTP enables AES encryption of log transmissions; the command is "logging encrypted datetime msec"

Correct answer is C. NTP synchronisation is fundamental to useful syslog for one primary reason: cross-device event correlation. In a real incident, events happen across multiple devices within milliseconds of each other. If each device has its own unsynchronised clock, Device A might show an event at 14:03:12 while Device B (whose clock is 6 hours off) shows a related event at 08:03:12. An engineer looking at these two logs cannot determine the relationship between the events. With NTP, both devices show 14:03:12.001 and 14:03:12.345 respectively — the 344ms gap immediately reveals the sequence and causal relationship. The leading asterisk (*) on timestamps in show logging output is the indicator that NTP is not synchronised. The command service timestamps log datetime msec adds the full date, time, and millisecond precision to every log message, and combined with NTP provides the accurate event timeline necessary for root-cause analysis.

← Back to Home