Cisco Router Operational Metrics: Was ins NOC-Dashboard gehört

Ein NOC-Dashboard für Cisco-Router ist dann wirksam, wenn es nicht „alles zeigt“, sondern die wenigen Operational Metrics, die Incidents früh erkennen, Prioritäten klar machen und Troubleshooting beschleunigen. In der Praxis scheitern Dashboards an zwei Extremen: zu wenig (nur Ping/Uptime) oder zu viel (tausende Metriken ohne Kontext). Ein production-grade Dashboard trennt Device-, Link- und Service-Ebene, setzt klare Alarm- und Drilldown-Logik und standardisiert Evidence, damit L1/L2 schnell handeln kann. Dieser Leitfaden zeigt, welche Cisco-Router-Metriken ins NOC-Dashboard gehören – inklusive sinnvoller Gruppen, typischer Alarme und CLI-Verifikation.

Dashboard-Zielbild: Vom Alarm zur Ursache in 3 Klicks

Das NOC braucht eine klare Journey: (1) Was ist kritisch? (2) Was ist betroffen? (3) Wo ist die Ursache wahrscheinlich? Strukturieren Sie Panels nach Incident-Relevanz.

• Top Panel: aktuelle P1/P2 Events (Site/Device/Service)
• Health Panel: CPU/Memory/Temps/Crashes
• Link Panel: Interface Status, Errors, Utilization, Drops
• Service Panel: Internet/VPN/Tracking, RTT/Loss
• Drilldown: Logs, Routing/VPN Status, letzte Changes

Pflichtpanel 1: Availability-Status (Device, Link, Service getrennt)

Ein Router kann up sein, während der Service down ist (Path-down, VPN down). Trennen Sie daher die Zustände explizit, um Fehlinterpretationen zu vermeiden.

• Device: Reachability/Agent/Up
• WAN Links: ISP1/ISP2 Interface up/down
• Service: IP SLA/Probes zu Hub/Internet (Path-Down Erkennung)
• VPN: Tunnel up und Traffic aktiv (Counter/Flow-basiert)

CLI: Availability Evidence

show ip interface brief
show ip route 0.0.0.0
show ip sla statistics
show track
show crypto ipsec sa

Pflichtpanel 2: WAN-Qualität (RTT, Packet Loss, Jitter)

WAN-Qualität ist oft der wichtigste Early-Warning KPI. Zeigen Sie pro Standort die wichtigsten Targets: ein internes (Hub/DC) und optional ein externes (Public DNS/CDN).

• RTT: Trend und aktuelle Werte (intern/extern getrennt)
• Packet Loss: kurzfristig (5–15 min) und langfristig (24h/7d)
• Jitter: wenn Voice/Video relevant ist
• Alarme: sustained Degradation, nicht Einzelspikes

Pflichtpanel 3: Interface Health (Errors, Drops, Flaps)

Viele Incidents kündigen sich durch Errors und Flaps an. Zeigen Sie pro kritischem Interface eine kompakte Health-Sicht und ein Flap-Ranking.

• Errors: CRC, input errors, output errors
• Drops: output drops, queue drops (Engpass/QoS Indikator)
• Flaps: Interface up/down Ereignisse, Carrier transitions
• Duplex/Speed: Mismatch als klassischer Fehler

CLI: Interface Evidence

show interfaces counters errors
show interfaces | include output drops|queue
show interfaces | include line protocol|Last input|Last output

Pflichtpanel 4: Resource Health (CPU, Memory, Control Plane)

CPU- und Memory-Themen sind häufige Ursachen für Instabilität (Routing Flaps, langsames Management). Zeigen Sie nicht nur Durchschnitt, sondern Peaks und Top-Prozesse.

• CPU: sustained >80% (5–10 min) als Alarmkriterium
• Memory: Low-Memory Events, Fragmentierung, Trend
• Control Plane: CoPP Drops (wenn aktiv) als Attack/Noise Indikator
• Crashes/Reloads: unerwartete Reloads sofort als P1

CLI: Resource Evidence

show processes cpu sorted
show processes memory sorted
show policy-map control-plane
show version

Pflichtpanel 5: Routing Stability (OSPF/BGP Neighbor, Route Churn)

Routing-Instabilität ist ein Blast-Radius-Thema. Für das NOC sind Neighbor-Status und Flap-Frequenz wichtiger als jede einzelne Route.

• OSPF: Neighbor up/down, Anzahl Neighbors, Flaps
• BGP: Session up/down, Prefix Count, max-prefix Events
• Route Churn: häufige Änderungen als Stabilitätswarnung
• Alarm: wiederkehrende Flaps in kurzer Zeit

CLI: Routing Evidence

show ip ospf neighbor
show bgp summary
show ip route summary
show logging | include OSPF|BGP

Pflichtpanel 6: VPN Operations (Session, Rekey/DPD, Traffic)

VPN-Monitoring sollte Tunnel-Status und Traffic-Aktivität trennen. „SA up“ ohne Traffic ist in der Praxis ein häufiger Incident.

• IKE/IPsec Sessions: up/down, Rekey/DPD Events
• Traffic: Bytes/Packets steigen (aktiv)
• Site-to-Site Health: pro Hub/Spoke aggregiert
• Alarm: wiederkehrende Rekeys/Flaps oder Traffic=0 bei erwarteter Nutzung

CLI: VPN Evidence

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

Pflichtpanel 7: Dual-ISP/Failover (Track Events und Umschaltungen)

Bei Dual-ISP ist die wichtigste Metrik die Umschalthäufigkeit. Viele Umschaltungen bedeuten Instabilität. Zusätzlich sollten Track down/up Events sichtbar sein.

• Track Status: up/down, letzte Änderung, Anzahl Events
• Default Route Active Path: ISP1 oder ISP2
• Failover Count: pro Tag/Woche als Stabilitätsindikator
• Alarm: Ping-Pong oder häufiger Failover innerhalb kurzer Zeit

CLI: Failover Evidence

show ip sla statistics
show track
show ip route 0.0.0.0
show logging | include TRACK|IP_SLA

Pflichtpanel 8: Security Signals (Management Access, Denies, Scans)

Das NOC sollte zumindest grundlegende Security-Signale sehen: ungewöhnliche Login-Versuche, Managementzugriffe außerhalb der Bastion, und relevante Denies. Detaillierte Korrelation erfolgt im SOC/SIEM.

• Login/AAA Events: Failed logins, privilege changes
• MGMT Access: Verbindungen außerhalb erlaubter Netze (Policy-Verstöße)
• ACL Denies: selektiv, policy-relevant (keine Logflut)
• Alarm: Spike an Denies oder wiederkehrende Login-Fails

CLI: Security Evidence

show logging | last 100
show running-config | include line vty|access-class|aaa
show access-lists

Pflichtpanel 9: Change Awareness (letzte Changes, Drift, Compliance)

Viele Incidents sind Change-induziert. Wenn das NOC sieht, dass „vor 20 Minuten ein Change war“, beschleunigt das Triage enorm. Ergänzen Sie Change- und Drift-Signale.

• Letzter Change: Change-ID/Window/Owner (aus CMDB/Ticketing)
• Config Drift: Abweichung vom Template (wenn verfügbar)
• Compliance Basics: NTP ok, Syslog ok, SNMPv3 ok (Statusampel)

Alarmdesign: Welche Alarme P1/P2 sein sollten

Ein gutes Dashboard braucht klare Priorisierung. Diese Alarme sind in vielen Umgebungen echte P1/P2-Kandidaten.

• P1: Router down (kritischer Standort), unerwarteter Reload
• P1: WAN beide Links down (Dual-ISP), VPN Hub down
• P2: Tracking down (Primary Path), wiederkehrende Failover-Events
• P2: BGP/OSPF Neighbor flaps wiederholt, Prefix Loss
• P2: Sustained Loss/RTT Degradation über definierte Zeit
• P2: CPU >80% sustained, Control Plane Drops

Drilldown-Standard: Was L1 im Incident als Erstes sammelt

Das Dashboard sollte einen „Copy/Paste“-Pfad liefern: welche CLI-Auszüge werden für das Ticket benötigt. So werden Eskalationen zu L2/L3 schneller.

CLI: NOC Quick Snapshot (Copy/Paste)

show clock
show ip interface brief
show interfaces counters errors
show interfaces | include output drops|queue
show ip route 0.0.0.0
show ip route summary
show ip sla statistics
show track
show crypto ipsec sa
show logging | last 100
show processes cpu sorted

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.