Cisco-Router-Monitoring: Syslog, SNMP und Alerting für den Betrieb

Cisco-Router-Monitoring ist die Grundlage für stabilen Betrieb: Ohne Syslog, SNMP und sauberes Alerting bleiben Ausfälle und Performance-Probleme zu lange unentdeckt. Ein gutes Monitoring-Setup liefert nicht nur „Gerät erreichbar“, sondern erkennt Link-Flaps, Fehlerzähler, CPU-Spikes, VPN-Probleme und Routing-Instabilität frühzeitig. Dieser Leitfaden zeigt praxisnahe Mindeststandards, sichere Konfigurationen und eine Alerting-Logik, die im Alltag funktioniert.

Monitoring-Zielbild: Was im Betrieb wirklich überwacht werden sollte

Monitoring muss die kritischen Pfade abdecken: WAN, LAN-Gateway, VPN, Routing und Ressourcen. Ziel ist nicht „alles messen“, sondern die richtigen Signale so zu alarmieren, dass Tickets sinnvoll und wiederholbar sind.

• Erreichbarkeit: Router, Management-IP, Default-Route/Upstream
• Interfaces: Status, Flaps, Errors/CRC, Drops, Auslastung
• Ressourcen: CPU, Memory, Plattformressourcen
• Routing: OSPF/EIGRP/BGP Nachbarschaften, Route-Änderungen
• VPN: IKEv2/IPsec SAs, Tunnelstatus, DPD/Rekey-Events
• Security/Betrieb: Login-Events, Konfigänderungen, Policy-Fehler

Grundvoraussetzungen: Zeit, Identität und saubere Namenskonventionen

Ohne korrekte Zeitstempel sind Logs kaum korrelierbar. Ebenso wichtig: eindeutige Hostnames und Interface-Descriptions, damit Alarme sofort einem Standort und Pfad zugeordnet werden können.

• NTP aktivieren (idealerweise redundant)
• Log-Timestamps aktivieren
• Hostname/Standortcode und Interface-Beschreibungen standardisieren

Beispiel: NTP und Log-Timestamps

service timestamps log datetime msec
ntp server 192.0.2.10 prefer
ntp server 192.0.2.11

Syslog: Ereignisse zentral erfassen und auswerten

Syslog ist die Ereignisspur des Routers: Interface up/down, Routing-Events, VPN-Probleme, Authentifizierungsfehler. Zentralisiertes Syslog ist Pflicht, weil lokale Puffer bei Störungen schnell überschrieben werden.

Best Practices für Syslog im Betrieb

• Syslog an zentrale Instanz (SIEM/NMS/Logserver) senden
• Sinnvolles Log-Level wählen (zu viel erzeugt Lärm, zu wenig übersieht Events)
• Zusätzlich lokales Logging als Kurzpuffer aktivieren
• Quellinterface festlegen, damit Logs eindeutig zuordenbar sind

Beispiel: Syslog-Baseline

service timestamps log datetime msec
logging buffered 64000 informational
logging host 192.0.2.20
logging trap informational
logging source-interface GigabitEthernet0/1

Erwartete Ergebnisse bei Syslog

• Interface-Flaps erscheinen als Events mit Zeitstempel
• VPN-/Routing-Events sind zentral sichtbar (auch wenn der Router rebootet)
• Alarme können aus Logmustern abgeleitet werden (z. B. „Tunnel down“)

SNMP: Metriken und Zustände sicher abfragen (SNMPv3)

SNMP liefert Messwerte: Interface-Bytes, Errors, CPU, Memory und Status. Im Unternehmen ist SNMPv3 mit Authentifizierung und Verschlüsselung der Mindeststandard. SNMPv2c mit Community-Strings sollte vermieden werden.

SNMPv3 Mindeststandard

• SNMPv3 Group mit „priv“ (Auth + Privacy)
• SNMPv3 User mit SHA + AES
• Zugriff auf NMS-Quellnetze beschränken (zusätzlich per ACL)

Beispiel: SNMPv3 Konfiguration

snmp-server group NMS v3 priv
snmp-server user snmpmon NMS v3 auth sha <AUTH> priv aes 128 <PRIV>
snmp-server location "BER-FIL01"
snmp-server contact "noc@example.local"

Optional: SNMP-Zugriff per ACL einschränken

ip access-list standard ACL-SNMP-NMS
 permit 192.0.2.30
 deny   any

Traps vs. Polling: Was ist sinnvoll?

In der Praxis ist die Kombination ideal: Polling misst Trends (Auslastung, Errors), Traps melden Ereignisse sofort (Link down, Authentication Fail). So erhalten Sie sowohl Reaktionsfähigkeit als auch Daten für Kapazitätsplanung.

• Polling: Auslastung, Errors, CPU/Memory, Trendanalyse
• Traps: Interface up/down, Cold/Warm Start, Auth Fail, VPN/Routing Events (je nach Plattform)
• Wichtig: Traps nur gezielt aktivieren, sonst entsteht Alarmflut

Beispiel: Traps aktivieren (kompakt)

snmp-server enable traps
snmp-server host 192.0.2.30 version 3 priv snmpmon

Alerting-Design: Alarme, die im Betrieb wirklich helfen

Gutes Alerting ist nicht „alles rot“. Es unterscheidet zwischen Ereignissen (sofort), Trends (Schwellwert) und Korrelation (mehrere Signale gleichzeitig). So werden Tickets aussagekräftig und vermeiden unnötige Eskalationen.

Pflicht-Alarme (hoch priorisiert)

• WAN-Interface down oder Link-Flapping
• Default-Route/Upstream nicht erreichbar (Path-Down, nicht nur Link-Down)
• CPU dauerhaft hoch (z. B. > 80% über mehrere Minuten)
• Interface Errors/CRC steigen signifikant
• VPN Tunnel down oder IPsec SA zählt keine Pakete (bei aktivem Traffic)
• Routing-Nachbarschaft down (OSPF/EIGRP/BGP), sofern produktionskritisch

Empfohlene Schwellenwerte (praxisnah, an Umgebung anpassen)

• Interface Flaps: > 3 Flaps in 10 Minuten
• CRC/Input Errors: kontinuierlicher Anstieg, nicht nur einzelne Events
• Output Drops: wiederkehrend, korreliert mit Peak-Zeiten
• CPU: > 80% für 5–10 Minuten, oder Spitzen > 95% wiederholt
• Memory: dauerhaft hoher Verbrauch oder rapide Anstiege (Leak-Indikator)

Path-Monitoring: Upstream-Ausfälle erkennen (IP SLA)

Viele Störungen sind „Link up, Internet down“. IP SLA misst die Erreichbarkeit eines Zieles über den WAN-Pfad und eignet sich sowohl für Failover-Designs als auch für präzises Alerting („Providerpfad gestört“).

Beispiel: IP SLA für Internet-Path-Monitoring

ip sla 10
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now

Verifikation IP SLA (für Betrieb/SOP)

show ip sla statistics
show track

VPN- und Routing-Monitoring: Was Sie überwachen sollten

VPN und Routing sind oft die kritischsten Bausteine in Filial- und Enterprise-Edges. Monitoring sollte Status und Qualität abbilden: „SA up“ reicht nicht, wenn keine Pakete fließen oder Nachbarschaften flappen.

VPN Monitoring: Mindestchecks

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail

• Alarm, wenn IKEv2 SA down oder ständig rekeyt
• Alarm, wenn IPsec SA keine Pakete zählt (bei erwartetem Traffic)

Routing Monitoring: Nachbarschaften und Stabilität

show ip ospf neighbor
show ip eigrp neighbors
show bgp summary

• Alarm, wenn produktive Nachbarschaften down
• Alarm, wenn häufige State-Wechsel auftreten (Flapping-Indikator)

Konfigurations- und Security-Events: Betriebssicherheit erhöhen

Neben Performance sollten sicherheitsrelevante Events erfasst werden: fehlgeschlagene Logins, Management-Zugriffe außerhalb erwarteter Netze und Konfigänderungen. Das verbessert Incident Response und Audit-Fähigkeit.

• Syslog für Login-Events und VTY-Zugriffe auswerten
• Management-ACLs strikt halten, damit „Scanner“ nicht ständig triggern
• Konfig-Backups vor/nach Change automatisieren

Runbook/SOP für Monitoring: Standard-Checks für den Betrieb

Monitoring ist nur dann wirkungsvoll, wenn es ein Betriebshandbuch gibt: Was prüfen Sie bei Alarm X? Welche Kommandos sind Standard? Welche Eskalation gilt? Diese SOP minimiert Reaktionszeit.

SOP: Basis-Checks bei Alarm „Router/Link down“

show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show logging | last 50

SOP: Basis-Checks bei Alarm „Internet Path down“

show ip sla statistics
ping 198.51.100.1
traceroute 1.1.1.1

SOP: Basis-Checks bei Alarm „CPU hoch“

show processes cpu sorted
show processes memory sorted
show policy-map interface
show crypto ipsec sa
show ip nat statistics

SOP: Basis-Checks bei Alarm „VPN down“

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show logging | include IKEV2|IPSEC|CRYPTO

Minimal-Template: Monitoring-Baseline für Büro/Filiale

Dieses Muster bündelt die typischen Mindestbausteine für Zeit, Syslog und SNMPv3. Werte und IPs müssen an Ihre Umgebung angepasst werden.

service timestamps log datetime msec
ntp server 192.0.2.10 prefer
ntp server 192.0.2.11
logging buffered 64000 informational

logging host 192.0.2.20

logging trap informational

logging source-interface GigabitEthernet0/1
snmp-server group NMS v3 priv

snmp-server user snmpmon NMS v3 auth sha  priv aes 128 

snmp-server location "SITE-01"

snmp-server contact "noc@example.local"

snmp-server enable traps

snmp-server host 192.0.2.30 version 3 priv snmpmon

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.