„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.
- Akzeptabler Impact: 0 Sekunden, < 1 Sekunde, < 5 Sekunden?
- Welche Services sind kritisch (Voice, WLAN, Produktionssysteme)?
- Welche Bereiche dürfen einzeln kurz betroffen sein (ein Access-Block)?
- Wie wird Erfolg gemessen (Monitoring, Paketverlust, Call-Drops)?
Leitprinzipien für Downtime-arme Migrationen
Wenn du diese Prinzipien durchziehst, wird die Migration beherrschbar. Sie reduzieren „Big Bang“-Risiko und ermöglichen Rollback.
- Parallelbetrieb statt Umbruch: neuer Pfad existiert, bevor der alte entfernt wird
- Änderungen in kleinen Failure Domains (Access-Block, Gebäude, VLAN-Gruppe)
- Jede Phase hat klare Exit-Kriterien und einen Rollback-Schritt
- Messbarkeit: NTP, Syslog, SNMP/Telemetry und Baselines vor dem Change
- „Minimale Überraschungen“: Standards/Templates vorab durchsetzen
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.
- Topologie: Access–Distribution–Core Pfade, Port-Channels, Trunks
- VLAN-Plan: wo existiert welches VLAN, wo sind SVIs/Gateways?
- STP: Root Bridge pro VLAN, TCN-Hotspots, Guard-States
- Routing/FHRP: HSRP/VRRP, Tracking, aktive Gateways
- Monitoring/Logging: Syslog zentral, NTP synchron, SNMPv3 aktiv
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.
- NTP/Syslog standardisieren (Zeitdrift eliminieren)
- Trunks: Allowed VLANs als Whitelist, Native VLAN ungenutzt
- DTP deaktivieren, VLAN 1 nicht produktiv
- Edge: PortFast/BPDU Guard default, Parking VLAN für unbenutzte Ports
- Uplinks als LACP-Port-Channels konsistent
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.
- Neuen Core/Distribution Link als L3-Link (oder kontrollierter Trunk) hinzufügen
- Neue Switches/Stacks in Betrieb nehmen, ohne Traffic umzuschalten
- Routing-Nachbarschaften und Konvergenz testen (ohne Produktivtraffic)
- VLANs nur dort zulassen, wo sie wirklich gebraucht werden
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/VRRP: Active Gateway kontrolliert verschieben (per VLAN oder VLAN-Gruppe)
- Tracking: Uplink-Status beeinflusst Gateway-Rolle (sauberes Failover)
- ARP/ND Effekte einkalkulieren (kurze Micro-Unterbrechungen möglich)
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.
- Welle definieren: Welche Access-Switches/VLANs heute?
- Uplinks umhängen oder Port-Channel aktivieren (neuer Pfad übernimmt)
- Gateway-Rolle gezielt wechseln (HSRP/VRRP)
- Nachweis: Connectivity, Voice, WLAN, DHCP, Monitoring
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.
- Alte Links/Trunks entfernen, die nicht mehr gebraucht werden
- Allowed VLANs neu whitelisten (kein „temporär allow all“ stehen lassen)
- STP Root Placement überprüfen und Guards konsistent setzen
- Monitoring/Backups/Inventory aktualisieren
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.
- VLAN fehlt auf einem Trunk (Allowed VLANs, „allowed but not active“)
- Native VLAN mismatch oder DTP aktiviert (Trunk wird unerwartet)
- Port-Channel inkonsistent (Member nicht gebündelt, VLANs/Natives unterschiedlich)
- STP Root ungeplant (Access wird Root, Ports blockieren anders)
- HSRP ohne Tracking/Preempt-Strategie (Gateway wechselt falsch oder flapt)
- DHCP Snooping Trust falsch gesetzt (Clients verlieren IP)
- NTP/Syslog nicht sauber (Analyse im Incident unmöglich)
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.
- Link-Down Test auf einem Uplink (Port-Channel Member)
- HSRP Active/Standby Switch kontrolliert (pro VLAN-Gruppe)
- STP/TCN Monitoring während des Tests
- Voice/WLAN Qualität messen (nicht nur Ping)
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.
- Timebox pro Welle (Start, Cutover, Verifikation, Cleanup)
- Rollback-Kriterien: welche Symptome triggern Rückbau?
- Kommunikation: NOC/Service Desk, Stakeholder, Eskalationspfad
- Dokumentation: was wurde wann umgestellt (Audit-Trail)
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
-
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.
