Site icon bintorosoft.com

Campus Migration ohne Downtime: Strategie, Phasenplan und Fallstricke

Red Snapper

„Campus Migration ohne Downtime“ ist selten wirklich „null Sekunden“, aber operativ erreichbar, wenn du die Migration so planst, dass kritische Funktionen redundant bleiben und Änderungen in kontrollierten, rückbaubaren Schritten erfolgen. Der Schlüssel ist nicht ein einzelnes Feature, sondern ein Phasenplan: erst Beobachten und vorbereiten, dann parallelisieren (Dual-Path), anschließend kontrolliert umschalten und am Ende aufräumen. Dieser Leitfaden zeigt eine praxistaugliche Strategie für Cisco-Campus-Netze, typische Phasen, Verifikationschecks und die Fallstricke, die in realen Projekten am häufigsten zu Ausfällen führen.

Realistische Zieldefinition: Was bedeutet „ohne Downtime“ im Campus?

Definiere zunächst, welche „Downtime“ akzeptabel ist. Für viele Services ist ein kurzer Gateway-Failover (Millisekunden bis wenige Sekunden) tolerierbar, während VoIP oder Echtzeit-Video empfindlicher ist. Eine klare Definition steuert alle Designentscheidungen.

Leitprinzipien für Downtime-arme Migrationen

Wenn du diese Prinzipien durchziehst, wird die Migration beherrschbar. Sie reduzieren „Big Bang“-Risiko und ermöglichen Rollback.

Phase 0: Discovery, Baseline und Risikoinventar

Bevor du umbaust, musst du wissen, was du hast. Viele Downtime-Vorfälle entstehen, weil VLANs, Trunks, Abhängigkeiten oder Sonderports (APs, Hypervisor, Firewalls) nicht vollständig erfasst wurden.

Discovery-Kommandos (Copy/Paste)

show cdp neighbors detail
show lldp neighbors detail
show interfaces trunk
show etherchannel summary
show spanning-tree root
show spanning-tree summary
show ip interface brief
show standby brief
show ip route
show inventory

Phase 1: Standards stabilisieren (vor der Migration)

Eine Migration scheitert oft an Konfig-Drift. Stabilisiere daher zuerst Baselines: NTP/Syslog, Trunk-Whitelists, Native VLAN, DTP aus, Edge-Security und saubere Port-Channels. Das reduziert Nebenwirkungen beim späteren Umschalten.

Trunk-Standard prüfen

show interfaces trunk
show logging | include NATIVE|VLAN|TRUNK

Phase 2: Parallelpfad aufbauen (Dual-Path / Shadow Infrastructure)

Downtime-arm wird es, wenn der neue Pfad bereits vorhanden und getestet ist, bevor du den alten Pfad entfernst. Das heißt: neue Distribution/Core-Verbindungen, neue Port-Channels und ggf. neue Gateways werden parallel aufgebaut.

Parallelpfad verifizieren

show etherchannel summary
show interfaces status
show ip route
show logging | include LINK|LINEPROTO

Phase 3: Gateway-Strategie festlegen (FHRP vs. Anycast/Layer-3 Access)

Der größte Impact entsteht meist beim Gateway (SVIs). Du musst entscheiden, wie du Gateways migrierst: klassisch mit HSRP/VRRP und kontrolliertem Active/Standby-Wechsel, oder modernisiert (z. B. Layer-3 Access). Die Migrationsstrategie hängt vom Ziel-Design ab.

HSRP Status prüfen

show standby brief
show running-config | section interface Vlan

Phase 4: Controlled Cutover – Umschalten in kleinen Domänen

Der eigentliche Cutover passiert nicht „einmal“, sondern in Wellen. Du migrierst z. B. ein Gebäude, einen Access-Block oder eine VLAN-Gruppe. Nach jeder Welle folgt Verifikation und ein klarer Rollback-Punkt.

Cutover-Verifikationsblock

show interfaces trunk
show etherchannel summary
show spanning-tree root
show spanning-tree inconsistentports
show standby brief
show ip arp
show logging | include LINK|LINEPROTO|SPANNING|HSRP|STANDBY

Phase 5: Stabilisierung und Cleanup (oft unterschätzt)

Viele Migrationen sind „technisch fertig“, aber operativ instabil, weil alte Trunks, alte VLANs, alte Root-Placement oder Doppelpfade bleiben. Cleanup ist entscheidend, um spätere Loops und Drift zu verhindern.

Typische Fallstricke, die echte Downtime verursachen

Diese Punkte sind die häufigsten Ursachen für „eigentlich sollte es ohne Downtime gehen, aber…“. Wenn du sie vorher prüfst, sparst du die meisten Ausfälle.

Downtime-arme Tests: Wie du Failover sicher ausprobierst

Testen heißt nicht „alles aus“. Testen heißt: kontrollierte Fehler injizieren und messen. Typisch sind Link-Down am Uplink, Reload eines Distribution-Switches im Wartungsfenster und HSRP-Failover unter Beobachtung.

Failover-Indikatoren prüfen

show logging | include LINK|LINEPROTO|TOPOLOGY|SPANNING|HSRP|STANDBY
show spanning-tree vlan 10 detail
show standby brief

Operative Steuerung: Change-Plan, Kommunikation, Rollback

Ohne operativen Rahmen ist „ohne Downtime“ unrealistisch. Ein belastbarer Plan enthält Timeboxes, Verantwortlichkeiten, Kommunikationswege und klare Rollback-Kriterien.

Pre-Change Evidence (Baseline sichern)

show clock
show ntp status
show interfaces trunk
show etherchannel summary
show spanning-tree root
show standby brief
show interfaces counters errors

copy running-config startup-config

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

Sie erhalten

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.

Exit mobile version