Sauberes Logging ist auf Cisco Switches ein entscheidender Baustein für Troubleshooting, Security und Betrieb: Link-Flaps, STP-Events, Authentifizierungsfehler oder Port-Security-Verstöße lassen sich nur zuverlässig analysieren, wenn Logs zentral gesammelt und sinnvoll gefiltert werden. Syslog ermöglicht genau das – Ereignisse werden vom Switch an einen zentralen Syslog-Server gesendet, dort gespeichert und auswertbar gemacht. Dieses Tutorial zeigt, wie du Syslog auf Cisco IOS/IOS XE einrichtest und praxisgerecht nutzt.
Grundlagen: Was ist Syslog und warum zentral loggen?
Syslog ist ein Standardprotokoll zur Übertragung von Logmeldungen. Der Switch erzeugt Meldungen mit Severity-Level (0–7) und sendet sie an einen Syslog-Server. Zentralisiertes Logging verhindert, dass wichtige Informationen nach einem Reload oder Buffer-Overflow verloren gehen.
- Nachvollziehbarkeit von Events (Ursache/Wirkung)
- Schnellere Fehlersuche durch zentrale Suche und Korrelation
- Security: Login-Events, Policy-Verstöße, Audit-Trails
Severity-Level (0–7) in der Praxis
Im Alltag ist entscheidend, welche Schweregrade du speicherst und weiterleitest. Zu viele Logs überfluten den Server, zu wenige Logs machen Ursachenanalyse unmöglich.
- 0 Emergencies: System unbenutzbar
- 1 Alerts: sofortiges Handeln erforderlich
- 2 Critical: kritische Zustände
- 3 Errors: Fehlerbedingungen
- 4 Warnings: Warnungen (häufig sinnvoll für Betrieb)
- 5 Notifications: wichtige Ereignisse (oft guter Standard für Syslog)
- 6 Informational: detailreiche Infos (sehr viele Meldungen)
- 7 Debugging: sehr umfangreich (nur temporär)
Voraussetzungen: Zeit (NTP), Management-IP und Erreichbarkeit
Damit Logs korrekt zeitgestempelt sind, sollte NTP aktiv sein. Zusätzlich muss der Switch den Syslog-Server erreichen können (Routing/ACLs). Logs ohne korrekte Zeit sind in Incident-Analysen oft kaum nutzbar.
show clock detail
show ntp status
show ip interface brief
ping 192.168.99.70
Empfohlene Zeitzone (Deutschland) und NTP kurz prüfen
show running-config | include clock timezone|clock summer-time|ntp server|ntp source
Lokales Logging konfigurieren: Buffer, Console und Monitor
Bevor du Syslog an einen Server sendest, solltest du lokales Logging sinnvoll einstellen: Console-Logging ist oft störend, Buffer-Logging hingegen ist für schnelle Checks hilfreich.
Logging in den Buffer schreiben
Der Buffer speichert Meldungen lokal im RAM. Größe und Severity-Level solltest du passend wählen.
configure terminal
logging buffered 16384 notifications
end
Console-Logging reduzieren
Auf Konsolen kann Logging die Bedienung stören. In vielen Umgebungen wird es deaktiviert oder auf höhere Severity-Level begrenzt.
configure terminal
no logging console
end
Logging für Remote-Terminals (Monitor)
Wenn du per SSH arbeitest, kannst du Logging auf die Session anzeigen lassen. Das ist für Troubleshooting hilfreich, aber im Alltag oft deaktiviert.
terminal monitor
terminal no monitor
Syslog einrichten: Server, Severity und Source-Interface
Für sauberes Syslog definierst du mindestens einen Syslog-Server, ein Source-Interface (Management-SVI) und die Severity, die gesendet werden soll.
Syslog-Server konfigurieren (einfacher Start)
configure terminal
logging host 192.168.99.70
logging trap notifications
end
Source-Interface setzen (Best Practice)
Mit einem definierten Source-Interface kommen Syslog-Pakete aus dem Management-VLAN. Das erleichtert Firewall-Regeln und verhindert „wechselnde“ Source-IPs.
configure terminal
logging source-interface vlan 99
end
Mehrere Syslog-Server für Redundanz
Für Betriebssicherheit werden häufig zwei Server genutzt. So gehen Logs nicht verloren, wenn ein Server ausfällt.
configure terminal
logging host 192.168.99.70
logging host 192.168.99.71
logging trap notifications
end
Syslog sinnvoll nutzen: Facility, Origin-ID und einheitliche Identität
Damit Logs in SIEM/Syslog-Tools sauber sortiert werden, ist eine eindeutige Geräteidentität wichtig. Zusätzlich kann die Facility für Filterung/Weiterleitung genutzt werden.
Hostname als Geräteidentität und Origin-ID aktivieren
Der Hostname sollte eindeutig sein. Origin-ID hilft, Logs eindeutig dem Gerät zuzuordnen.
show running-config | include hostname
configure terminal
logging origin-id hostname
end
Facility setzen (optional)
Je nach Syslog-Server können Facilities zur Regelbildung genutzt werden. Nutze eine konsistente Facility für Netzwerkgeräte.
configure terminal
logging facility local7
end
Praxisbeispiel: „Guter Standard“ für Access-Switches
Dieses Beispiel liefert praxistaugliches Logging ohne Log-Flut: lokale Buffer-Logs, Syslog auf Notifications, definierte Source-IP und keine Console-Spam.
configure terminal
no logging console
logging buffered 16384 notifications
logging source-interface vlan 99
logging facility local7
logging origin-id hostname
logging host 192.168.99.70
logging host 192.168.99.71
logging trap notifications
end
Verifikation: Prüfen, ob Syslog wirklich sendet
Nach der Konfiguration prüfst du, ob Logging aktiv ist, welche Hosts eingetragen sind und ob Events im Buffer erscheinen. Zusätzlich erzeugst du bewusst ein Test-Event (z. B. Interface shutdown/no shutdown).
show logging
show running-config | include logging
show logging | include 192.168.99.70|192.168.99.71
Test-Event erzeugen (kontrolliert)
configure terminal
interface gigabitEthernet 1/0/1
shutdown
no shutdown
end
Typische Log-Quellen: Was du im Alltag filtern solltest
Für Betrieb und Security sind bestimmte Meldungsarten besonders wertvoll. Baue Filter/Alerts im Syslog-Server gezielt auf diese Ereignisse.
- Link-Flaps: Interface up/down, Line protocol changes
- STP: Topology Changes, BPDU Guard, Loop-Incidents
- Security: Login success/failure, ACL denies
- Port-Security: MAC violations, err-disabled
- PoE: Power denied, overload, class changes
show logging | include LINK|LINEPROTO|SPANNING|BPDU|SEC|AUTH|PORT_SECURITY|ERRDISABLE|POWER
Security-Best-Practices: Logging schützen und gezielt begrenzen
Logs enthalten sicherheitsrelevante Informationen. Begrenze daher, wer das Management-VLAN erreichen darf, und sorge für korrekte Zeitstempel und stabile Identitäten.
- Management-VLAN verwenden und Zugriff per ACL begrenzen
- NTP aktivieren, damit Zeitstempel korrekt sind
- Syslog-Source-Interface fixieren (stabile Source-IP)
- Severity sinnvoll wählen (oft
notificationsoderwarnings) - Debug-Logs nur temporär aktivieren und danach entfernen
Debugging sicher nutzen (nur temporär)
Debugging erzeugt sehr viele Logs und kann Ressourcen belasten. Aktiviere Debug nur zielgerichtet und beende es sofort nach dem Test.
debug ?
undebug all
show logging
Konfiguration speichern und dokumentieren
Speichere die Konfiguration nach erfolgreicher Verifikation und dokumentiere Syslog-Server, Facility, Severity und Source-Interface. Das erleichtert Audits und schnelle Wiederherstellung.
copy running-config startup-config
show running-config | include logging
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.
