Monitoring-KPIs für Cisco-Router: Uptime, Latenz, Packet Loss und Availability Report

Monitoring-KPIs für Cisco-Router sind dann wertvoll, wenn sie nicht nur „Gerät lebt“ anzeigen, sondern Service-Availability messbar machen: Uptime (Device/Interface), Latenz (RTT), Packet Loss, Jitter (bei Echtzeit) und daraus abgeleitete Availability Reports pro Standort, Link und Service (Internet, VPN, WAN). Viele Umgebungen scheitern an unklaren Definitionen: Ist ein Router „up“, wenn die Management-IP antwortet, aber der ISP-Pfad tot ist? Ein production-grade KPI-Set trennt deshalb Device-, Link- und Service-KPIs, nutzt eindeutige Messpunkte (IP SLA/Probe Targets) und liefert reports, die Business und NOC gleichermaßen verstehen. Dieser Leitfaden zeigt praxistaugliche KPI-Definitionen, Messmethoden und ein Availability-Reporting-Modell für Cisco-Router.

KPI-Grundmodell: Device, Link und Service getrennt messen

Ein Router kann „up“ sein, während ein Service down ist (Path-down, VPN down). Trennen Sie daher die KPI-Ebenen, damit Reports nicht täuschen.

• Device KPIs: Systemzustand (Uptime, CPU/Memory, Temps)
• Link KPIs: Interface/Provider-Link (Carrier, Errors, Utilization)
• Service KPIs: End-to-End (Internet, VPN, Hub-Erreichbarkeit)

Availability als Verhältnis (Template)

$\mathrm{Availability}=\frac{\mathrm{Total}\mathrm{Time}–\mathrm{Downtime}}{\mathrm{Total}\mathrm{Time}}$

Uptime: Was „Uptime“ im Enterprise wirklich bedeutet

Uptime ist mehrdeutig. Definieren Sie, ob Sie Device-Uptime (System läuft), Management-Uptime (MGMT-IP antwortet), Link-Uptime (WAN-Interface up) oder Service-Uptime (Internet/VPN verfügbar) meinen.

• Device-Uptime: Router läuft (aber Service kann trotzdem down sein)
• Interface-Uptime: WAN-Port up (Path-down nicht abgedeckt)
• Service-Uptime: Probe zur definierten Zieladresse erfolgreich
• Reporting: immer „welche Uptime“ im KPI-Namen kennzeichnen

CLI: Device/Interface Uptime Evidence

show version
show ip interface brief
show interfaces | include line protocol|Last input|Last output

Latenz (RTT): Messpunkt, Zieladressen und Interpretation

Latenz ist nur dann aussagekräftig, wenn Messpunkt und Zieladressen stabil sind. Für WAN-Reports benötigen Sie mindestens ein internes Ziel (Hub/Resolver) und optional ein externes Ziel (Public DNS/CDN).

• Internes RTT: Filiale → Hub/Datacenter (WAN-Qualität für interne Services)
• Externes RTT: Filiale → Public DNS/CDN (Internet-Qualität)
• Messfrequenz: häufig genug für Trends, nicht so hoch, dass Noise entsteht
• Schwellenwerte: pro Standorttyp (Metro vs. Land), nicht global blind

CLI: IP SLA als RTT-Messung (Beispiel)

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

CLI: RTT Evidence

show ip sla statistics
show track

Packet Loss: Der KPI, der Availability oft besser erklärt als RTT

Packet Loss korreliert stark mit Nutzerwahrnehmung („VPN instabil“, „SaaS langsam“). Besonders bei Retail/OT/Healthcare ist Loss häufig der erste echte Indikator für Degradation.

• Loss messen: über IP SLA (ICMP) oder dedizierte NPM-Tools
• Interpretation: 0,5–1% kann schon Echtzeit/SSL spürbar beeinträchtigen
• Reporting: Loss pro Link und pro Service (Hub/Internet) trennen

Jitter und Echtzeit-KPIs: Wenn Voice/Video im Scope ist

Wenn VoIP/Video relevant ist, reicht RTT/Loss allein nicht. Jitter und Queue Drops am WAN sind entscheidend, ebenso QoS-Counter.

• Jitter: Schwankung der Verzögerung (Echtzeit empfindlich)
• Queue Drops: Hinweis auf Engpass/Shaping/QoS-Fehler
• QoS Counter: Beleg, dass Priorisierung wirkt

CLI: QoS/Queue Evidence

show policy-map interface
show interfaces | include output drops|queue

Availability Report: Was ein „business-tauglicher“ Report enthalten muss

Ein guter Availability Report zeigt nicht nur Prozentwerte, sondern erklärt Ursachen: war es Device, Link, Provider, oder Service? Außerdem muss er Failover berücksichtigen.

• Zeitraum: Woche/Monat, mit Wartungsfenstern separat
• Dimensionen: pro Standort, pro Link (ISP1/ISP2), pro Service (Internet/VPN)
• Downtime-Klassifikation: Planned vs. Unplanned
• Root Cause Kategorien: ISP, Power, Config Change, Hardware, Unknown

Dual-ISP KPI: Failover-Verfügbarkeit und Umschaltzeiten

Bei Dual-ISP ist die wichtigste KPI nicht nur „beide Links up“, sondern ob Failover zuverlässig funktioniert und wie lange es dauert. Messen Sie Track-Events und Failover-Zeit.

• Track-Uptime: Anteil Zeit, in dem Primary Path als erreichbar gilt
• Failover-Count: Anzahl Umschaltungen pro Zeitraum (Stabilitätsindikator)
• Failover-Zeit: Detection + Convergence + Service-Recovery

CLI: Dual-ISP Evidence

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

VPN KPI: Tunnel-Uptime vs. Traffic-Uptime

VPN-KPIs müssen zwischen „Tunnel steht“ und „Traffic läuft“ unterscheiden. Viele Incidents zeigen „SA up“, aber keine Pakete. Nutzen Sie daher Counter-basierte Nachweise.

• Tunnel-Uptime: IKE/IPsec Session vorhanden
• Traffic-Uptime: Bytes/Packets steigen bei Tests/Normalbetrieb
• Stabilität: Rekey/DPD Flaps pro Zeitraum

CLI: VPN Evidence

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

Health KPIs: CPU, Memory, Errors und Drops als Frühwarnsystem

Viele Outages kündigen sich an: steigende Errors, Queue Drops oder CPU-Spitzen. Health-KPIs helfen, Probleme zu vermeiden, bevor sie Availability beeinflussen.

• CPU: dauerhaft hoch oder häufige Peaks (Control Plane Risiko)
• Memory: Leaks, Fragmentierung, Low-Memory Events
• Interface Errors: CRC, input errors, flaps
• Output Drops: Engpass, fehlendes Shaping/QoS

CLI: Health Evidence

show processes cpu sorted
show processes memory sorted
show interfaces counters errors
show interfaces | include output drops|queue

Thresholds: Praxiswerte und wie Sie Fehlalarme vermeiden

Schwellenwerte sind kontextabhängig. Definieren Sie Werte pro Standortklasse (HQ/Branch, Region, Linktyp) und nutzen Sie „Sustained“ Kriterien statt Einzelspikes.

• RTT: Schwelle als „Baseline + Delta“ statt fixer Wert
• Loss: Alarm erst bei X% über Y Minuten
• CPU: Alarm bei >80% über 5–10 Minuten, nicht bei 10 Sekunden Peak
• Flaps: Alarm bei wiederkehrenden Track/Interface Events pro Stunde

Evidence Collection für Reports: Welche Routerdaten Sie regelmäßig ziehen

Auch wenn das NMS die Reports erzeugt, sind Router-eigene Evidence wichtig für RCA und Audit. Definieren Sie ein Standardpaket für periodische Snapshots.

• Wöchentlich/Monatlich: Interface Errors/Drops, CPU/Memory Trends
• Bei Degradation: IP SLA Stats, Track Events, Logs
• Bei VPN-Problemen: IPsec Counters und Session Details

CLI: KPI Snapshot Pack (Copy/Paste)

show clock
show ip interface brief
show interfaces counters errors
show interfaces | include output drops|queue
show ip sla statistics
show track
show crypto ipsec sa
show logging | last 50
show processes cpu sorted
show processes memory 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.