When something breaks at 3 a.m., the first question is "what changed, and when?" Syslog is the answer, but only if you set it up before the outage: severity levels chosen deliberately, messages shipped off-box to a collector, and clocks synced so the timeline means something. This article configures Cisco IOS XE logging to a real Linux syslog server and reads the actual messages that arrive, as part of the IP Services complete guide.
Anatomy of a Syslog Message
Here is a real message captured on the collector during this lab:
2026-07-10T15:53:28.713914-07:00 10.0.13.2 114: *Jul 10 22:53:27.685: %LINK-3-UPDOWN: Interface Loopback1, changed state to upReading left to right: the collector's own receive timestamp, the source router (10.0.13.2), the router's message sequence number (114), the router's local timestamp, and then the Cisco message body. That body always follows one pattern:
%FACILITY-SEVERITY-MNEMONIC: description
%LINK - 3 - UPDOWN : Interface Loopback1, changed state to upFacility is the subsystem that spoke (LINK, LINEPROTO, SYS, OSPF, SEC_LOGIN). Severity is the number you filter on. The mnemonic identifies the exact event type, which is what you grep for.
The Eight Severity Levels
Severities run 0 through 7, and lower is worse. The classic mnemonic: Every Awesome Cisco Engineer Will Need Ice cream Daily.
One subtlety that shows up in interviews: setting a level means "log this severity and everything worse." logging trap informational sends severities 0 through 6, not just 6.
Where Messages Go
IOS XE can deliver every message to four places independently: the console line (logging console), VTY sessions (logging monitor plus terminal monitor when you want it live in SSH), the in-memory buffer (logging buffered, your first stop during troubleshooting), and one or more remote collectors (logging host). The buffer disappears on reload and the console only helps if you are watching it, which is why the collector matters: it is the copy that survives the incident.
logging host 192.168.99.100
logging trap informationalThat is the entire router-side configuration used in this lab. Verify what is actually being sent:
R1#show logging | include Trap logging|logging host
Trap logging: level informational, 220 message lines logged
Logging to 192.168.99.100 (udp port 514, audit disabled ...The Collector Side: rsyslog in 6 Lines
Any Linux box becomes a syslog collector with rsyslog's UDP input module. This is the exact configuration the lab VM runs (as /etc/rsyslog.d/10-ciscolab.conf), filtering lab devices into their own file:
module(load="imudp")
input(type="imudp" port="514")
if ($fromhost-ip startswith "10.0." or $fromhost-ip startswith "192.168.99.") then {
action(type="omfile" file="/var/log/ciscolab.log")
stop
}Then we caused some events (an interface bounce on R3, an SSH login to R1) and read the file:
j@llmbits:~$ sudo tail /var/log/ciscolab.log
2026-07-10T15:53:26.748667-07:00 10.0.13.2 111: *Jul 10 22:53:25.720: %SYS-5-CONFIG_I: Configured from console by cisco on vty0 (192.168.99.100)
2026-07-10T15:53:27.715614-07:00 10.0.13.2 113: *Jul 10 22:53:27.685: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up
2026-07-10T15:53:28.713914-07:00 10.0.13.2 114: *Jul 10 22:53:27.685: %LINK-3-UPDOWN: Interface Loopback1, changed state to up
2026-07-10T15:53:31.948104-07:00 192.168.99.1 219: Jul 10 22:53:31.240: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: cisco] [Source: 192.168.99.100] [localport: 22] at 22:53:31 UTC Fri Jul 10 2026Look at what you get for free: who configured what from where (%SYS-5-CONFIG_I names the user, the line, and the source IP), interface state history with timestamps, and an authentication audit trail (%SEC_LOGIN-5-LOGIN_SUCCESS). During the login hardening lab, failed brute-force attempts landed in this same file as %SEC_LOGIN-4-LOGIN_FAILED, which is exactly the signal a SIEM alerts on.
The Local Buffer: Your First Stop in an Incident
Before you ever reach for the collector, show logging on the device itself shows the in-memory buffer. Size it deliberately, because the default is small enough that a busy OSPF event can push the interesting lines out before you log in:
logging buffered 64000 informational
service timestamps log datetime msec localtime show-timezone
service sequence-numbersThe service timestamps line is why the captured messages above carry millisecond timestamps: without it you get relative uptime stamps that are useless for correlation. service sequence-numbers adds the incrementing counter (the 114: in the capture), which lets you spot dropped messages: if the collector has 113 and 115 but no 114, a datagram died in transit, and with UDP transport nothing will retransmit it.
Two more line-level behaviors worth setting everywhere: logging synchronous on console and VTY lines stops log output from splicing itself into the middle of whatever command you are typing, and logging console warnings keeps a chatty box from drowning the console during an event storm while still showing you severities 0 through 4.
Operational Discipline
Three practices turn logging from noise into evidence. First, sync clocks with NTP; correlating an event across five devices requires their timestamps to agree, and a beautiful pipeline of lies is worse than no logs at all. Second, pick trap levels deliberately: informational (6) to the collector is the sane default, debugging (7) only ever temporarily and only for a targeted debug, because a single debug ip packet at severity 7 can generate more log volume than the rest of the network combined. Third, remember syslog over UDP 514 is fire-and-forget cleartext; a dropped datagram is a lost log line, and anyone on the path can read it. rsyslog and IOS XE both support TCP and TLS transport when logs cross untrusted segments.
Also decide what source address your devices log from. By default the packet leaves with the egress interface's address, which means the same router shows up in your collector under different IPs depending on routing at that moment (you can see it in the captures above: R3's messages arrived from 10.0.13.2, its egress toward the collector). logging source-interface Loopback0 pins every message to one stable, identifiable address, which keeps collector-side filtering and per-device log files sane.
Key Takeaways
Syslog messages follow %FACILITY-SEVERITY-MNEMONIC, severities run 0 (emergency) to 7 (debugging), and configuring a level always includes everything more severe. Two commands (logging host, logging trap informational) ship every meaningful event to a collector, and six lines of rsyslog catch them in a dedicated file. The captured output shows the payoff: config-change attribution, interface history, and login auditing, all timestamped. Pair it with NTP or the timeline lies to you. The rest of the day-2 stack (SNMP for polling, NTP for time, DHCP for addressing) is in the IP Services complete guide.
