The least glamorous config on the box, and the one you'll be most grateful for at 3am. Synchronized time so logs line up, centralized syslog so evidence survives a reboot, SNMPv3 so you're monitored, and NetFlow so you can answer "what was using all the bandwidth?" — after it already happened.
When something breaks at a client site, the difference between a five-minute diagnosis and a five-hour guess is whether the network was recording. Four services do that recording, and they're the first thing we configure on any device we take over — before VLANs, before routing. NTP gives every device the same clock, so a log line here and a log line there can be correlated. Syslog ships events off-box to a server that survives the device rebooting (or being wiped). SNMP lets a monitoring system poll health and receive alerts. NetFlow records who talked to whom, so "the internet was slow at 2pm" becomes an answerable question.
None of it is hard, and all of it is invisible until the day you need it — at which point its absence is catastrophic. This post is the "make the box tell you what it's doing" checklist, and it pairs directly with the recovery discipline from the Backup & Restore post: backups let you rebuild, telemetry tells you why you had to.
01
Every log timestamp, every certificate check, every correlation depends on accurate time. A device with the wrong clock produces logs you can't trust. Configure NTP before anything else that records.
# Set the zone so local time reads correctly (Greece = EET, +2, DST +1) R1(config)# clock timezone EET 2 0 R1(config)# clock summer-time EEST recurring last Sun Mar 3:00 last Sun Oct 4:00 # Point at upstream NTP servers (pool servers, or your own) R1(config)# ntp server 0.gr.pool.ntp.org R1(config)# ntp server 1.gr.pool.ntp.org # CRITICAL: stamp logs and debugs with the real date+time, not "uptime" R1(config)# service timestamps log datetime msec localtime show-timezone R1(config)# service timestamps debug datetime msec localtime show-timezone R1(config)# end # Confirm it locked (may take a few minutes to sync) R1# show ntp status Clock is synchronized, stratum 3, reference is 203.0.113.9
Out of the box, IOS stamps log messages with time since boot and a bogus "March 1" date (its epoch), and the leading * means the clock is unsynchronized. Correlating those across devices is impossible. The service timestamps log datetime command is the single most valuable line in this whole post — without it, NTP fixes the clock but your logs still don't show it. Set both log and debug timestamps, and confirm the * disappears from show logging once NTP syncs.
02
The device's local log buffer clears on reboot and holds only a few hundred lines. Send everything to a central syslog server so events survive, aggregate across devices, and can be searched and alerted on.
# Keep a decent local buffer too (survives until reboot) R1(config)# logging buffered 64000 informational R1(config)# service sequence-numbers # number lines so gaps are visible # Ship to the central collector, at severity "informational" (6) and above R1(config)# logging host 192.168.1.50 R1(config)# logging trap informational R1(config)# logging source-interface Loopback0 # stable source IP R1(config)# end # Verify the collector is receiving and see the buffer R1# show logging Trap logging: level informational, 842 message lines logged Logging to 192.168.1.50 (udp port 514, audit disabled)
Syslog severities run 0 (emergencies) to 7 (debugging); logging trap informational (6) is the sweet spot — you get link flaps, config changes, and security events without drowning in debug noise. Two refinements make it production-grade: log from a Loopback interface so every message carries the same source IP no matter which physical interface it left by (your collector groups by device cleanly), and remember that logging trap debugging (7) can flood a slow link — only raise it while actively troubleshooting. A config-change log (archive / log config) plus syslog gives you an audit trail of who changed what, when.
03
SNMP lets your monitoring platform poll interface counters, CPU, and memory, and receive traps. Use v3 — authenticated and encrypted — never v1/v2c, whose "community string" is a cleartext password on the wire.
# A view limiting what can be read, a group using it, and an encrypted user R1(config)# snmp-server view MON iso included R1(config)# snmp-server group MONITORING v3 priv read MON R1(config)# snmp-server user nms MONITORING v3 auth sha AuthPass123 priv aes 128 PrivPass123 # Send traps to the monitoring host (link up/down, config changes, etc.) R1(config)# snmp-server enable traps R1(config)# snmp-server host 192.168.1.50 version 3 priv nms R1(config)# snmp-server location Heraklion-Rack-1 R1(config)# snmp-server contact noc@noctis.gr R1(config)# end
snmp-server community public RO Is a Findings-Report Classic
SNMPv1/v2c authenticate with a plaintext "community string" that crosses the network in the clear — and default communities public/private are the first thing any scanner (and any pentester) tries. A readable v2c community leaks your entire config topology; a writable one (private RW) can reconfigure the device. On engagements this is a routine finding. Use v3 with priv (auth + encryption), restrict which hosts may poll with an ACL (snmp-server community … `<acl>` if you're truly stuck on v2c), and never leave a default community in place. This is the SNMP half of the management-plane hardening we'll consolidate later in the series.
04
Interface counters tell you a link was full; NetFlow tells you which conversations filled it. Three objects — a record (what to collect), an exporter (where to send it), and a monitor (tying them together) — applied to an interface.
# 1. RECORD — the fields that define a flow and the stats to keep R1(config)# flow record RECORD-1 R1(config-flow-record)# match ipv4 source address R1(config-flow-record)# match ipv4 destination address R1(config-flow-record)# match transport source-port R1(config-flow-record)# match transport destination-port R1(config-flow-record)# match ipv4 protocol R1(config-flow-record)# collect counter bytes R1(config-flow-record)# collect counter packets R1(config-flow-record)# exit # 2. EXPORTER — where to ship the flow data R1(config)# flow exporter EXPORT-1 R1(config-flow-exporter)# destination 192.168.1.50 R1(config-flow-exporter)# transport udp 2055 R1(config-flow-exporter)# exit # 3. MONITOR — bind record + exporter, then apply to the interface R1(config)# flow monitor MONITOR-1 R1(config-flow-monitor)# record RECORD-1 R1(config-flow-monitor)# exporter EXPORT-1 R1(config-flow-monitor)# exit R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip flow monitor MONITOR-1 input R1(config-if)# ip flow monitor MONITOR-1 output R1(config-if)# end
R1# show flow monitor MONITOR-1 cache sort highest counter bytes top 5 SRC ADDR DST ADDR PROT SRC DST BYTES 192.168.1.30 93.184.216.34 6 5512 443 248 M ← the bandwidth hog 192.168.1.44 140.82.121.4 6 6001 443 31 M ... # "What ate the internet at 2pm" — answered from the device itself.
05
Confirm each of the four is actually working — a silently-broken telemetry pipeline is worse than none, because you'll trust data that isn't arriving.
| Command | Confirms |
|---|---|
| show ntp status / associations | Clock synchronized, which server, stratum. |
| show logging | Syslog host, trap level, and the local buffer. |
| show snmp / show snmp user | SNMP engine up, v3 users and their auth/priv. |
| show flow monitor MONITOR-1 cache | Flows are being recorded. |
| show flow exporter statistics | Flow packets actually being sent to the collector. |
| show clock detail | Time source — "NTP" (good) vs "user configuration" (drifting). |
06
RouterOS offers every one of these; the crossover is direct.
| MikroTik / RouterOS | Cisco IOS |
|---|---|
| /system ntp client | ntp server |
| /system logging action remote + rule | logging host + logging trap |
| /snmp community (v3 user) | snmp-server user … v3 auth … priv … |
| /ip traffic-flow (+ target) | Flexible NetFlow record/exporter/monitor |
| /tool sniffer, /tool torch | show flow monitor cache |
Takeaways
service timestamps log datetime is the line that actually puts real time on your logs — without it, NTP alone doesn't help.logging trap informational is the noise/signal sweet spot.NOCTIS instruments the networks we manage — synced time, central logging, SNMP monitoring, and NetFlow — so an outage comes with evidence, not guesswork. For hotels and SMBs that need answers, not just a reboot.
Book a Discovery Call →