Cisco-Router-Cutover-Checkliste: Pre-Change, Change, Post-Change (Template)

Ein Cisco-Router-Cutover ist dann sicher und planbar, wenn er als standardisiertes Verfahren (SOP) durchgeführt wird: Pre-Change Baseline und Go/No-Go, eine klare Change-Schrittfolge mit Zeitboxen, sowie Post-Change Validierung inklusive UAT und Evidence. Viele Outages entstehen, weil Pre-Checks fehlen (kein Vergleich), Rollback zu spät entschieden wird oder Post-Checks nicht systematisch durchgeführt werden. Dieses Template liefert eine praxistaugliche Cutover-Checkliste für Cisco-Router-Projekte, die Sie direkt in Change-Management, SoW oder Runbooks übernehmen können.

Pre-Change: Vorbereitung, Freigaben und Go/No-Go

Pre-Change entscheidet über Erfolg oder Rollback. Ziel ist, alle Abhängigkeiten zu prüfen, Baselines zu sichern und die Entscheidung „Go“ objektiv zu treffen.

• Change-ID, Scope (Geräte/Standorte), Zeitfenster und Rollen bestätigt
• Freeze aktiv: keine parallelen Netzwerk-/Firewall-/DNS-Changes
• Providerdaten (Circuit-ID), Zugänge, Bastion/OOB getestet
• Rollback-Plan: Trigger, Schrittfolge, Zeitreserve im Window
• Monitoring/NOC: Alarm-Noise reduziert, Ansprechpartner erreichbar

Pre-Change: Baseline sichern (Backups)

• Running/Startup Config sichern (PRE)
• IOS/IOS-XE Version, Boot-Variable, Lizenzen dokumentieren
• Konfig-Export in zentrale Ablage/Repo (Change-ID Pflicht)

CLI: Pre-Change Evidence Pack (Copy/Paste)

terminal length 0
show version
show boot
show license summary
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 ospf neighbor
show bgp summary
show crypto ikev2 sa
show crypto ipsec sa
show ip nat statistics
show ip sla statistics
show track
show policy-map interface
show ntp status
show logging | last 100
show processes cpu sorted
show processes memory sorted
show running-config

Pre-Change: Go/No-Go Kriterien (Template)

• Go: Baseline vollständig, keine kritischen Alarme/Flaps, OOB/Access bestätigt
• Go: Rollback-Reserve vorhanden, Stakeholder erreichbar, UAT-Verantwortliche bereit
• No-Go: bestehende Instabilität (Flaps/CPU), unklare Providerlage, fehlende Zugänge

Change: Schrittfolge, Zeitboxen und Kontrollpunkte

Im Change zählt Struktur. Arbeiten Sie in klaren Blöcken und definieren Sie Kontrollpunkte: „Stabil? Weiter.“ oder „Rollback Trigger erreicht? Zurück.“. Dokumentieren Sie jede Abweichung.

• Kommunikationskanal aktiv (Bridge/Chat), Status alle 10–15 Minuten
• Änderungen nur gemäß Runbook, keine „Nebenbei“-Optimierungen
• Commit erst nach Post-Checks (kein vorschnelles write memory)
• Rollback-Zeitbox aktiv überwachen (spätester Entscheidungszeitpunkt)

Change: Beispiel-Schrittfolge (generisch)

• Schritt 1: Zugang/Session prüfen (SSH/Bastion), Konsole bereit
• Schritt 2: Konfig laden/ändern (staged config), Syntax prüfen
• Schritt 3: Interfaces/VLANs/VRFs aktivieren (kontrolliert, in Reihenfolge)
• Schritt 4: Routing/VPN aktivieren (Neighbors/SAs prüfen)
• Schritt 5: Traffic-Path Smoke Tests (kritische Ziele)
• Schritt 6: Übergabe an Post-Change Validierung

CLI: Change-Control Checks (während des Changes)

show clock
show ip interface brief
show ip route 0.0.0.0
show ip ospf neighbor
show bgp summary
show crypto ipsec sa
show ip sla statistics
show track
show logging | last 50

Rollback: Trigger und Sofortmaßnahmen (Template)

• Trigger: kritische Services down (Internet/VPN), Routing Loops/Flaps, Managementverlust
• Trigger: CPU dauerhaft kritisch hoch, massive Drops/Errors, unkontrollierte Route-Leaks
• Sofort: Change stoppen, stabilisieren (z. B. Interface down), Entscheidung Rollback
• Rollback: PRE-Konfig/Altgerät aktivieren, Post-Checks nach Rollback

Post-Change: Validierung, UAT und Abnahme

Post-Change ist nicht „kurz schauen“. Ziel ist, nachzuweisen, dass Servicepfade, Policies, Logging und Monitoring funktionieren. Erst danach wird der Change abgeschlossen.

• Routing stabil: keine Flaps, Default/Policies korrekt
• VPN stabil: SA up und Counters steigen (falls Scope)
• Security/Management: MGMT-Only, AAA/Logging/NTP ok
• Performance: CPU/Memory Headroom, Drops/Errors unauffällig
• Monitoring: NOC sieht Gerät, Alarme getestet (mind. Interface down)

Post-Change: UAT Testfälle (Template)

• Test 1: Internet (DNS + HTTPS), Default-Route korrekt
• Test 2: Zugriff auf zentrale Services (AD/DNS/NTP/Apps) je Scope
• Test 3: VPN (falls Scope) – Applikationspfade + Counter
• Test 4: Segmentierung (Negativtests: Guest→RFC1918 blockiert, Users→MGMT blockiert)
• Test 5: Failover (stichprobenartig): Track down simulieren, Umschaltzeit messen

CLI: Post-Change Evidence Pack (Copy/Paste)

terminal length 0
show version
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 ospf neighbor
show bgp summary
show crypto ikev2 sa
show crypto ipsec sa
show ip nat statistics
show ip sla statistics
show track
show policy-map interface
show ip ssh
show ntp status
show running-config | include line vty|access-class|aaa|logging host|logging source-interface|ntp server
show logging | last 100
show processes cpu sorted
show processes memory sorted

Post-Change: Commit-Regel (Template)

• Commit („write memory“) erst nach erfolgreichen Post-Checks und UAT
• Dokumentation: As-Built/Runbook aktualisiert, Change-ID referenziert
• Abnahme: Service Owner bestätigt kritische Services, NOC bestätigt Normalzustand

Abschluss: Closure, Evidence-Ablage und PIR

Ein Change ist erst abgeschlossen, wenn Evidence abgelegt und Stakeholder informiert sind. Das reduziert spätere Diskussionen und verbessert künftige Changes.

• Closure Message: Ergebnis, Impact, offene Actions, Monitoring-Status
• Evidence Pack Ablage: PRE/POST, UAT-Protokoll, Logs, Screenshots (falls nötig)
• PIR: Lessons Learned, Template-/SOP-Updates, Risk Register aktualisieren

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.