Cisco-Router-Migration: Vom Altgerät zu IOS/IOS-XE ohne Downtime

Eine Cisco-Router-Migration vom Altgerät auf IOS/IOS-XE ohne Downtime ist möglich, wenn Sie das Projekt als kontrollierte Umschaltung mit Parallelbetrieb planen: Neues Gerät vorbereiten, Konfiguration und Policies kompatibel abbilden, Traffic schrittweise umleiten und jederzeit zurückrollen können. Entscheidend sind stabile Zugangspfade (idealerweise Out-of-Band), saubere Pre-/Post-Checks, ein klarer Cutover-Plan und ein Design, das Übergangsphasen (Dual-ISP, VRRP/HSRP, Routing-Prioritäten) unterstützt.

Was „ohne Downtime“ in der Praxis bedeutet

„Ohne Downtime“ heißt meist: Keine wahrnehmbare Unterbrechung für kritische Anwendungen oder nur kurze, tolerierbare Mikrounterbrechungen (z. B. 1–3 Sekunden bei Gateway-Failover). Vollständig unterbrechungsfrei gelingt es typischerweise nur mit Redundanz und Parallelbetrieb.

• Zero-Downtime-Ansatz: Parallelbetrieb + kontrollierte Umschaltung
• Akzeptierte Mikrounterbrechung: Gateway-/Routing-Konvergenz
• Harte Downtime entsteht meist durch Layer-1/Provider-Umschaltungen ohne Redundanz

Voraussetzungen: Damit eine Downtime-freie Migration realistisch ist

Die wichtigsten Voraussetzungen sind Redundanz und ein sicherer Notfallzugang. Ohne zweiten Uplink oder ohne HA am LAN-Gateway wird „ohne Downtime“ schnell zu einer Marketing-Aussage statt eines belastbaren Plans.

• Zweiter WAN-Pfad oder temporärer Parallel-Uplink (z. B. zweiter Provider, LTE)
• HA am LAN-Gateway (HSRP/VRRP) oder L3-Routing-Design mit kontrollierter Präferenz
• Out-of-Band-Management oder Remote-Hands für Console-Recovery
• Geklärte Provider-Übergaben (VLAN-Tag, IP, MTU, BGP-Parameter)
• Definierte Abnahme- und Rollback-Kriterien (SOP)

Phase 1: Assessment des Altgeräts (Ist-Zustand & Risiken)

Der häufigste Migrationsfehler ist „Config kopieren und hoffen“. Stattdessen müssen Funktionen, Abhängigkeiten und Sonderfälle identifiziert werden: NAT-Ausnahmen, PBR, VPN-Selektoren, QoS, Routing-Redistribution, Management-ACLs.

Ist-Daten erfassen (Mindestset)

show version
show inventory
show running-config
show ip interface brief
show interfaces counters errors
show ip route summary
show ip protocols
show logging | last 100

Fokus-Checks für typische Stolpersteine

show ip nat translations
show ip nat statistics
show crypto ikev2 sa
show crypto ipsec sa
show policy-map interface
show route-map
show access-lists

Phase 2: Kompatibilitätsprüfung IOS vs. IOS XE

IOS XE ist architektonisch anders (Prozesse, Plattform-Kommandos, Feature-Implementierung). Viele Konfigurationszeilen sind ähnlich, aber nicht immer 1:1 kompatibel. Ziel ist eine Mapping-Tabelle: „Altfeature → Neuimplementation → Testfall“.

• Interface-Namen/Portlayout prüfen (Gi/Te vs. neue Slot/Port-Zuordnung)
• Lizenz- und Feature-Verfügbarkeit prüfen (z. B. Security, Crypto, Routing)
• Crypto-Defaults können sich unterscheiden (IKEv2/IPsec Kompatibilität)
• Monitoring-Kommandos (plattformabhängig) anpassen

Phase 3: Design für Parallelbetrieb (ohne Downtime)

Downtime-freie Migration basiert auf Parallelbetrieb. Das neue Gerät wird in die Umgebung eingebunden, ohne zunächst den aktiven Pfad zu übernehmen. Erst wenn alle Prüfungen bestanden sind, erfolgt der kontrollierte Wechsel.

Option A: HA am LAN-Gateway mit HSRP/VRRP (empfohlen)

Beide Router hängen am gleichen LAN-Switch/Segment. Der Altrouter bleibt zunächst Active, der neue Standby. Danach wird die Priorität umgestellt oder ein Failover ausgelöst.

• Vorteil: Clients behalten Default-Gateway-IP (virtuelle IP)
• Umschaltung: Sekundenbereich, planbar und reversibel
• Geeignet: Büros/Filialen mit L2-Access und zentralem Gateway

Option B: Routing-Priorität (Static AD/OSPF Cost/BGP LocalPref)

Wenn das Gateway nicht per FHRP (HSRP/VRRP) abgebildet wird, kann Routing-Priorisierung genutzt werden: Das neue Gerät erhält zunächst höhere AD/Kosten und übernimmt später durch Kosten-/AD-Änderung.

• Vorteil: funktioniert auch in reinen L3-Designs
• Risiko: Konvergenz hängt von Protokollen/Timers ab

Phase 4: Pre-Staging des neuen Routers (Lab/Remote, ohne Einfluss)

Der neue Router wird vor dem Cutover vollständig vorbereitet: Hardening, Basisrouting, NAT/VPN-Bausteine, Monitoring, Templates. Ziel ist, dass im Change-Fenster nur noch Parameter und Umschaltung erfolgen.

Mindest-Hardening als Basis

no ip domain-lookup
no ip http server
no ip http secure-server
ip domain-name example.local

username netadmin privilege 15 secret 
crypto key generate rsa modulus 2048

ip ssh version 2

line vty 0 4

transport input ssh

login local

exec-timeout 10 0
service timestamps log datetime msec

ntp server 192.0.2.10 prefer

logging host 192.0.2.20

logging trap informational

Konfigurationsstruktur standardisieren

• Interface-Descriptions und Namenskonventionen
• Separate Blöcke: Management, WAN, LAN, Routing, NAT, VPN, QoS
• Pre-/Post-Checks als SOP in der Doku

Phase 5: Parallelbetrieb herstellen (ohne den aktiven Pfad zu stören)

Jetzt wird das neue Gerät physisch eingebunden, aber noch nicht „führend“. Wichtig sind saubere L1/L2-Prüfungen und ein Management-Zugang, der auch bei Fehlkonfiguration erreichbar bleibt.

Physik und Basis-Connectivity verifizieren

show ip interface brief
show interfaces counters errors
show cdp neighbors detail
show lldp neighbors detail

WAN und Upstream testen (ohne produktive Umschaltung)

ping 198.51.100.1
traceroute 1.1.1.1
show ip route 0.0.0.0

Downtime-freier Cutover mit HSRP/VRRP (Beispielmuster)

Bei FHRP teilen sich Alt und Neu eine virtuelle Gateway-IP. Der Altrouter bleibt zunächst Active. Zum Cutover wird die Priorität des neuen Routers erhöht oder der Altrouter temporär „getrackt“ und verliert Active.

Beispiel: HSRP auf VLAN10 (Altrouter Active, Neurouter Standby)

interface GigabitEthernet0/1.10
 description VLAN10-USERS
 encapsulation dot1Q 10
 ip address 10.10.10.2 255.255.255.0
 standby 10 ip 10.10.10.1
 standby 10 priority 90
 standby 10 preempt

Cutover: Neue Priorität setzen (Neurouter übernimmt)

interface GigabitEthernet0/1.10
 standby 10 priority 110

Erwartete Ergebnisse beim Cutover

• Clients behalten Default-Gateway 10.10.10.1 (virtuell)
• Kurzzeitige Umschaltung im Sekundenbereich (ARP/Gateway-Failover)
• Nach Umschaltung: Routing/NAT/VPN laufen über den neuen Router

FHRP-Verifikation

show standby brief
show standby
show ip arp | include 10.10.10.1

NAT, VPN und Routing in der Übergangsphase: Häufige Fallstricke

Die kniffligen Teile der Migration sind selten Interfaces, sondern State: NAT-Translations, VPN-SAs und bestehende Sessions. Bei Umschaltung können Sessions abbrechen, wenn Quell-IP/State wechselt. Daher wird „ohne Downtime“ meist als „ohne spürbare Downtime“ für kritische Dienste umgesetzt – oder über Redundanz auf Applikationsebene ergänzt.

NAT: Erwartung an Session-Verhalten

• Bei Routerwechsel: NAT-States werden neu aufgebaut, bestehende Sessions können abbrechen
• Minimieren durch: Cutover außerhalb Peak, kurze Umschaltung, ggf. App-Reconnect
• Pflicht: No-NAT für VPN bleibt identisch, sonst Tunnel-Traffic bricht

VPN: Parallelbetrieb und kontrollierte Umschaltung

• IKEv2/IPsec-Profil konsistent halten (Cipher/Hash/DH/PFS)
• Peers und Selektoren 1:1 übernehmen, MTU/MSS prüfen
• Bei Dual-ISP: Primary/Backup-Tunnel sauber priorisieren

VPN-Checks vor und nach Cutover

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

Phase 6: Post-Checks und Abnahme (Go-Live-Validierung)

Die Abnahme muss reproduzierbar sein: gleiche Tests wie im Pre-Check, plus kritische Applikationspfade. Nur so ist nachweisbar, dass die Migration nicht nur „irgendwie läuft“, sondern betriebssicher ist.

Standard-Post-Checks

show ip interface brief
show interfaces counters errors
show ip route
show ip protocols
show processes cpu sorted
show processes memory sorted
show logging | last 50

Connectivity- und Pfadtests

ping 8.8.8.8 source 10.10.10.1
traceroute 1.1.1.1 source 10.10.10.1

Rollback-Plan: Pflicht für „ohne Downtime“

Downtime-freie Migration ist nur glaubwürdig, wenn Rollback schnell und eindeutig ist. Bei FHRP bedeutet Rollback meist: Priorität zurücksetzen oder den alten Router wieder Active machen. In L3-Designs bedeutet es: Kosten/AD zurück oder Routenpräferenz ändern.

• Rollback-Trigger: Verlust Management, WAN instabil, VPN kritisch down, Routing-Loop, hohe CPU
• Rollback-Schritte: FHRP-Priorität zurück, alte Default-Route/Policy aktivieren
• Rollback-Validierung: Standard-Checks + Applikationspfade

Beispiel: Rollback per HSRP-Priorität (vereinfacht)

interface GigabitEthernet0/1.10
 standby 10 priority 90

Dokumentation und Deliverables: Was am Ende vorliegen muss

Eine saubere Migration ist nicht nur ein technischer Wechsel, sondern ein operatives Deliverable. Dokumentation reduziert spätere Störungen und macht Audits und Erweiterungen deutlich einfacher.

• Konfiguration Alt/Neu (vorher/nachher), Versionsstände IOS/IOS XE
• Mapping-Tabelle (Altfeature → Neuimplementation → Testfall)
• Cutover-Plan inkl. Timings, Verantwortlichkeiten, Kommunikationsplan
• Pre-/Post-Check-Protokolle, Abnahmeprotokoll
• Rollback-Plan mit klaren Triggern und Schritten

Praxis-Tipp: Migration ohne Downtime durch „Parallelpfad“ absichern

Wenn echte Zero-Downtime gefordert ist, planen Unternehmen häufig einen temporären Parallelpfad: zweiter Uplink, OOB-LTE oder ein zweiter Router im Standby. Damit bleiben Management und Produktion auch dann erreichbar, wenn ein Schritt unerwartet scheitert.

• Temporäres Dual-WAN oder LTE-OOB für Change-Fenster
• FHRP für Gateway-Stabilität, Routing-Präferenz für Edge-Steuerung
• Standardisierte Templates, damit Standorte konsistent migriert werden

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.