Case Study: IOS/IOS-XE-Migration von Cisco-Routern ohne Downtime (Cutover-Methodik)

Eine IOS/IOS-XE-Migration „ohne Downtime“ ist in Enterprise-Projekten realistisch, wenn sie als kontrollierter Cutover mit paralleler Infrastruktur geplant wird: neues Gerät/IOS-XE vorbereitet, Konfiguration vorab validiert, Traffic per wartungsarmem Umschaltmechanismus migriert und jederzeit ein getesteter Rollback möglich ist. Downtime entsteht selten durch das Image selbst, sondern durch fehlende Pre-Checks (Lizenzen/Features), ungetestete Abhängigkeiten (VPN, Routing, NAT), unklare Demarkation (ISP/Firewall) und nicht standardisierte Post-Checks. Diese Case Study beschreibt eine praxistaugliche Cutover-Methodik für eine Migration von IOS zu IOS-XE (oder IOS-XE Upgrade) mit minimalem Risiko und „near-zero“ Service-Impact – inklusive Evidence Packs und UAT.

Ausgangslage: Warum IOS/IOS-XE-Migrationen oft riskant wirken

Viele Teams behandeln Migrationen wie ein normales Upgrade im Maintenance Window. In kritischen Umgebungen führt das zu langen Unterbrechungen, weil Plan B fehlt und Konfig-/Feature-Deltas erst im Livebetrieb auffallen.

• Altgeräte: heterogene IOS-Stände, teilweise EoL, inkonsistente Baselines
• Abhängigkeiten: Dual-ISP, VPN, BGP/OSPF, NAT, QoS, Logging/AAA
• Risikotreiber: Feature-Parität unklar, Lizenz-/Image-Readiness fehlt
• Operativ: kein standardisiertes Pre-/Post-Check und Evidence Pack

Zielsetzung: „Zero Downtime“ als Methodik, nicht als Versprechen

In dieser Case Study wurde „ohne Downtime“ als Service-Ziel definiert: keine sichtbare Unterbrechung für kritische Anwendungen oder nur kurze, kontrollierte Mikro-Interruptions. Entscheidend ist die Architektur des Cutovers.

• Service-Continuity: Traffic bleibt durch redundanten Pfad am Laufen
• Rollback in Minuten: Altpfad jederzeit reaktivierbar
• Evidence: Pre-/Post-Checks, UAT, Logs, Change-IDs
• Governance: standardisierte Konfig-Templates und Abnahmegates

Cutover-Design: Drei Patterns für Migration ohne Downtime

Die Methodik hängt von der vorhandenen Redundanz ab. „Ohne Downtime“ gelingt nur, wenn es während des Cutovers einen alternativen Traffic Path gibt.

• Pattern A: HA-Paar (HSRP/VRRP/GLBP) – Upgrade/Migration per Rollenwechsel
• Pattern B: Dual-ISP – Traffic temporär auf Secondary ISP, dann Cutover
• Pattern C: Paralleles Edge-Gerät – neues Gerät vorbereitet, Umschaltung per L2/L3 Demarkation

Vorbereitung: Readiness Checks (Image, Lizenz, Feature-Parität)

Die wichtigste Phase ist die Vorbereitung. Hier wird entschieden, ob der Cutover glatt läuft oder im Incident endet. Prüfen Sie Feature-Parität zwischen IOS und IOS-XE.

• Hardware: Plattform kompatibel, Performance-Headroom (CPU/Memory)
• Software: Ziel-Release festgelegt, Security Advisories berücksichtigt
• Lizenzen: benötigte Features vorhanden (z. B. Security/VPN, Routing)
• Konfig-Deltas: Kommandos/Features, die sich zwischen IOS und IOS-XE unterscheiden

CLI: Altgerät – Readiness Snapshot

terminal length 0
show version
show inventory
show boot
show license summary
show running-config
show startup-config

Build-Phase: Golden Config und Migrations-Template

Die Konfiguration wurde nicht „kopiert“, sondern als Golden Config neu gerendert: Baseline (Management/Logging/NTP/AAA) plus Module (VPN, Dual-ISP, Routing, QoS). Das reduziert Legacy-Altlasten.

• Baseline: SSH/MGMT-Only, AAA/Accounting, NTP, Syslog, Monitoring
• Routing Module: OSPF/BGP Policies, Summaries, max-prefix
• VPN Module: IKEv2/IPsec Standards, No-NAT Patterns
• Governance: Template-Version und Change-ID im Header

CLI: Governance Header (Beispiel)

!
! MIGRATION: IOS->IOS-XE
! TEMPLATE: edge-golden
! VERSION: v1.0.0
! CHANGE-ID: CHG-2026-00XXXX
!

Validate-Phase: Lab/Pre-Prod Tests und UAT-Katalog

Vor dem Cutover wurden Standard-UATs definiert. Wichtig ist, dass nicht nur „Ping“ getestet wird, sondern auch End-to-End Services und Failover-Verhalten.

• Connectivity: Internet, DNS, zentrale Services
• Routing: Neighbor-Stabilität, Prefix Counts, Default-Pfad
• VPN: SA up und Traffic aktiv (Counter)
• Security: MGMT-Only, AAA, Logging, NTP
• Resilience: Failover-Tests (wenn Dual-ISP/HA im Scope)

CLI: UAT Evidence Bundle (Auszug)

show clock
show ntp status
show ip interface brief
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 logging | last 100

Cutover-Methodik: Ablauf mit „Traffic zuerst sichern, dann umschalten“

Der Cutover wurde als Schrittfolge mit Kontrollpunkten geplant. Kernprinzip: Servicepfad stabilisieren (z. B. über Secondary) und erst dann das produktive Edge-Device migrieren.

• Schritt 1: Pre-Change Baseline + PRE Backup + Go/No-Go
• Schritt 2: Traffic auf redundanten Pfad (HA Secondary/ISP2) verlagern
• Schritt 3: Altgerät aus dem Traffic nehmen (controlled isolation)
• Schritt 4: Migration/Upgrade oder neues IOS-XE Gerät aktivieren
• Schritt 5: Post-Checks und UAT, dann Rückschwenk (wenn geplant)

Beispiel Cutover Pattern A: HA Rollenwechsel (minimale Unterbrechung)

Wenn zwei Edge-Router existieren, wird der aktive Pfad per HSRP/VRRP/GLBP umgestellt. Das ermöglicht Wartung am passiven Gerät, während Traffic weiterläuft.

• Aktiv/Standby prüfen, dann Failover bewusst auslösen
• Standby migrieren/upgrade, validieren, dann optional zurückwechseln
• Rollback: Role switch zurück, falls Probleme auftreten

CLI: HA-Verifikation (Beispielkommandos)

show standby brief
show vrrp brief
show glbp brief

Beispiel Cutover Pattern B: Dual-ISP Traffic Shift (Branch/HQ Edge)

Bei Dual-ISP wurde der Primary Pfad temporär entlastet: Default Route/Tracking wurde so gesetzt, dass der Standort über ISP2 stabil arbeitet. Dann wurde ISP1/Edge migriert.

• Track/Default-Route bewusst auf ISP2 setzen (temporär)
• Migration am IOS/IOS-XE Device durchführen, ohne Service zu verlieren
• Failback nach stabiler Validierung

CLI: Dual-ISP Evidence

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

Post-Change: Validierung und Evidence Collection als Abnahme

Nach Aktivierung des IOS-XE Geräts wurde nicht sofort „committed“. Erst nach Post-Checks, UAT und Stabilitätsfenster wurde die Änderung abgeschlossen.

• Post-Checks: identisch zum Pre-Check Bundle (vergleichbar)
• UAT: kritische Services bestätigt durch Service Owner
• Monitoring: NOC sieht KPIs, keine Flaps/Errors
• Commit: write memory erst nach Abnahme

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

terminal length 0
show version
show clock
show ntp status
show ip interface brief
show interfaces counters errors
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 logging | last 150
show processes cpu sorted

Rollback-Plan: Trigger, Zeitbox und minimale Schritte

Rollback ist ein Muss, nicht optional. In der Case Study wurde ein spätester Rollback-Zeitpunkt definiert und die Rückkehr zum Altpfad in wenigen Schritten geübt.

• Rollback Trigger: kritische Services down, Routing Flaps/Loops, VPN instabil
• Zeitbox: klarer Zeitpunkt im Change Window (z. B. T+30min)
• Rollback Pfad: Traffic zurück auf Altgerät/Altpfad (HA/ISP2/Parallel)
• Post-Rollback Checks: Evidence Pack auch für Rollback

Lessons Learned: Was die Downtime tatsächlich minimiert

Die wichtigsten Erkenntnisse betreffen Prozess und Testdisziplin. Die Migration selbst ist selten das Problem, sondern die fehlende Absicherung.

• „Ohne Downtime“ braucht Redundanz: HA oder Dual-ISP oder paralleles Gerät
• Golden Config statt Copy/Paste reduziert Legacy-Risiken
• UAT muss Traffic-Pfade beweisen (VPN Counter, Routing Stability)
• NTP/Syslog/AAA als Go-Live Gate erhöht Auditfähigkeit und RCA-Qualität
• Rollback muss geübt sein, nicht nur dokumentiert

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.