Cisco IOS Logging and Syslog Config: Levels, Buffer and Traps

The default Cisco logging configuration is actively unhelpful: the console is chatty, the buffer is tiny, and when the router reloads the evidence disappears with it. Getting logging right is one of the highest-return configuration changes on any device, because it decides whether you diagnose the next incident from a log or from memory. This guide sets severity levels deliberately, sizes the buffer and persistent storage, sends logs to the right destinations, and verifies timestamps so the log is actually usable in a correlator.

Severity levels, and which ones you actually want

Logging a level means logging that level and numerically lower. Most production devices belong at level 6 for the remote host, 5 for the local buffer during normal operation, and 7 only temporarily while debugging - level 7 permanently is how a router ends up with a log full of noise and 80% CPU.

A sane baseline configuration

service timestamps log datetime msec localtime show-timezone
service sequence-numbers
logging enable

! local buffer: big enough to survive a busy hour
logging buffered 10000000 informational
logging buffer size 10000000

! destinations
logging host 10.10.50.10 transport udp port 514
logging host 10.10.50.11 transport tcp port 601
logging trap informational
logging source-interface Loopback0
logging facility local6

! keep the console readable when you are on it
logging console warnings
logging monitor warnings
logging synchronous

! rate limiting, so a loop cannot flood the device
logging rate-limit 50 except 5
no logging message-counter syslog

logging source-interface is the line that makes syslog usable at scale: without it, logs arrive with whatever interface the device picked, and correlators produce duplicate or missing entries. Use a loopback that never flaps. service timestamps ... msec localtime show-timezone prevents the classic "log says 08:00 but the incident was at 16:00" mistake - and correct time requires working NTP, which is a prerequisite for meaningful logs.

Surviving a reload: persistent logging

logging persistent url flash0:/MYLOGS size 104857600 filesize 5242880
logging persistent url bootflash:/logs threshold 80 alert
show logging
dir flash0:/MYLOGS
show logging persistent

Persistent logging writes the buffer to flash in rotating files, which is what turns a reboot investigation from guesswork into a timeline. Watch the directory: when the allocation threshold is reached the oldest file is deleted, so size it for the retention you need (100 MB with 5 MB files is a reasonable starting point). Manage flash writes on devices with frequent log storms - or point persistent logging at USB/bootflash with more room.

Per-feature control and filtering

logging discriminator CRYPTO msg-body drops \^%CRYPTO
logging buffered discriminator CRYPTO
logging host 10.10.50.10 discriminator CRYPTO
show logging | include discriminator
show logging | include %LINK-3-UPDOWN
show logging count
show logging history

Discriminators keep known-noisy subsystems out of the buffer without losing them everywhere. Use them sparingly - filters that hide real faults are worse than noisy logs.

Verify, then alert on it

show logging | include Syslog logging
show logging | include Trap logging
show logging | include Buffer logging
show logging | include rate-limited
logging host 10.10.50.10 vrf MGMT
show ip socket | include 514
ping 10.10.50.10 source Loopback0

Confirm three things before you move on: the destination is reachable from the source interface, the trap level is what you intended, and messages are actually arriving at the collector. Then create alerts for what the log is telling you - config changes, interface flapping, authentication failures - rather than leaving someone to read it after the fact. Related reading: building a central rsyslog server, NTP for correct timestamps, Zabbix SNMP monitoring and SNMP troubleshooting.

Where each destination actually goes

Cisco IOS has four logging destinations, and they are independent. Understanding which one you are looking at explains almost every "the log does not show what I expected" complaint.

The trap is that each destination has its own level. Setting logging trap informational does not change what the console shows, and quieting the console does not change what the buffer keeps. Check each one explicitly with show logging and read the header block, which lists the status and level of every destination.

Reading a syslog message

Once logs leave the device, the text matters more than the CLI does. Every message follows the same shape, and knowing the parts makes filters and alerts far easier to write.

# <PRI>TIMESTAMP HOSTNAME SEQUENCE: FACILITY-SEVERITY-MNEMONIC: MESSAGE
<134>Mar  4 16:22:01 edge01 000123: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

# PRI = facility * 8 + severity.  local6 * 8 + 6 (informational) = 134
# FACILITY      = local6  (configurable with logging facility)
# SEVERITY      = 3 (error) - this is the level number
# MNEMONIC      = UPDOWN (the subsystem plus the specific event)

The priority value is what your collector uses to route the message before it ever parses text. Pick a facility your rsyslog or Graylog configuration already knows about, keep it consistent across the estate, and the severity becomes a reliable routing dimension rather than something you grep for.

It also explains why service sequence-numbers is worth enabling: it puts a monotonic counter on every message, which is the only reliable way to detect that logs were lost on the way to the collector. Without it, a gap in timestamps is ambiguous — you cannot tell whether nothing happened or whether messages were dropped.

Time is a logging feature

A log with the wrong timestamp is a log you cannot correlate, and correlation is the whole point of centralising. Three things have to be right.

service timestamps log datetime msec localtime show-timezone
clock timezone UTC 0
ntp server 10.10.0.10 prefer
ntp server 10.10.0.11
ntp source Loopback0
show ntp status
show ntp associations

! Confirm the clock is actually synchronised before trusting the log
show clock detail
show logging | include timezone

msec gives you millisecond resolution, which is the difference between ordering events correctly and guessing. show-timezone records whether the device thought it was UTC or local, which matters the day someone builds a device with the wrong clock timezone. And NTP is a hard prerequisite: a device with an unsynchronised clock will stamp a log with a time that could be hours out, and no amount of collector-side cleverness fixes that.

Persistent logging in practice

Persistent logging writes the buffer to flash as rotating files. It is the only destination that helps when the device reloads, which is exactly when you most need history.

logging persistent url flash0:/MYLOGS size 104857600 filesize 5242880
logging persistent url bootflash:/logs threshold 80 alert
logging persistent filter

show logging persistent
dir flash0:/MYLOGS
show file systems

! If your platform supports it, size the directory for the retention you need
configure terminal
 logging persistent url flash0:/MYLOGS size 209715200 filesize 10485760
end

The size is the total directory allocation and filesize is the size of each individual file. With a 100 MB directory and 5 MB files you keep about twenty rotations, so size it against the log rate you actually see, not a round number. The threshold and alert keywords warn you (or a syslog message) when the directory fills, at which point the oldest file is overwritten. Watch flash wear on platforms with busy logs, and prefer bootflash or USB storage where there is room.

Filtering without going blind

Noisy subsystems drown the log you need, but a filter that hides real faults is worse than a noisy log. Use discriminators surgically and always leave a copy somewhere unfiltered.

! Keep known-noisy crypto messages out of the buffer only
logging discriminator CRYPTO msg-body drops \^%CRYPTO
logging buffered discriminator CRYPTO

! The remote host still receives everything
logging host 10.10.50.10 transport udp port 514

! Conditional logging: only log when something else is happening
logging discriminator TRACE facility drops SEC
show logging | include discriminator
show logging count
show logging history 10

The discriminator is applied per destination, so the standard pattern is: filter the buffer so the live operator sees signal, and leave the remote collector unfiltered so you retain everything for the postmortem. show logging count is the important companion command — it shows how many messages of each severity were suppressed or rate-limited, so you can tell whether the filter is doing its job or hiding a storm.

Protecting the control plane from the log itself

Logging is a control-plane load as well as a diagnostic. A layer 2 loop or a flapping interface can generate enough messages to peg the CPU, and a device that is busy formatting log lines is a device that is dropping routing adjacencies.

logging rate-limit all 20 except errors
logging rate-limit 50 except 5
no logging console
no logging monitor
logging synchronous
service timestamps log datetime msec localtime show-timezone

! Watch what logging is costing you
show processes cpu sorted | include IP Input|Logger|syslog
show logging | include rate-limited

logging synchronous is a usability fix rather than a protection one: it stops messages appearing in the middle of a line you are typing, which prevents a whole category of accidental config errors. And printing rate-limited counts in the log is the signal that your device is shedding messages — if that number climbs during an incident, you are losing evidence precisely when you need it.

What to alert on, and what to just keep

The highest-return change most teams make is alerting on config-change messages rather than reading them a week later. A %SYS-5-CONFIG_I that does not match a change ticket is the single most useful log line a router produces.

Verify the whole chain before you move on

show logging
show logging | include Syslog logging|Trap logging|Buffer logging|Console logging
show logging persistent
show ip socket | include 514
ping 10.10.50.10 source Loopback0
show ntp status
! Then confirm on the collector that the last message arrived
tail -f /var/log/remote/edge01.log

Confirm five things: the destination is reachable from the source interface, the trap level is what you intended, the buffer and persistent destinations are enabled at the level you chose, the clock is synchronised, and a real message from the device appears at the collector. Only then is the logging configuration done — anything short of that is configuration that has not been tested.

Related reading: building a central rsyslog server, Cisco IOS NTP server and source interface, Grafana Loki log aggregation and IOS XR SNMP troubleshooting.

原文链接：https://www.cisco.com/c/en/us/support/docs/voice/telephony-signaling/212102-Configure-Persistent-Logging-on-Cisco-IO.html