Cisco-Router-Konfiguration: Performance-Checkliste nach dem Go-Live

Nach dem Go-Live ist „läuft“ kein ausreichender Zustand. Die Performance-Checkliste stellt sicher, dass der Cisco-Router nicht nur funktional arbeitet, sondern unter realer Last stabil bleibt: keine überhöhte CPU, keine Interface-Errors, keine Drops durch falsches QoS/Shaping, keine Path-Degradation (Loss/RTT) und keine stillen Probleme bei NAT/VPN. Diese Checks sind bewusst praxisorientiert: Sie liefern objektive Messpunkte, die Sie direkt nach dem Go-Live (und in den ersten Betriebstagen) wiederholen können, um Performance-Drift früh zu erkennen.

Grundregeln für Post-Go-Live Performance-Checks

Führen Sie Checks immer zu definierten Zeitpunkten aus: direkt nach Cutover, nach 1–2 Stunden, und nochmals im ersten Peak-Fenster (z. B. Vormittag). Vergleichbarkeit ist wichtiger als „einmal schauen“.

• Baseline vor Go-Live sichern (Pre-Checks), danach vergleichen (Post-Checks)
• Checks in Lastfenstern wiederholen (Peak vs. Off-Peak)
• Messpunkte definieren: Internet, Zentrale, Cloud, kritische Apps
• Nachweise speichern (CLI-Outputs mit Zeitstempel/Ticket-ID)

Checkliste 1: CPU-Last und Prozess-Spitzen

Überhöhte CPU ist ein Hauptindikator für Performanceprobleme (z. B. zu viele Interrupts, Crypto/NAT-Last, Routing-Stürme). Prüfen Sie nicht nur den Gesamtwert, sondern die Top-Prozesse.

• CPU im Normalbetrieb stabil (keine Dauerlast)
• Spitzen korrelieren mit Events (VPN-Rekey, Routing-Update, Interface-Flap)
• Top-Prozesse plausibel (kein „mystery hog“)

CLI-Checks CPU

show processes cpu sorted
show processes cpu history
show logging | last 50

Checkliste 2: Memory und Ressourcen (Leaks/Knappheit vermeiden)

Memoryprobleme äußern sich oft später als CPU-Probleme. Prüfen Sie deshalb früh, ob ungewöhnlich hoher Verbrauch oder Fragmentierung sichtbar ist – insbesondere nach VPN/NAT-Änderungen.

• Memory ausreichend frei, keine „kritische“ Auslastung
• Keine auffälligen Sprünge nach Go-Live
• Speicherintensive Prozesse identifizieren

CLI-Checks Memory

show processes memory sorted
show memory statistics

Checkliste 3: Interface-Health (Errors, Drops, Duplex/CRC)

Viele Performanceprobleme sind Layer-1/2: CRC-Errors, Input Errors, Output Drops, falsche Speed/Duplex-Aushandlung. Diese Werte sind oft der schnellste Hinweis auf die eigentliche Ursache.

• Keine steigenden CRC/Input Errors auf WAN/LAN-Uplinks
• Keine ungewöhnlichen Output Drops/Queue Drops
• Interface-Flaps ausgeschlossen (Stabilität)

CLI-Checks Interfaces

show ip interface brief
show interfaces counters errors
show interfaces description

Checkliste 4: Path-Qualität (RTT/Loss/Jitter pragmatisch prüfen)

Selbst wenn „Internet geht“, kann die Pfadqualität schlecht sein (Transit-Probleme, Routing-Umwege, Congestion). Definieren Sie daher 2–3 feste Ziele und vergleichen Sie RTT/Loss vor/nach Go-Live.

• RTT im erwarteten Bereich (vergleichbar mit Pre-Checks)
• Loss nahe 0% in stabilen Umgebungen
• Traceroute-Pfad plausibel (keine unerwarteten Umwege)

CLI-Checks Path

ping 8.8.8.8 repeat 20
ping 1.1.1.1 repeat 20
traceroute 1.1.1.1

Checkliste 5: IP SLA (wenn aktiv) – Messwerte und Flapping

Wenn IP SLA im Design genutzt wird (Failover/Monitoring), prüfen Sie nach Go-Live die Statistiken. Flapping oder häufige Timeouts sind ein Frühwarnsignal für Pfadinstabilität.

• IP SLA liefert konsistente Werte
• Keine häufigen Timeouts/RTT-Spikes
• Tracking-Status stabil (falls gekoppelt)

CLI-Checks IP SLA/Tracking

show ip sla statistics
show track

Checkliste 6: NAT-Performance (Translations, Ressourcen, unerwartete Matches)

NAT kann Performance belasten, wenn sehr viele Sessions entstehen oder wenn Regeln zu breit matchen. Prüfen Sie, ob die Anzahl Translations plausibel ist und ob keine falschen Netze genattet werden.

• Translations steigen bei Traffic und bleiben stabil
• Keine unerwarteten Quellnetze in NAT-Translations
• Keine auffälligen NAT-Fehler im Log

CLI-Checks NAT

show ip nat statistics
show ip nat translations

Checkliste 7: VPN-Performance (Crypto, Paketzähler, Rekey-Stabilität)

VPNs sind oft Performance-kritisch (Crypto-Last, MTU/MSS). Prüfen Sie SA-Status, Paketzähler und Logs. „Tunnel up“ reicht nicht – Zähler müssen steigen und Rekey darf nicht flappen.

• IKEv2/IPsec SAs aktiv, keine häufigen Rekey-Events
• Paketzähler steigen unter Last
• Keine wiederkehrenden Crypto-Fehler im Log

CLI-Checks VPN

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

Checkliste 8: Routing-Stabilität (Neighbor, Flaps, Table-Size)

Routing-Instabilität kann sich als „langsam“ äußern (Umwege, Micro-Outages). Prüfen Sie Nachbarschaften, Routenanzahl und Logs auf Flaps, besonders bei OSPF/BGP.

• Neighbors stabil (keine häufigen State-Wechsel)
• Routenanzahl plausibel (keine unerwarteten Leaks)
• Logs frei von wiederkehrenden Neighbor-Down/Up

CLI-Checks Routing

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

Checkliste 9: QoS-Verifikation (wenn QoS aktiv ist)

QoS kann Performance verbessern oder verschlechtern – je nachdem, ob Shaping und Klassen korrekt sind. Prüfen Sie, ob Klassen Traffic sehen und ob Drops in kritischen Klassen auftreten.

• WAN-Shaping aktiv (Queueing im Router, nicht beim Provider)
• Voice/Video-Klassen sehen Traffic
• Keine auffälligen Drops in Prioritätsklassen

CLI-Checks QoS

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

Checkliste 10: Logs als Performance-Frühwarnsystem

Viele Performance-Probleme werden zuerst in Logs sichtbar (Interface flaps, routing changes, crypto errors). Nach Go-Live sollten Sie Logs gezielt auf wiederkehrende Muster prüfen.

• Keine wiederkehrenden Interface up/down Meldungen
• Keine wiederkehrenden Neighbor-Resets
• Keine Crypto/DPD/Rekey-Schleifen
• Keine CPU-Hog-Warnungen

CLI-Checks Logs

show logging | last 100
show logging | include LINEPROTO|LINK-|OSPF|BGP|CRYPTO|CPUHOG

Post-Go-Live Runbook: Kompakte Performance-Checkliste (Copy/Paste)

Dieses Runbook bündelt die wichtigsten Performance-Signale. Es eignet sich für die ersten Stunden nach Go-Live und als Wiederholung im Peak-Fenster.

show ip interface brief
show interfaces counters errors
show processes cpu sorted
show processes cpu history
show processes memory sorted
show ip route 0.0.0.0
show ip route summary
show ip nat statistics
show ip nat translations
show crypto ikev2 sa
show crypto ipsec sa
show ip sla statistics
show track
show policy-map interface
show logging | last 100
ping 8.8.8.8 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.