Cisco-Router-Konfiguration: Erfolgs-KPIs (Uptime, Latenz, Failover)

Erfolgs-KPIs für Cisco-Router-Konfigurationen machen „Netz läuft“ messbar. Gerade in Unternehmen zählen nicht nur Up/Down-Events, sondern Servicequalität: Latenz, Paketverlust, Failover-Zeit, VPN-Stabilität und Change-Qualität. Wenn KPIs sauber definiert sind, können Betrieb und Management objektiv bewerten, ob eine Konfiguration stabil ist, ob Provider-SLAs eingehalten werden und ob Redundanz wirklich wirkt. Dieser Leitfaden zeigt praxistaugliche KPIs, Messmethoden und CLI-Checks, die Sie direkt in Monitoring und Abnahme integrieren können.

KPI-Grundregeln: Messbar, reproduzierbar, businessnah

KPIs müssen klar definierte Messpunkte haben (was wird gemessen?), eine Messmethode (wie?) und ein Zeitfenster (wann?). Ohne diese drei Elemente sind Zahlen nicht vergleichbar.

• Messpunkte: WAN-Gateway, Internet-Targets, Zentrale/Hub, kritische Apps
• Zeitfenster: Peak/Off-Peak, 7/30/90 Tage
• Definitionen: was zählt als „Outage“ (Link down vs. Path down)
• Baseline: Werte vor und nach Changes vergleichen

KPI 1: Uptime/Verfügbarkeit (Service, nicht nur Interface)

Verfügbarkeit ist die wichtigste KPI, aber sie muss richtig definiert werden. „Interface up“ ist kein Service. Für Router-Services sollten Sie mindestens WAN-Service (Path) und VPN-Service (Traffic-fähig) unterscheiden.

• WAN-Service-Uptime: Internetpfad erreichbar (nicht nur Link up)
• VPN-Uptime: IKE/IPsec stabil + Traffic möglich
• Gateway-Uptime: HSRP/VRRP stabil (wenn im Scope)
• Messung: Monitoring-Checks, IP SLA, Syslog-Events

Verfügbarkeitsformel (Grundlage)

$\mathrm{Verfügbarkeit}=\frac{\mathrm{Gesamtzeit}–\mathrm{Ausfallzeit}}{\mathrm{Gesamtzeit}}$

CLI-Checks (Service-Sicht)

show ip sla statistics
show track
show logging | include LINEPROTO|LINK-|IPSLAs

KPI 2: Latenz (RTT) zu definierten Zielen

Latenz muss zu festen Zielen gemessen werden, sonst sind Werte nicht vergleichbar. In der Praxis sind drei Targets sinnvoll: Internet (Public), Zentrale/Hub (Private) und eine kritische Cloud-App (wenn erreichbar).

• RTT Internet: z. B. 1.1.1.1 oder Provider-Target
• RTT Hub/Zentrale: definierter Router/Loopback im WAN
• RTT Cloud/SaaS: definierter Endpoint (wenn Monitoring möglich)
• Auswertung: Median/95. Perzentil statt nur Durchschnitt

CLI-Checks RTT (pragmatisch)

ping 1.1.1.1 repeat 20
ping <HUB_IP> repeat 20
traceroute 1.1.1.1

KPI 3: Paketverlust (Loss) und Path-Degradation

Packet Loss ist oft der beste Indikator für Nutzerprobleme (Voice/Video, VDI). Schon geringe Loss-Raten können spürbar sein. Loss sollte über IP SLA oder Monitoring dauerhaft erfasst werden.

• Loss in % pro Messpunkt (Internet/Hub)
• Degradation-Events: Loss > Schwelle für definierte Dauer
• Korrelation: Loss vs. Interface-Errors vs. QoS-Drops

CLI-Checks Loss/Errors

show ip sla statistics
show interfaces counters errors
show interfaces | include output drops|queue

KPI 4: Failover-Zeit (Link-Down und Path-Down getrennt)

Failover ist nur dann erfolgreich, wenn die Umschaltzeit messbar ist und in Tests reproduzierbar erreicht wird. Wichtig: Link-Down (physisch) und Path-Down (Upstream kaputt) sind unterschiedliche Szenarien.

• Failover Link-Down: Zeit von Interface down bis stabiler Default-Pfad
• Failover Path-Down: Zeit von SLA-Fail bis stabiler Default-Pfad
• Failback: Rückübernahme ohne Flapping
• Messung: Syslog-Zeitstempel + Tracking/IP SLA + Route-Status

CLI-Checks Failover

show ip sla statistics
show track
show ip route 0.0.0.0

KPI 5: Routing-Stabilität (Neighbor-Flaps, Convergence)

Routing-Flaps verursachen Micro-Outages, die Nutzer als „langsam“ wahrnehmen. Gute KPIs messen daher Neighbor-Stabilität (Anzahl Flaps) und Convergence-Zeiten bei geplanten Events.

• OSPF/EIGRP/BGP Neighbor-Flaps pro Zeitraum
• Convergence-Zeit bei Failover-Tests (wenn gemessen)
• Route-Table-Health: erwartete Präfixanzahl, keine Leaks

CLI-Checks Routing-Stabilität

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

KPI 6: VPN-Stabilität (SA-Flaps, Rekey-Fehler, Throughput-Indikatoren)

VPN-KPIs müssen zwischen „Tunnel up“ und „Tunnel nutzbar“ unterscheiden. Erfolgreiche KPIs zählen SA-Flaps, prüfen Rekey/DPD und belegen Traffic über Paketzähler.

• IKE/IPsec SA-Flaps pro Zeitraum
• Rekey/DPD Errors (Anzahl/Tag)
• Traffic-Indikator: Paketzähler steigen bei Testtraffic

CLI-Checks VPN-KPIs

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

KPI 7: QoS-Wirksamkeit (Drops in Klassen, Voice/Video Qualität)

Wenn QoS im Scope ist, muss es messbar helfen. Die wichtigsten KPIs sind Drops in Prioritätsklassen (sollten nahe 0 sein) und stabile RTT/Loss während Lasttests.

• QoS-Drops: Drops pro Klasse, besonders Voice/Video
• Queue-Health: Output drops/Queue drops am WAN
• UAT-Qualität: Testcalls/Meetings unter Last (Pass/Fail)

CLI-Checks QoS

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

KPI 8: Ressourcen-Headroom (CPU/Memory als Frühwarnsignal)

Ein Router kann „funktionieren“ und dennoch kurz vor der Überlast stehen. Deshalb ist Headroom eine KPI: CPU-/Memory-Spitzen und Dauerlast in Peakzeiten sind Frühwarnindikatoren.

• CPU: Spitzen und Dauerlast getrennt betrachten
• Memory: Trend über Zeit (Leaks/Knappheit)
• Korrelation: CPU-Spitzen vs. VPN/NAT/QoS Events

CLI-Checks Ressourcen

show processes cpu sorted
show processes cpu history
show processes memory sorted

KPI 9: Change-Qualität (Rollback-Rate, Incident nach Change)

Technische KPIs reichen nicht. Ein reifes Netzwerkteam misst auch Change-Qualität: wie oft führen Changes zu Incidents oder Rollbacks? Diese KPI ist direkt beeinflussbar durch Standards und Tests.

• Rollback-Rate: Rollbacks/Changes pro Zeitraum
• Change-Failure-Rate: Incidents innerhalb 24–72h nach Change
• Abnahmequote: Anteil der Changes mit Pre-/Post-Checks und UAT

KPI 10: MTTR (Mean Time to Restore) und Diagnosezeit

MTTR ist eine Business-KPI: Wie schnell wird der Service wiederhergestellt? Ergänzend ist Diagnosezeit wichtig, weil gute Standards (Runbooks, Monitoring) genau hier Kosten sparen.

• MTTR pro Priorität (P1–P4)
• Time-to-Triage: Zeit bis Ursache grob eingegrenzt ist
• Time-to-Workaround: Zeit bis Service teilweise wieder läuft

Mess-Setup: Wie Sie KPIs technisch „sauber“ erfassen

Damit KPIs belastbar sind, brauchen Sie Mindest-Monitoring: NTP, Syslog, ggf. SNMP/Telemetry und IP SLA. Ohne diese Signale sind KPIs nur Schätzungen.

• NTP synchronized + Log-Timestamps
• Syslog zentral (Interface/Routing/VPN/AAA Events)
• SNMP/Telemetry: Interfaces, Errors/Drops, CPU/Memory
• IP SLA: RTT/Loss und Path-Down Events

CLI-Checks für KPI-Readiness

show ntp status
show logging | last 50
show ip sla statistics
show interfaces counters errors
show processes cpu sorted

KPI-Runbook: Kompakter „KPI Snapshot“ (Copy/Paste)

Dieser Snapshot liefert in wenigen Minuten die wichtigsten KPI-Signale und eignet sich als Abnahmeanhang sowie als regelmäßiger Gesundheitscheck.

show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip sla statistics
show track
show crypto ikev2 sa
show crypto ipsec sa
show policy-map interface
show processes cpu sorted
show processes memory sorted
show logging | last 100
ping 1.1.1.1 repeat 20
traceroute 1.1.1.1

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.