Syslog Severity Levels (0–7) – Complete Guide

1. What Is Syslog?

Syslog is a standardised logging protocol (RFC 5424) that allows network devices — routers, switches, firewalls, servers, and access points — to send event and diagnostic messages to a centralised syslog server. Each message is tagged with a severity level (0–7) so that operators can quickly prioritise which events require immediate attention versus which are routine.

Syslog uses UDP port 514 by default (TCP 514 or TCP 6514 with TLS are also used for reliable/encrypted delivery). Messages travel from the sending device directly to the syslog server — there is no acknowledgement mechanism on UDP, so message loss under extreme load is possible.

  • Centralised log collection — all device logs in one place for search and correlation
  • Severity-based filtering — alert on level 0–3 immediately; archive 4–6 for review
  • Security auditing and compliance — syslog records who logged in, what changed, and when
  • Troubleshooting — trace an incident timeline across multiple devices using correlated timestamps

Related pages: show logging | show running-config | show interfaces | NTP Synchronisation | ACL Overview | Troubleshooting Methodology | Syslog Configuration Lab

2. Syslog Severity Levels 0–7

Syslog defines eight severity levels. Lower numbers are more severe; higher numbers are less critical. When you configure a logging level on a Cisco device (e.g., logging trap warnings), the device sends that level and all lower-numbered (more severe) levels to the destination.

Mnemonic to remember the order: “Every Awesome Cat Eats Whiskas Near Its Dish” (Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug)

Level Name Keyword Meaning Typical Cisco Example Action Required
0 Emergency emergencies System is unusable — complete failure Router crash, kernel panic, hardware failure Immediate — escalate at once
1 Alert alerts Immediate action required to prevent system failure Power supply failure, fan failure, disk full Immediate — on-call engineer
2 Critical critical Critical condition — primary function degraded BGP or OSPF neighbour down, redundant path lost Urgent — investigate within minutes
3 Error errors Error condition that should be corrected Interface CRC errors, input/output drops, AAA failure Same business day investigation
4 Warning warnings Potential problem — not yet an error High CPU utilisation, memory threshold crossed, duplicate IP Monitor closely; investigate if persistent
5 Notice notifications Significant but normal condition User login/logout, configuration saved, STP topology change Log and review periodically
6 Informational informational Routine operational messages — normal activity Interface up/down, OSPF adjacency formed, DHCP lease Archive; review during audits
7 Debug debugging Verbose diagnostic messages for troubleshooting Packet-level routing decisions, protocol state machine detail Enable only during active troubleshooting; disable immediately after

Key rule: When you set a logging level to n, the device forwards messages at severity n and all levels below it (i.e., more severe). Setting logging trap warnings (level 4) means you receive levels 0, 1, 2, 3, and 4 — not level 5, 6, or 7.

3. Syslog Message Format

Every syslog message from a Cisco IOS device follows a predictable format. Understanding each field helps you quickly parse log output during troubleshooting: 

*Dec 15 10:30:45.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
Field Example from Above Meaning
Timestamp *Dec 15 10:30:45.123 Date and time of the event; * means the clock is not synchronised (NTP not configured); milliseconds shown if service timestamps log datetime msec is enabled
Facility %LINEPROTO The software component or subsystem that generated the message (e.g., LINEPROTO = line protocol, SYS = system, OSPF = OSPF process)
Severity 5 The numeric severity level (0–7); here 5 = Notice
Mnemonic UPDOWN Short code identifying the specific message type within the facility
Description Line protocol on Interface GigabitEthernet0/0, changed state to down Human-readable description of what happened

The full pattern is: %FACILITY-SEVERITY-MNEMONIC: description 

! Additional examples:
%SYS-5-CONFIG_I: Configured from console by admin on vty0 (192.168.1.10)
%OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.2 on Gi0/0 from LOADING to FULL, Loading Done
%SEC-6-IPACCESSLOGP: list 101 denied tcp 10.0.0.5(1234) -> 192.168.1.1(80), 1 packet

4. Default Logging Levels on Cisco Devices

Cisco IOS sends log messages to four possible destinations, each with its own independently configurable severity level:

Destination Default Level Description Command to Configure
Console 7 (Debugging) Messages printed directly to the console terminal; can impact console performance at high log volumes logging console <level>
VTY (terminal monitor) Disabled by default Messages sent to active Telnet/SSH sessions; must be enabled per session terminal monitor (per session); logging monitor <level>
Buffered (RAM) 6 (Informational) Messages stored in a ring buffer in RAM; lost on reload; viewable with show logging logging buffered <size> <level>
Syslog server (trap) Not configured by default Messages forwarded to a remote syslog server over UDP 514; persistent and centrally managed logging host <IP> + logging trap <level>

5. Configuring Syslog on Cisco IOS

! Step 1: Enable timestamps so logs include date/time (highly recommended)
Router(config)# service timestamps log datetime msec localtime

! Step 2: Set the buffered log level and buffer size (stored in RAM)
Router(config)# logging buffered 64000 informational    ! 64 KB buffer, levels 0-6

! Step 3: Set the console log level (reduce in production to avoid console floods)
Router(config)# logging console warnings                ! Levels 0-4 to console

! Step 4: Specify the syslog server IP address
Router(config)# logging host 192.168.1.100

! Step 5: Set the trap level (what gets sent to the syslog server)
Router(config)# logging trap informational              ! Levels 0-6 to server

! Step 6: Set the source interface (so syslog messages always come from a stable IP)
Router(config)# logging source-interface Loopback0

! Optional: Specify a custom facility code for the syslog server to sort by device
Router(config)# logging facility local6

! Enable terminal monitor for the current SSH/Telnet session
Router# terminal monitor

6. Filtering Logs by Severity

Cisco IOS

! View all current log messages in the buffer
Router# show logging

! Filter buffer output to show only critical messages
Router# show logging | include %CRITICAL
Router# show logging | include %SYS-3
Router# show logging | include %OSPF

! View only messages at severity 3 (errors) and above in real time
Router# debug condition interface GigabitEthernet0/0

Linux (rsyslog)

# Filter syslog for error-level and above messages
grep -i "error\|critical\|alert\|emerg" /var/log/syslog

# Follow syslog in real time
tail -f /var/log/syslog

# Send a test message at local0.error level
logger -p local0.err "Test error message from network device"

7. Syslog Facility Codes

Every syslog message carries both a severity (0–7) and a facility code. The facility identifies the category of software or hardware that generated the message. On Cisco devices the facility appears in the message string (e.g., %SYS, %LINEPROTO); on Linux syslog servers the facility is a numeric code carried in the packet header.

Facility Code Keyword Typical Source
0 kern Kernel messages
1 user User-level messages
2 mail Mail system
3 daemon System daemons
4 auth Security and authentication messages
16–23 local0–local7 Locally defined — commonly assigned to network equipment (routers, switches, firewalls) on the syslog server to separate their logs

On Cisco IOS you choose which local facility to use with logging facility local<0–7>. Using a different facility per device type (e.g., local0 for routers, local1 for switches) allows the syslog server to route messages into separate log files automatically.

8. Local vs. Remote Syslog

Feature Local Logging (Buffered) Remote Syslog Server
Storage location RAM on the device (ring buffer) Persistent storage on centralised server
Retention Lost on every reload; overwritten as buffer fills Persistent across reboots; archived long-term
Access show logging on the device Web UI, CLI, or SIEM on the syslog server
Scalability Limited to one device at a time Aggregates logs from hundreds of devices simultaneously
Use case Quick on-device troubleshooting during an active session Compliance auditing, long-term forensics, cross-device correlation
Transport N/A — on-device UDP 514 (default), TCP 514, or TLS TCP 6514

Best practice: always configure both — buffered logging for immediate on-device diagnosis and remote syslog for persistence, compliance, and multi-device correlation.

9. Performance Impact of Logging Levels

Levels Volume CPU Impact Recommended For
0–3 (Emergency–Error) Very low — only genuine failures Negligible Always enabled; minimum threshold for any production system
4 (Warning) Low — potential problems before they become errors Minimal Production networks — recommended minimum for syslog trap level
5 (Notice) Moderate — normal significant events (logins, config saves) Low Production with audit requirements (compliance, change tracking)
6 (Informational) Higher — all routine events including interface changes Moderate; can generate significant log volume on busy networks Development, lab, or detailed production monitoring where storage allows
7 (Debug) Very high — every packet, protocol event, and state change High — can overwhelm the device CPU and crash a production router Active troubleshooting only; never leave enabled in production; disable immediately after use

10. Verification Commands

! View current logging configuration and buffered messages
Router# show logging

! Sample output (annotated):
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: level debugging, 42 messages logged
    Monitor logging: level debugging, 0 messages logged (inactive)
    Buffer logging:  level informational, 150 messages logged
    Trap logging:    level informational, 150 message lines logged
         Logging to 192.168.1.100  (udp port 514, audit disabled,
              link up),
              150 message lines logged

! Clear the logging buffer (useful after resolving an issue)
Router# clear logging

! Verify NTP is in sync (important for accurate timestamps)
Router# show ntp status

! Test that syslog server receives messages
Router# debug ip packet   ! Generates level 7 messages (use in lab only!)
Router# undebug all        ! Disable all debug immediately after testing

11. Best Practices

  • Always synchronise time with NTP before configuring syslog — without accurate timestamps, correlating events across devices is impossible; configure service timestamps log datetime msec localtime
  • Set logging trap to Warning (4) or lower for production — captures all genuine problems without the volume of informational noise; use logging trap warnings
  • Always configure a remote syslog server — on-device buffered logs are lost on reboot; use logging host <IP> pointing to a dedicated syslog/SIEM server
  • Use a stable source interface for syslog — logging source-interface Loopback0 ensures syslog packets always originate from the same IP even if a physical interface goes down
  • Set the console log level to Warning or higher in production — the default console level of 7 (Debugging) floods the console and can impact device performance; use logging console warnings
  • Never leave Debug (7) enabled in production — debug generates enormous log volume and can spike CPU to 100%, causing packet drops or a router crash
  • Use different facility codes per device type — logging facility local0 for routers, local1 for switches, etc. lets the syslog server sort messages into separate files
  • Configure log rotation — on Linux syslog servers, use logrotate to compress and archive old log files and prevent disk exhaustion
  • Set up alerting on levels 0–2 — Emergency, Alert, and Critical messages should trigger immediate on-call notifications via the SIEM or monitoring system

12. Key Points & CCNA Exam Tips

  • Syslog uses UDP port 514 by default; it is a one-way protocol (no acknowledgements)
  • There are eight severity levels: 0–7; lower number = more severe
  • Mnemonic: “Every Awesome Cat Eats Whiskas Near Its Dish” — Emergency (0), Alert (1), Critical (2), Error (3), Warning (4), Notice (5), Informational (6), Debug (7)
  • When you configure logging trap <level>, the device sends that level and all more severe levels (lower numbers); logging trap warnings sends 0–4
  • Cisco IOS has four independent logging destinations: console, VTY (terminal monitor), buffered, and syslog server (trap) — each can have a different level
  • The default console level on Cisco IOS is 7 (Debugging); the default buffered level is 6 (Informational)
  • Syslog message format: %FACILITY-SEVERITY-MNEMONIC: description
  • A * before the timestamp means NTP is not synchronised — always configure NTP before syslog for accurate logs
  • Use show logging to view buffered messages and verify current logging configuration
  • Debug (7) should never be left on in production — it can consume 100% CPU and cause device instability
  • Facility codes local0–local7 are reserved for custom use and are commonly assigned to network equipment on syslog servers

Syslog Logging Levels Quiz

1. What is syslog primarily used for?

Correct answer is D. Syslog (RFC 5424) is a standardised logging protocol that allows routers, switches, servers, and other devices to send event messages to a centralised syslog server over UDP port 514. This enables operators to monitor, alert on, and audit events across all devices from a single location.

2. Which syslog severity level represents the highest priority?

Correct answer is A. Severity level 0 (Emergency) is the most critical — it means the system is completely unusable. Examples include a router crash or kernel panic. In syslog, lower number = higher severity; level 7 (Debug) is the least critical.

3. What does a severity level 3 (Error) indicate?

Correct answer is B. Level 3 (Error) covers error conditions that do not prevent the system from operating but indicate something that needs to be addressed — such as interface CRC errors, AAA authentication failures, or packet drops. They are more serious than a warning (4) but less urgent than a critical failure (2).

4. Which severity level is used for normal operational messages like interface status changes?

Correct answer is C. Level 6 (Informational) covers routine operational messages that describe normal activity — interface up/down events, OSPF adjacency formation, DHCP leases, and similar events. These are the most common messages in a healthy network and form the basis of the default buffered logging level on Cisco IOS.

5. Which mnemonic correctly maps to the syslog severity levels in order from 0 to 7?

Correct answer is B. “Every Awesome Cat Eats Whiskas Near Its Dish” maps to: Emergency (0), Alert (1), Critical (2), Error (3), Warning (4), Notice (5), Informational (6), Debug (7). Memorising this is essential for the CCNA exam.

6. When you configure logging trap warnings on a Cisco device, which levels are sent to the syslog server?

Correct answer is A. When you set a logging level to n, the device sends messages at level n and all more severe levels (lower numbers). logging trap warnings sets the trap level to 4, so levels 0 (Emergency), 1 (Alert), 2 (Critical), 3 (Error), and 4 (Warning) are all forwarded to the syslog server. Levels 5, 6, and 7 are not sent.

7. What is the key advantage of remote syslog over local buffered logging?

Correct answer is D. The on-device buffer is stored in RAM and is lost every time the device reboots. A remote syslog server stores messages persistently, aggregates logs from all devices, and supports long-term archiving, compliance auditing, and cross-device event correlation — none of which are possible with local buffered logging alone.

8. Which logging level is recommended as the minimum trap level for a production environment?

Correct answer is B. Warning (4) is widely recommended as the minimum trap level for production networks. This captures all genuine failures (levels 0–3) plus potential problems before they escalate (level 4), without the log volume of Informational (6) or the performance risk of Debug (7). Setting it to Informational (6) is acceptable when storage is adequate and audit requirements demand it.

9. What is a significant risk of enabling Debug (level 7) logging on a production network device?

Correct answer is C. Debug logging generates an enormous volume of messages — every packet, protocol event, and internal state change. On a busy production router, this can consume 100% of CPU, causing the device to drop forwarded traffic or become unresponsive. Always use debug only in a controlled window, with care, and disable it immediately with undebug all when finished.

10. Which Cisco IOS command displays the current logging configuration and buffered messages?

Correct answer is A. show logging displays the current logging configuration (console level, buffered level, trap level, syslog server IP) as well as all messages stored in the on-device RAM buffer. It is the primary verification command for syslog on Cisco IOS. Use show logging | include <keyword> to filter for specific facility or severity strings.

← Back to Home