When a router or switch fails, the only evidence you may have is the log messages it generated before going dark. IOS logging is how network devices record events—from a simple interface flap to a catastrophic crash—and it's a core troubleshooting skill for the CCNA 200-301 exam (Objective 4.6: Configure and verify IOS logging). In production, centralized logging is the backbone of network monitoring, security auditing, and forensic analysis. This chapter covers local logging (buffered, console, terminal) and remote logging via syslog, including severity levels, facility codes, and the configuration commands you'll need to know for the exam and for real-world engineering.
Jump to a section
Imagine you're the captain of a large cargo ship. The ship has a black box that continuously records every engine reading, navigation command, and alarm—this is like the router's logging buffer, a circular memory that always keeps the most recent events. You also have a paper logbook where the first mate writes down important events like course changes, weather alerts, and equipment failures—this is like sending logs to a console or terminal session, where a human can read them in real time. Finally, the ship radios a daily report to the shipping company's headquarters, which aggregates logs from all vessels in the fleet—this is remote syslog, where a central server collects logs from every router and switch. If the ship sinks, the black box (logging buffer) preserves the last moments, but if it's damaged, the headquarters (syslog server) still has the daily reports. The captain sets the threshold for what gets recorded: a minor warning like 'port side light bulb out' might be ignored, but 'engine room fire' must be logged immediately—this mirrors severity levels. If the captain misconfigures the logbook (e.g., sets the threshold too high), critical events might be missed, just as a router with wrong logging severity settings can fail to capture a security breach. The analogy teaches that logging is about balancing storage (buffer size), immediacy (console), and permanence (remote server), all while filtering by importance (severity).
What is IOS Logging?
IOS logging is the mechanism by which Cisco devices record system messages (syslog messages) that describe events such as interface state changes, configuration changes, authentication failures, and hardware errors. These messages are generated by the device's operating system and can be directed to multiple destinations simultaneously: the console line (console logging), the internal buffer (buffered logging), a remote syslog server (remote logging), and active terminal sessions (monitor logging). The exam expects you to know how to configure and verify each of these destinations, understand the severity levels (0–7), and recognize the format of a syslog message.
Syslog Message Format
Every IOS syslog message follows a standard format defined by RFC 5424 (though IOS uses a slightly older variant). A typical message looks like this:
*Mar 1 00:12:34.567: %SYS-5-CONFIG_I: Configured from console by consoleBreaking it down:
- Timestamp: *Mar 1 00:12:34.567 – the date and time (if NTP is configured, it's accurate; otherwise it's relative to last boot). The asterisk indicates the timestamp is accurate (when NTP is used).
- Facility: %SYS – the source of the message (e.g., SYS for system, IF for interfaces, LINEPROTO for line protocols).
- Severity: 5 – a number from 0 (emergency) to 7 (debugging). In the message, it appears right after the facility, separated by a hyphen.
- Mnemonic: CONFIG_I – a short code describing the event.
- Message text: Configured from console by console – the human-readable description.
Severity Levels (0–7)
Cisco defines eight severity levels, and the exam expects you to know them by number and name. The lower the number, the more critical the event.
0 – Emergency: System is unusable (e.g., crash).
1 – Alert: Immediate action needed (e.g., critical temperature threshold exceeded).
2 – Critical: Critical conditions (e.g., hardware failure).
3 – Error: Error conditions (e.g., interface down).
4 – Warning: Warning conditions (e.g., configuration change).
5 – Notice: Normal but significant conditions (e.g., interface up).
6 – Informational: Informational messages (e.g., ACL match).
7 – Debugging: Debug messages (very verbose).
Common wrong answer on the exam: confusing severity 0 (emergency) with severity 7 (debugging). Remember: 0 is the most severe, 7 is the least.
Logging Destinations
Console Logging: By default, console logging is enabled with severity level 7 (debugging). This means all messages appear on the console. In production, you often reduce this to level 5 or 3 to avoid flooding. Command: logging console <level>.
Buffered Logging: Messages are stored in RAM in a circular buffer. By default, buffered logging is enabled with severity 7 and a buffer size of 4096 bytes (older IOS) or larger (newer IOS). The buffer wraps, so oldest messages are overwritten. Command: logging buffered <size> <level>. To view: show logging.
Monitor Logging: Sends messages to active VTY (Telnet/SSH) sessions. Disabled by default. Enable with logging monitor <level>, then the user must issue terminal monitor in their session.
Remote Logging (Syslog): Sends UDP packets (port 514) to a syslog server. Configure with logging host <ip-address> (up to 8 hosts). You can specify the source interface with logging source-interface <interface>. The default severity is 6 (informational). Command: logging trap <level>. Note: the syslog server must be reachable and listening on UDP 514.
How Logging Works Step by Step
An event occurs (e.g., interface goes down).
IOS generates a syslog message with facility, severity, mnemonic, and text.
The message is compared against the severity threshold for each destination. If the message's severity is numerically less than or equal to the configured level, it is sent to that destination. For example, if console is set to 5 (notice), then severity 0–5 messages go to console; severity 6–7 are blocked.
For remote logging, the message is encapsulated in a UDP segment (source port usually 514 or ephemeral) and sent to the syslog server IP.
The syslog server receives and stores the message (typically in a file).
Verification Commands
`show logging`: Displays the current logging configuration and the contents of the buffer. Example output:
Router# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 0 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 0 messages logged
Logging to: 192.168.1.100 (udp port 514, audit disabled)
Logging Source Interface: Loopback0
Log Buffer (4096 bytes):
*Mar 1 00:12:34.567: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:15:22.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up`show logging | include <keyword>`: Filters buffer contents.
`terminal monitor`: Issued from a VTY session to enable monitor logging for that session.
`debug <feature>`: Enables debugging for a specific feature; generates severity 7 messages. Always use with logging buffered or logging console to capture output.
Interaction with Other Features
NTP: Accurate timestamps in logs rely on NTP. Without NTP, timestamps are relative to boot (e.g., *Mar 1 00:00:00).
SNMP: SNMP traps are a separate notification mechanism, but syslog is often used alongside SNMP for event logging.
AAA: Authentication events generate syslog messages (e.g., %SEC_LOGIN-5-LOGIN_SUCCESS).
EEM: Embedded Event Manager can trigger actions based on syslog messages.
Defaults
Console logging: enabled, level 7 (debugging)
Monitor logging: disabled
Buffer logging: enabled, level 7, size 4096 bytes (or 8192 on some platforms)
Remote logging: disabled (no host configured)
Logging source interface: not set (uses outgoing interface IP)
Timestamps: disabled by default (but often enabled via service timestamps log datetime msec)
Enable timestamp service
By default, IOS does not include timestamps in log messages. This makes logs nearly useless for troubleshooting. Enable timestamps with the command `service timestamps log datetime msec` in global configuration mode. The `datetime` option shows the date and time (if NTP is configured) or time since boot. The `msec` keyword adds milliseconds. For debug messages, also enable `service timestamps debug datetime msec`. This is a common configuration that appears on the exam.
Configure buffered logging
Buffered logging stores messages in RAM. Use `logging buffered <size> <severity-level>`. For example, `logging buffered 16384 6` sets a 16 KB buffer and logs messages with severity 0–6 (informational and above). The default size is 4096 bytes, which is small for production. The buffer is circular; when full, the oldest messages are overwritten. To view the buffer, use `show logging`. The exam may ask you to determine the correct command to set the buffer size or severity.
Configure console logging
Console logging sends messages to the console port. By default, it logs everything (level 7). In production, you often reduce the severity to avoid console floods. Use `logging console <level>`. For example, `logging console 3` logs only emergencies, alerts, critical, and errors. To disable console logging, use `no logging console`. The exam tests that you know console logging is enabled by default and can be adjusted.
Configure monitor logging
Monitor logging sends messages to VTY (Telnet/SSH) sessions. It is disabled by default. Enable it with `logging monitor <level>` (e.g., `logging monitor 5`). However, the user must also issue the `terminal monitor` command in their session to actually receive messages. Without `terminal monitor`, no messages appear. This two-step process is a common exam trap. To stop receiving messages, use `terminal no monitor`.
Configure remote syslog server
To send logs to a central server, use `logging host <ip-address>`. You can specify up to 8 hosts. The default severity for remote logging is 6 (informational). Change it with `logging trap <level>`. For reliability, set the source interface with `logging source-interface <interface>` so the syslog server sees a consistent IP. Example: `logging host 192.168.1.100` then `logging trap 5`. Verify with `show logging`. The exam expects you to know the default UDP port (514) and that syslog uses UDP.
Verify logging configuration
Use `show logging` to see all logging settings and the buffer contents. Look for lines like 'Console logging: level debugging', 'Buffer logging: level debugging', and 'Logging to: 192.168.1.100'. Also check that timestamps are enabled with `show running-config | include service timestamps`. For remote logging, use `ping` to test reachability to the syslog server. If logs aren't appearing, check ACLs (UDP 514 must be permitted) and that the server is listening.
In a large enterprise network with hundreds of routers and switches, centralized logging is indispensable. A common deployment is to configure all devices to send syslog messages to a pair of syslog servers (e.g., using Linux rsyslog or a commercial SIEM like Splunk). The network engineer sets the logging trap level to 5 (notice) for most devices, which captures interface state changes, configuration changes, and errors without the noise of informational or debug messages. For critical infrastructure like core routers and firewalls, the level might be set to 3 (error) to ensure only serious issues are logged. The logging source interface is usually set to a loopback interface so that all logs from a device appear to come from a single IP, simplifying server-side filtering.
One real-world scenario: a network engineer notices intermittent connectivity issues. By checking the syslog server, they see repeated '%LINK-3-UPDOWN' messages on a trunk interface, indicating flapping. This leads to discovering a faulty SFP module. Without centralized logging, the engineer would have to manually check each device's buffer, which may have wrapped and lost the evidence.
Another scenario: security auditing. The syslog server logs every configuration change via '%SYS-5-CONFIG_I' messages. If an unauthorized change occurs, the logs show the source (console or VTY) and the username (if AAA is configured). This is critical for compliance with standards like PCI-DSS.
Common misconfigurations: setting the buffer size too small (e.g., 4096 bytes) so that important logs are overwritten quickly; forgetting to enable timestamps, making logs impossible to correlate; and using the wrong severity level, either missing critical events or flooding the server. Also, many engineers forget to configure the source interface, causing the syslog server to see different IPs for the same device (e.g., if logs are sent from different physical interfaces). This can cause server-side filtering issues. Finally, since syslog uses UDP, messages can be lost if the network is congested; for critical environments, consider using reliable syslog (RFC 3195) or a separate management network.
The CCNA 200-301 exam tests IOS logging under Objective 4.6: 'Configure and verify IOS logging'. Expect questions on severity levels, default settings, and configuration commands. The most common wrong answers include:
Confusing severity numbers: Candidates often think 7 is the most severe (it's the least) or that 0 is least. Remember: 0 = emergency (most severe), 7 = debugging (least).
Thinking 'terminal monitor' is a global command: It's a user-level command for the current session. The global command is logging monitor <level>. Many candidates believe terminal monitor enables monitor logging globally.
Assuming buffered logging is disabled by default: It's enabled by default with level 7. The exam might ask 'What is the default logging buffer size?' (4096 bytes on classic IOS, but newer IOS may have larger; exam typically uses 4096).
Forgetting that remote syslog uses UDP port 514: Some candidates think it's TCP or a different port. Also, the default severity for remote logging is 6 (informational), not 7.
For scenario questions: if a question says 'A network engineer wants to see debug messages on a Telnet session', the answer involves two commands: logging monitor 7 (global) and terminal monitor (user). If the question only mentions one command, it's incomplete.
Another trap: 'Which command shows the logging buffer?' The answer is show logging. Some candidates pick show log or show buffer log, which are not valid.
Key values to memorize:
Default console logging level: 7 (debugging)
Default monitor logging: disabled
Default buffer logging: enabled, level 7, size 4096 bytes
Default remote logging: no host configured
Syslog UDP port: 514
Maximum syslog servers: 8
Decision rule for multiple-choice: if the question asks about enabling logging to a remote server, the answer must include logging host <ip>. If it asks about seeing logs in a VTY session, look for both logging monitor and terminal monitor.
Syslog severity levels: 0=Emergency, 1=Alert, 2=Critical, 3=Error, 4=Warning, 5=Notice, 6=Informational, 7=Debugging
Default buffered logging is enabled with severity 7 and buffer size 4096 bytes
Remote syslog uses UDP port 514; default severity is 6 (informational)
Enable timestamps with 'service timestamps log datetime msec'
To receive logs on a VTY session, both 'logging monitor' (global) and 'terminal monitor' (user) are required
Use 'show logging' to view buffer contents and logging configuration
Console logging is enabled by default at level 7
These come up on the exam all the time. Here's how to tell them apart.
Console Logging
Logs appear directly on the console port
Enabled by default at level 7
No network dependency
Not persistent (scrolls off screen)
Configured with 'logging console <level>'
Remote Syslog
Logs sent as UDP packets to a server
Disabled by default (no host configured)
Requires IP reachability to server
Persistent storage on server
Configured with 'logging host <ip>' and 'logging trap <level>'
Mistake
Severity level 7 is the most critical and 0 is the least critical.
Correct
Severity 0 (Emergency) is the most critical, and 7 (Debugging) is the least critical. Lower numbers indicate higher priority.
Candidates often think '7' sounds more severe because it's a larger number.
Mistake
The command 'terminal monitor' globally enables monitor logging for all users.
Correct
'terminal monitor' is a user-level command that enables monitor logging for the current VTY session only. The global command is 'logging monitor <level>'.
The word 'terminal' makes it sound like a global configuration, but it's an EXEC command.
Mistake
Remote syslog uses TCP port 514 for reliable delivery.
Correct
Remote syslog uses UDP port 514. There is no built-in reliability; messages may be lost if the network is congested.
Candidates assume logging needs reliability, but syslog traditionally uses UDP for performance.
Mistake
Buffered logging is disabled by default to save memory.
Correct
Buffered logging is enabled by default with severity level 7 and a buffer size of 4096 bytes.
Candidates think default configurations are minimal, but IOS enables buffered logging out of the box.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'logging console' sends syslog messages to the physical console port (usually used for out-of-band management). 'logging monitor' sends messages to VTY (Telnet/SSH) sessions. Console logging is enabled by default at level 7; monitor logging is disabled by default. To receive monitor messages, the user must also issue the 'terminal monitor' command. On the exam, be careful: both are configured globally, but monitor logging requires an extra user-level command.
Use the 'show logging' privileged EXEC command. This displays the current logging configuration (console, monitor, buffer, and remote settings) and the contents of the buffer. If the buffer is large, you can filter with 'show logging | include <keyword>'. The buffer is circular, so the oldest messages are overwritten when full. The exam may ask you to identify the correct command to view logs.
The default logging buffer size is 4096 bytes (4 KB) on most IOS platforms. Some newer platforms may have larger default buffers (e.g., 8192 bytes), but the exam typically expects 4096. You can increase the buffer size with 'logging buffered <size>' (size in bytes). For example, 'logging buffered 16384' sets a 16 KB buffer.
Yes, you can configure up to 8 syslog servers using multiple 'logging host' commands. Each server receives all messages that match the severity threshold configured with 'logging trap'. There is no per-server severity filtering—all servers get the same messages. If you need different severities for different servers, you would need to use a log collector or use SNMP traps instead.
The timestamp 'Mar 1 00:00:00' is the default timestamp used when the device boots and has no accurate time source. Even if you set the clock manually, the logs may still show this until you enable NTP or configure 'service timestamps log datetime'. The command 'service timestamps log datetime msec' uses the system clock. If the clock is not set or NTP is not synchronized, the timestamp will still show the boot time. Always use NTP for accurate logging.
The facility code indicates which IOS subsystem generated the message. For example, %SYS indicates system messages, %LINK indicates interface link messages, %LINEPROTO indicates line protocol messages, %SEC indicates security messages, etc. The facility is part of the message format: %FACILITY-SEVERITY-MNEMONIC: message text. The exam may ask you to interpret a syslog message, so you should recognize common facilities like SYS, LINK, and LINEPROTO.
To disable console logging, use the command 'no logging console' in global configuration mode. This stops all syslog messages from appearing on the console. Alternatively, you can set the severity level to a very high number (like 7) to allow all, but to disable, use 'no logging console'. Note that disabling console logging does not affect other logging destinations.
You've just covered IOS Logging — Local and Remote — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?