Logging- & Observability-Design: Syslog, Telemetry, NetFlow – was wirklich hilft

Observability im Netzwerk ist mehr als „ein paar Logs“: Du brauchst Events (was ist passiert?), Metriken (wie ist der Zustand?) und Flows/Telemetry (wer verursacht es?). In Cisco-Router-Umgebungen leisten Syslog, SNMP/Telemetry und NetFlow jeweils Unterschiedliches. Ein gutes Design kombiniert diese Quellen so, dass du Incidents schnell triagieren kannst, ohne in Daten zu ertrinken: klare Severity-Level, stabile Source-IPs, zentrale Zeitbasis (NTP) und ein bewusstes Datenmodell (welche Signale lösen Alerts aus, welche dienen der Analyse).

Das Zielbild: Events, Metrics und Flows sauber trennen

Jede Datenquelle beantwortet eine andere Frage. Wenn du versuchst, „alles mit Syslog“ zu lösen oder „nur SNMP“ zu nutzen, fehlen dir entscheidende Informationen.

• Syslog (Events): „Interface down“, „BGP neighbor reset“, „Auth failure“
• Metrics (SNMP/Telemetry): Auslastung, Drops, CPU, Memory, Jitter/Quality
• Flows (NetFlow): Top-Talker, Apps/Ports, wer/was füllt die Leitung

Merker

$\text{Incident-Triage}=\text{Events}+\text{Metrics}+\text{Flows}$

Syslog: Was wirklich hilft (und was nur Noise ist)

Syslog ist ideal für Zustandswechsel und Sicherheitsereignisse. In der Praxis hilft nicht „informational für alles“, sondern ein kuratierter Satz an Events mit sinnvoller Severity (z. B. warnings/notifications) und konsistenter Zeit.

• Hilfreich: Link up/down, Routing-Neighbor up/down, VPN Rekey-Fails
• Hilfreich: Login-Failures, AAA-Events, Config-Changes (wenn verfügbar)
• Noise: zu viele informational/debug Meldungen ohne Filter

Syslog-Baseline (NTP, Source, Severity)

service timestamps log datetime msec localtime
ntp server 10.255.0.10 prefer
ntp source loopback0
logging host 10.255.0.20

logging source-interface loopback0

logging trap warnings

logging buffered 16384 warnings

no logging console

SNMP vs. Streaming Telemetry: Metrics richtig wählen

SNMP ist weit verbreitet und reicht für viele Health-Checks (Interface, CPU, Memory). Streaming Telemetry (je nach Plattform/IOS XE) liefert Metriken push-basiert und kann granularer sein. Entscheidend ist nicht das Buzzword, sondern stabile, aussagekräftige SLO-Signale.

• SNMP: einfach, kompatibel, gut für Standard-Graphs und Alerts
• Telemetry: push-basiert, hohe Granularität, besser für moderne Observability
• Wichtig: weniger, aber „harte“ Alerts (z. B. Interface errors/drops, CPU > X)

SNMPv3-Baseline (Monitoring sicher machen)

ip access-list standard SNMP_MGMT
 permit 10.255.0.30
 deny any
snmp-server group NMS v3 priv access SNMP_MGMT

snmp-server user nmsuser NMS v3 auth sha Str0ngAuthP@ss priv aes 128 Str0ngPrivP@ss

snmp-server location SITE-{{ID}}

snmp-server contact noc@example.local

NetFlow: Flows als „Antwort auf: Wer ist schuld?“

Wenn ein Link voll ist, sagt dir SNMP nur „voll“. NetFlow zeigt dir die Top-Talker, Protokolle und Zielnetze. Das ist entscheidend für Incident-Triage, Kapazitätsplanung und Security (Anomalien, Scans, DDoS-Indizien).

• Use-Case: Top-Talker und Apps/Ports
• Use-Case: ungewöhnliche Verbindungen (z. B. Exfiltration-Indizien)
• Trade-off: mehr CPU/Memory als reines SNMP, daher gezielt einsetzen

Flexible NetFlow Baseline (Exporter + Monitor, kurz)

flow exporter EXP_NETFLOW
 destination 10.255.0.40
 source loopback0
 transport udp 2055
flow record REC_IPV4_BASIC

match ipv4 source address

match ipv4 destination address

match ip protocol

match transport source-port

match transport destination-port

collect counter bytes

collect counter packets
flow monitor MON_IPV4

record REC_IPV4_BASIC

exporter EXP_NETFLOW

cache timeout active 60

cache timeout inactive 15
interface gigabitEthernet0/1

ip flow monitor MON_IPV4 input

Was du wirklich alerten solltest: SLO-orientierte Signale

Ein häufiges Observability-Problem ist Alarmflut. Besser ist ein SLO-Ansatz: Alerts auf wenige Signale, die User-Impact stark korrelieren. Alles andere wird als „Investigation Signal“ gesammelt.

• Alert: Interface down / Line protocol down
• Alert: Default Route verloren / BGP/OSPF Neighbor down (kritisch)
• Alert: hohe CRC/Errors oder Output Drops (dauerhaft)
• Alert: CPU dauerhaft hoch oder Control-Plane Drops
• Investigation: Top-Talker via NetFlow bei Congestion

Designprinzip: Stabile Source-IPs und Management-Segment

Damit Logs/Telemetry in Firewalls/ACLs zuverlässig funktionieren, sollten Router stets aus einer stabilen Quelle senden (Loopback oder Management-Interface). Das erleichtert Whitelisting und verhindert „plötzlich kommt alles von einer anderen IP“ nach Failover.

• Loopback0 als Source für Syslog/SNMP/NetFlow (wenn geroutet)
• OOB/Mgmt-VLAN oder Mgmt-VRF für Management-Traffic
• ACLs: nur Collector/NMS/Logserver erlauben

Beispiel: Konsistente Source-Interfaces

logging source-interface loopback0
snmp-server trap-source loopback0

Security und Compliance: Observability ohne neue Angriffsfläche

Monitoring-Interfaces sind Angriffsziele. Daher: SNMPv3 statt v2c, Management-Zugriff per ACL, und keine Telemetrie „ins Internet“. Zudem solltest du Auth-Failures und Policy-Drops gezielt loggen.

• SNMPv3 authPriv, Zugriff nur von NMS-IP
• Syslog nur zu internen Logservern, nicht öffentlich
• NetFlow nur zu Collector im Management-Netz
• Auth-Failure-Events auswerten (Brute-Force/Recon)

Praxis-Pitfalls: Warum Observability oft scheitert

Die häufigsten Fehler sind nicht „fehlende Tools“, sondern fehlende Struktur. Wenn Zeit, Source-IPs oder Severity chaotisch sind, ist jede Auswertung mühsam.

• NTP fehlt → Logs sind zeitlich nicht korrelierbar
• Syslog zu laut → wichtige Events gehen unter
• SNMPv2c ohne ACL → Security-Risiko
• NetFlow überall aktiviert → unnötige Last, unklare Fragestellung
• Keine Baselines → Drift, unterschiedliche Formate pro Gerät

Verifikation: Funktionieren Syslog, SNMP und NetFlow wirklich?

Nach der Konfiguration verifizierst du jede Quelle separat: Syslog-Status, SNMP-User und ACL, NetFlow-Cache/Exporter-Stats. Das ist schneller als „im Tool nachsehen und raten“.

Syslog prüfen

show running-config | include logging
show logging
show ntp status

SNMP prüfen

show snmp user
show access-lists SNMP_MGMT

NetFlow prüfen

show flow exporter statistics
show flow monitor MON_IPV4 cache

Quick-Reference: Minimal-Baseline für Router-Observability

Diese Baseline ist ein solider Startpunkt: zentrale Zeit, Syslog und SNMPv3. NetFlow ergänzt du gezielt, wenn du Flow-Analysen brauchst.

service timestamps log datetime msec localtime
ntp server 10.255.0.10 prefer
ntp source loopback0
logging host 10.255.0.20

logging source-interface loopback0

logging trap warnings

logging buffered 16384 warnings

no logging console
ip access-list standard SNMP_MGMT

permit 10.255.0.30

deny any

snmp-server group NMS v3 priv access SNMP_MGMT

snmp-server user nmsuser NMS v3 auth sha Str0ngAuthP@ss priv aes 128 Str0ngPrivP@ss

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.