SNMP-Monitoring ist im Switch-Betrieb unverzichtbar: Du bekommst Interface-Status, Traffic-Raten, Errors/Drops, CPU/Memory sowie Hardwarezustände (PoE, PSU, Temperatur) zentral ins Monitoring (z. B. PRTG oder Zabbix). Damit SNMP im Campus zuverlässig und sicher funktioniert, brauchst du eine saubere Management-Plane (MGMT-VLAN, ACLs), ein konsistentes SNMP-Design (SNMPv3 statt v2c), sinnvolle Polling-Intervalle und klare „Baseline“-Sensoren. Dieser Leitfaden zeigt Best Practices für Cisco Switch Monitoring mit SNMP – inklusive praxistauglicher Konfiguration und Verifikation.
Monitoring-Ziele: Was du auf Switches wirklich überwachen solltest
Viele Monitoring-Setups sind entweder zu dünn (nur Ping) oder zu laut (zu viele Sensoren ohne Priorität). Für den Betrieb sind wenige, aber aussagekräftige Metriken am wichtigsten.
- Interface Status (up/down), Speed/Duplex
- Traffic (in/out), Utilization auf Uplinks/Port-Channels
- Errors: CRC/FCS, input/output errors, discards/drops
- CPU und Memory (Trends, nicht nur Momentaufnahme)
- STP/EtherChannel Hinweise indirekt: Flaps, MAC-Flaps (über Syslog ergänzen)
- Hardware: PSU, Temperatur, Lüfter, PoE Budget und Denied/Fault
SNMPv3 als Standard: Sicher ohne Klartext-Community
Für produktive Netze ist SNMPv3 (AuthPriv) Best Practice: Authentifizierung und Verschlüsselung statt Klartext-Communities. Zusätzlich begrenzt du Zugriffe per ACL auf die Monitoring-Server.
SNMPv3 Baseline (Read-only, AuthPriv)
enable
configure terminal
snmp-server view MONITORING iso included
snmp-server group NMS-GRP v3 priv read MONITORING
snmp-server user nmsuser NMS-GRP v3 auth sha priv aes 128
ip access-list standard ACL-SNMP-NMS
permit 10.1.99.70
permit 10.1.99.71
deny any
exit
snmp-server group NMS-GRP v3 priv read MONITORING access ACL-SNMP-NMS
snmp-server location DC1-Rack12-U18
snmp-server contact noc@corp.local
end
Verifikation
show snmp user
show snmp group
show running-config | include snmp-server
show access-lists ACL-SNMP-NMS
Management-Netz sauber halten: MGMT-VLAN, Source-Interface, ACLs
SNMP ist nur so stabil wie der Management-Pfad. Nutze ein Management-VLAN/VRF, setze Source-Interfaces und erlaube SNMP nur aus dem Monitoring-Netz. So reduzierst du Angriffsfläche und Fehlerquellen.
Management-SVI und Default Gateway (Beispiel L2-Switch)
configure terminal
vlan 99
name MGMT
exit
interface vlan 99
ip address 10.1.99.10 255.255.255.0
no shutdown
exit
ip default-gateway 10.1.99.1
end
VTY-ACL ergänzend (SSH nur aus Admin-Netz)
configure terminal
ip access-list standard ACL-MGMT-SSH
permit 10.1.99.0 0.0.0.255
deny any
exit
line vty 0 15
transport input ssh
access-class ACL-MGMT-SSH in
end
PRTG/Zabbix Praxis: Polling-Strategie gegen CPU-Last und Timeouts
Zu aggressives Polling kann Switch-CPU belasten oder SNMP-Timeouts erzeugen. Das gilt besonders für viele Interfaces, sehr kurze Intervalle und große Walks (ganze MIB-Bäume). Ziel ist: wenige essentielle Sensoren pro Switch, detailliert nur dort, wo es nötig ist.
- Standard-Intervalle: nicht zu kurz, besonders bei großen Switches
- Uplinks/Port-Channels detailliert überwachen, Edge-Ports eher statusbasiert
- Errors/Drops trendbasiert (Anstieg wichtiger als absoluter Wert)
- Walks vermeiden oder begrenzen (nur benötigte OIDs)
SNMP-Last-Indikatoren prüfen
show processes cpu sorted
show logging | include SNMP
Best Practice Sensoren: „Minimal sinnvoll“ vs. „Deep Dive“
Baue dein Monitoring in Schichten auf. So bleibt es übersichtlich und performant, und du kannst bei Bedarf gezielt vertiefen.
- Minimal: Ping/Reachability, Syslog-Events, Uplink-Status
- Standard: Uplink-Traffic, Errors/Drops, CPU/Memory, Temperatur/PSU
- Deep Dive: Top-Talkers/Flow (nicht SNMP), detaillierte Edge-Errors, PoE pro Port
SNMP Traps/Informs: Events statt nur Polling
Polling erkennt Ausfälle erst beim nächsten Intervall. Traps/Informs liefern Ereignisse sofort: Link Down, PoE Fault, Auth-Failures. In PRTG/Zabbix kannst du Traps als Ergänzung nutzen, ersetzt aber nicht die wichtigsten Polling-Werte.
Traps aktivieren und Empfänger setzen (SNMPv3)
configure terminal
snmp-server enable traps
snmp-server host 10.1.99.70 version 3 priv nmsuser
snmp-server host 10.1.99.71 version 3 priv nmsuser
snmp-server trap-source vlan 99
end
Verifikation
show running-config | include snmp-server host|enable traps|trap-source
Interface-Errors als Frühwarnsystem: CRC, Drops und Flaps
Viele Incidents kündigen sich durch steigende CRCs oder Drops an, bevor ein Port komplett ausfällt. Genau diese Trends solltest du in PRTG/Zabbix priorisieren, vor allem auf Uplinks und kritischen Ports.
- CRC/FCS: Kabel/Transceiver/Physik
- Output Drops: Congestion/Microbursts/QoS
- Link Flaps: Wackelkontakt, PoE-Reboots, Gegenstelle
CLI-Referenz für Verifikation
show interfaces counters errors
show interfaces gigabitEthernet 1/0/48 | include rate|drops|discard|CRC
show logging | include LINK|LINEPROTO|UPDOWN
PoE Monitoring: Budget, Denied und Faults sichtbar machen
PoE-Probleme sind oft budget- oder verkabelungsbedingt. Überwache PoE-Gesamtbudget und Fault/Denied Events, besonders in Access-Switches mit vielen APs.
PoE Status prüfen
show power inline
show logging | include ILPOWER|PoE|POWER|DENIED|FAULT
Typische Fehler und wie du sie vermeidest
Viele SNMP-Monitoring-Probleme sind Konfig- oder Betriebsfehler: falsche Source-IP, ACL blockt, SNMPv3 Parameter falsch, oder Poller ist zu aggressiv.
- SNMPv3 Auth/Priv mismatch zwischen NMS und Switch
- ACL lässt Poller-IP nicht zu
- Management-Routing/Default-Gateway fehlt (L2-Switch)
- Zu viele Sensoren/zu kurze Intervalle → CPU hoch, Timeouts
- v2c Communities noch aktiv (unnötige Angriffsfläche)
Troubleshooting-Kommandos (Copy/Paste)
show ip interface brief
show running-config | include snmp-server
show snmp user
show snmp group
show access-lists
show processes cpu sorted
show logging | include SNMP|AUTH|FAIL
Best Practices: Stabil, sicher und skalierbar monitoren
Ein gutes SNMP-Monitoring ist konsistent: SNMPv3 überall, nur definierte Poller-IPs, klare Sensor-Standards und ergänzende Syslog-Events. So bekommst du hohe Signalqualität bei niedriger Last.
- SNMPv3 AuthPriv als Standard, v2c entfernen
- ACLs auf Poller-IPs/Subnetze, Source-Interface im MGMT
- Sensoren priorisieren (Uplinks/PoE/CPU/Errors) statt „alles überall“
- Polling-Intervalle realistisch wählen, Walks begrenzen
- Traps für schnelle Events ergänzen, Syslog für Kontext nutzen
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.
