Switch-Firmware-Upgrade ohne Downtime: Rollout-Strategie, Prüfungen und Rollback-Plan

Ein Switch-Firmware-Upgrade ohne Downtime klingt nach einem Versprechen, das in der Praxis oft an Details scheitert: ein einzelner Uplink ohne LACP, ein falsch gesetzter STP-Pfad, ein Stack mit gemischten Modellen oder ein Image, das zwar bootet, aber neue Defaults aktiviert. Gleichzeitig sind Firmware-Updates kein „nice to have“. Sie schließen Sicherheitslücken, beheben Speicherlecks, verbessern Interoperabilität (z. B. bei LACP, BGP/EVPN oder PoE) und stabilisieren den Betrieb.

Dieser Beitrag zeigt, wie Sie Firmware-Upgrades so planen und ausrollen, dass Nutzer und Systeme im Idealfall nichts merken. Im Fokus stehen nicht Hersteller-spezifische Kommandos, sondern die betriebliche Logik: welche Redundanz Sie wirklich brauchen, welche Prüfungen vorab zwingend sind, wie ein stufenweiser Rollout über Access/Distribution/Core aussieht und wie ein belastbarer Rollback-Plan aussieht – inklusive typischer Stolperfallen und Monitoring-Punkten.

Warum „ohne Downtime“ bei Switches manchmal stimmt – und manchmal nicht

„Ohne Downtime“ bedeutet in Netzwerken meist: keine wahrnehmbare Unterbrechung für die angebundenen Services. Technisch kann es trotzdem kurze Ereignisse geben: einzelne Paketverluste, ein Routing-Reconvergence, ein STP-Topology-Change oder ein Link-Flap. Ob das als Downtime zählt, hängt von Ihren Applikationen (VoIP, OT, Storage, VDI), von Timeouts und von Ihrer Redundanz ab.

Wichtig: Ein Firmware-Upgrade ist nicht automatisch „hitless“. Hersteller bieten Mechanismen wie ISSU (In-Service Software Upgrade, Upgrade im laufenden Betrieb), „non-disruptive upgrade“, „rolling upgrade“ in Stacks oder Upgrade-Pfade für MLAG/vPC. Diese Verfahren funktionieren nur, wenn bestimmte Voraussetzungen erfüllt sind: kompatible Hardware-Revisionen, unterstützte Feature-Set-Kombinationen, identische Images, passende Bootloader-Versionen, korrektes Dual-Control-Plane-Design oder stabile LACP-Partner.

Grundvoraussetzungen für ein Switch-Firmware-Upgrade ohne Downtime

Ob Sie wirklich ohne spürbare Unterbrechung upgraden können, entscheidet sich vorab. Prüfen Sie diese Punkte, bevor Sie überhaupt ein Image herunterladen:

1) Redundanz ist kein Label, sondern ein Nachweis

„Dual-homed“ ist nur dann belastbar, wenn jede kritische Verbindung redundant ist – und zwar bis zum nächsten Layer (Distribution/Core) und weiter bis zu Routing-Gateways. Typische Muster:

• LACP (Link Aggregation Control Protocol): Bündelt mehrere physische Links zu einem logischen Port-Channel. Fällt ein Link weg, bleibt der Channel aktiv. Voraussetzung: korrektes Hashing, gleiche MTU, gleiche VLAN- und STP-Parameter auf allen Member-Ports.
• MLAG/vPC: Zwei Switches erscheinen gegenüber dem Downstream als ein logischer LACP-Partner. Vorteil: Redundanz ohne STP-Blocking auf Access-Uplinks. Risiko: Peer-Link/Keepalive-Design und Split-Brain-Schutz müssen sauber sein.
• Stacking: Mehrere Switches bilden ein logisches Gerät. Rolling-Upgrade kann funktionieren, aber ein Stack ist auch ein gemeinsames Failure-Domain – Firmware, Control-Plane und Backplane-Topologie sind eng gekoppelt.

Wenn ein Access-Switch nur einen Uplink hat oder ein Server nur eine NIC ohne Bonding/Teaming nutzt, ist „ohne Downtime“ dort nicht erreichbar. Dann ist das Ziel eher: Downtime minimieren und kontrollieren.

2) Control Plane vs. Data Plane verstehen

Für Betreiber ist die Trennung entscheidend: Die Data Plane leitet Pakete weiter (ASICs/Forwarding), die Control Plane berechnet Tabellen und Nachbarschaften (STP, OSPF/BGP, ARP/ND). Ein hitless Upgrade versucht, Forwarding möglichst lange stabil zu halten, während die Control Plane neu startet oder auf eine zweite Supervisor/Route-Engine wechselt. Scheitern kann das, wenn Features genutzt werden, die während ISSU nicht unterstützt sind (z. B. bestimmte Telemetrie-Module, PBR, spezielle QoS-Profile, MACsec, VXLAN/EVPN-Kombinationen je nach Release).

3) Management-Zugang und Out-of-Band müssen stehen

Ohne OOB-Management (Out-of-Band, separates Management-Netz) wird ein Rollout riskant: Wenn das Inband-Netz kurz wackelt, verlieren Sie Zugriff genau dann, wenn Sie ihn brauchen. Mindestens nötig sind: konsistentes AAA (RADIUS/TACACS), lokale Fallback-Accounts, erreichbare Konsolenserver oder Remote-Hands-Prozess.

4) Konfigurations- und Zustandsdaten sichern

Ein Firmware-Upgrade ändert nicht nur die Software, sondern manchmal auch: Bootloader, Default-Werte, Feature-Flags, Datenbankformate für Konfiguration oder Zertifikats-/Key-Stores. Sichern Sie daher:

• Running und Startup-Konfiguration
• Aktuelles Image-Set (inkl. Secondary/Backup-Image, falls vorhanden)
• Inventar: Modell, Seriennummer, Hardware-Revision, PSU/Fan-Status
• Wichtige Betriebszustände: STP-Root, MLAG/vPC-Status, Routing-Adjacencies, Port-Channel-Status

Rollout-Strategie: So planen Sie den Upgrade-Pfad über Access, Distribution und Core

Die beste Upgrade-Strategie orientiert sich an Fehlerdomänen und Abhängigkeiten. Ein einfaches, in der Praxis robustes Prinzip: erst die Ränder, dann die Mitte – aber mit Bedacht.

Phase 0: Readiness-Check und Change-Plan

Erstellen Sie einen Change-Plan, der nicht nur „Upgrade durchführen“ sagt, sondern messbare Kriterien enthält: Go/No-Go, Monitoring-Schwellen, Rollback-Trigger, Kommunikationsweg und Zeitplan. Wenn Sie ITIL-orientiert arbeiten: Backout-Plan ist Pflicht, aber er muss technisch ausführbar sein (siehe weiter unten).

Phase 1: Lab/Canary – eine repräsentative Teilmenge

Starten Sie mit einem Canary: ein Switch oder ein Paar (MLAG/vPC) in einem Segment, das repräsentativ ist (gleiche Features, ähnliche VLANs, gleiche Optics/Transceiver) – aber betrieblich tolerierbar. Ziel ist nicht nur „bootet“, sondern: läuft stabil unter Ihrer Last und Ihrem Monitoring.

Phase 2: Access-Layer rolling upgraden

Access-Switches sind oft zahlreich, aber einzeln weniger kritisch. Wenn Endgeräte dual-homed sind (z. B. Server mit LACP zu zwei Access-Switches oder zu einem MLAG-Paar), können Sie Access-Geräte nacheinander upgraden. Wenn Endgeräte single-homed sind, definieren Sie dort explizit, dass kurze Unterbrechungen möglich sind – und planen Sie diese in ein Wartungsfenster.

Phase 3: Distribution/Leaf – paarweise und mit Zustandsprüfungen

In der Distribution (oder Leaf-Ebene im Spine-Leaf-Design) sind MLAG/vPC/EVPN-Mechanismen häufiger. Hier wird das Upgrade „ohne Downtime“ realistisch, wenn Sie paarweise vorgehen: erst Switch A, Stabilität prüfen, dann Switch B. Wichtig ist, dass die Peer-Links und Keepalives währenddessen stabil bleiben.

Phase 4: Core/Spine – nur mit gesicherter Routing-Convergence

Im Core oder Spine-Layer ist die Auswirkung am größten. Selbst wenn Datenpfade redundant sind, kann ein Control-Plane-Neustart BGP/OSPF neu aufbauen. Planen Sie hier bewusst: Route-Policy-Änderungen vermeiden, Timer nicht „on the fly“ anfassen, und prüfen Sie vorab, ob Ihre Applikationen kurze Routing-Events tolerieren. Für Storage-Netze (iSCSI/NFS) gilt: besonders konservativ planen, da kurze Paketverluste bereits Sessions beeinträchtigen können.

Typische Stolperfallen, die „hitless“ in der Praxis kippen

Viele Ausfälle beim Firmware-Rollout sind keine mysteriösen Bugs, sondern wiederkehrende Muster:

• Asymmetrische Redundanz: Zwei Uplinks existieren, aber nur einer trägt VLANs oder MTU ist unterschiedlich. Bei Failover kommt es zu Blackholing.
• STP-Überraschungen: Spanning Tree (Schleifenvermeidung auf Layer 2) reagiert auf Link-Events. Ein Upgrade kann Topology-Changes auslösen, die zu kurzzeitigem Blocking führen – besonders bei falsch platziertem Root oder inkonsistenten PortFast/Edge-Einstellungen.
• MLAG/vPC-Split-Brain: Peer-Keepalive läuft über dasselbe Netz wie der Peer-Link oder ist zu fragil. Fällt er weg, kann es zu Dual-Active-Situationen kommen.
• Stacks mit gemischten Generationen: Rolling-Upgrade ist eingeschränkt oder gar nicht möglich. Ein Member rebootet und zieht den Stack-Status mit.
• Transceiver/Optics-Kompatibilität: Nach dem Upgrade werden Drittanbieter-Optics strenger geprüft oder die DOM/EEPROM-Auswertung ändert sich. Ergebnis: Links bleiben down.
• Bootloader/ROMMON-Abhängigkeiten: Neues Image verlangt einen Bootloader-Upgrade-Schritt. Wird der übersprungen, kann der Switch nach Reboot nicht starten.
• Feature-Flags und Defaults: Sicherheitsfeatures (z. B. strengere SSH-Krypto-Defaults, TLS-Versionen, SNMPv3-Pflichten) ändern sich. Management-Tools verlieren Zugriff.

Vorab-Prüfungen: Checkliste für Inventur, Kompatibilität und Risiko

Die folgenden Prüfungen sind so formuliert, dass Sie sie in Ihr Runbook übernehmen können. Herstellerkommandos variieren, die Logik bleibt gleich.

Inventur und Abhängigkeiten (zwingend)

• Aktuelle Firmware-Version und geplante Zielversion; prüfen, ob ein Zwischenschritt erforderlich ist (Upgrade-Path).
• Hardware-Revisionen, Stack-Member, Supervisor/RE-Module, PSU/Fan-Status.
• Genutzte Features: MLAG/vPC, VXLAN/EVPN, MACsec, PBR, NetFlow/sFlow, Telemetrie, DHCP Snooping, Dynamic ARP Inspection, 802.1X.
• Management: AAA, SSH-Policies, SNMP (v2c/v3), Syslog, NTP, Zertifikate.
• Abhängige Systeme: NAC, Monitoring, Config-Backup, IPAM/DCIM, Automations-Tooling.

Redundanz-Validierung (Nachweis statt Annahme)

Testen Sie Failover vor dem Upgrade. Der Test muss realistisch sein: nicht nur „Link ziehen“, sondern auch prüfen, ob Traffic wirklich umschwenkt. Sinnvolle Schritte:

1. Baselines erfassen (Latenz, Paketverlust, Interface-Fehlerzähler, CPU/Memory der Switches).
2. Uplink A kurz deaktivieren, beobachten: bleiben Sessions stabil, konvergiert STP/Routing, steigt Paketverlust?
3. Uplink A wieder aktivieren, gleiche Beobachtung.
4. Gleiches für Uplink B.

Wenn Failover schon im Normalbetrieb nicht sauber ist, wird ein Firmware-Upgrade das Problem nicht lösen – es macht es nur sichtbar.

Monitoring- und Logging-Readiness

Für ein Upgrade ohne Downtime brauchen Sie „Augen und Ohren“: SNMP/Streaming-Telemetrie, Syslog, ggf. Interface-Error-Tracking. Achten Sie auf Counter, die bei Upgrades auffällig sind: CRC/Alignment Errors, Input Drops, STP TCNs (Topology Change Notifications), LACP-Flaps, BGP Neighbor Down/Up.

Umsetzung im Betrieb: Stufenplan inklusive Pre- und Post-Checks

Im Folgenden ein herstellerneutraler Stufenplan. Nutzen Sie ihn als Vorlage für Ihr Runbook; ergänzen Sie die konkreten CLI-Kommandos Ihrer Plattform.

Schritt 1: Pre-Checks direkt vor dem Change

• Change-Freeze für parallele Änderungen (Firewall, Routing, VLAN, Storage), um Effekte zu trennen.
• Konfigurationsbackup (automatisiert + manuell geprüft, dass es lesbar ist).
• Management-Zugriff testen: OOB erreichbar, Login ok, Privileged Mode ok.
• Gesundheitscheck: keine flappenden Links, keine hohen Error-Raten, keine instabilen Routing-Neighbor.

Schritt 2: Image-Handling und Integrität

Laden Sie Images nicht „irgendwoher“ auf den Switch. Nutzen Sie eine kontrollierte Quelle (internes Repo, signierte Vendor-Downloads) und prüfen Sie Integrität (Hash) und Speicherplatz. Als Beispiel für eine Hash-Prüfung auf einem Admin-Host:

# Beispiel: SHA256-Hash einer Firmware-Datei prüfen
sha256sum switch-firmware.bin
# Erwarteten Hash aus Herstellerquelle/Release-Notes gegenprüfen

Warum das wichtig ist: beschädigte Images führen zu Boot-Loops oder merkwürdigen Laufzeitfehlern, die sich erst nach dem Reboot zeigen. Hash-Prüfung ist ein einfacher, günstiger Schutz.

Schritt 3: Rolling Upgrade bei Paaren (MLAG/vPC) – Prinzip

Bei einem Switch-Paar ist das Prinzip immer ähnlich, egal wie es heißt: Sie halten einen Knoten im Dienst, während der andere upgradet und neu startet. Entscheidend sind drei Kontrollen:

• Peer-Link/Interconnect stabil: Der verbleibende Knoten muss den Status des Paars korrekt halten.
• Downstream-LACP stabil: Server/Access müssen ihre Bündel weiterführen.
• Gateway/Anycast stabil: Wenn Sie Anycast-Gateways nutzen, muss das Failover sauber sein.

Praktisch heißt das: Upgrade Knoten A, warten bis er vollständig wieder im Cluster ist, State synchron, dann erst Knoten B.

Schritt 4: Upgrade bei Stacks – Besonderheiten

Bei Stacking teilen sich die Mitglieder oft eine Control Plane. Manche Plattformen erlauben „rolling“, andere rebooten den Stack als Einheit. Prüfen Sie daher vorab:

• Ist ein hitless/rolling Upgrade für Ihr Stack-Modell und Ihre Version überhaupt unterstützt?
• Ist die Stack-Topologie redundant (Ring statt Line), damit ein Member-Reboot nicht den Stack trennt?
• Welche Rolle hat der Master (Active) und wie erfolgt ein Switchover?

Wenn Rolling nicht unterstützt wird, ist „ohne Downtime“ nur erreichbar, wenn Endgeräte außerhalb des Stacks redundant angebunden sind (z. B. Dual-Homing zu zwei separaten Stacks) – sonst gibt es eine spürbare Unterbrechung.

Schritt 5: Post-Checks – nicht nur „Ping geht“

Viele Teams beenden einen Change nach einem erfolgreichen Login. Für Stabilität brauchen Sie mehr:

• Port-Channel/LACP: alle Member up, kein „suspended“, kein ungewöhnliches Rebalancing.
• STP: Root-Bridge wie geplant, keine unerwarteten Topology-Changes, keine Ports in falschem State.
• Routing (falls L3): Nachbarn up, Routen vollständig, ECMP aktiv, keine Flaps.
• Interface-Fehler: CRC/Input Errors/Drops nicht ansteigend.
• Management: SNMP/Telemetry liefert, Syslog kommt an, NTP synchron, AAA ok.

Erst wenn diese Punkte stabil sind, ist der nächste Switch an der Reihe.

Rollback-Plan: Was im Ernstfall wirklich funktioniert

Ein Rollback ist kein „wir spielen das alte Image zurück“, sondern ein mechanischer Ablauf, der auch unter Stress funktioniert. Planen Sie Rollback so, dass er innerhalb Ihrer maximal tolerierten Störung (RTO im Betriebsjargon: Recovery Time Objective) ausführbar ist.

Rollback-Trigger definieren (vorher!)

Ohne klare Trigger diskutieren Teams zu lange. Typische Trigger, die einen sofortigen Rollback rechtfertigen:

• Core/Distribution: Routing-Instabilität (Neighbor-Flaps), die nicht binnen Minuten stabil wird
• MLAG/vPC: Dual-Active/Split-Brain-Indikatoren, Peer-Link instabil
• Massive Interface-Errors nach Upgrade (CRC/Drops steigen steil)
• Management-Loss: kein Zugriff über OOB und Inband, nur noch Remote Hands
• Unerwartete Inkompatibilität: Optics/PoE/802.1X brechen breitflächig

Rollback-Mechaniken: Image, Konfiguration, Boot-Variablen

In der Praxis gibt es drei Rollback-Ebenen:

1. Boot auf Secondary/Backup-Image: Viele Switches können ein zweites Image halten. Das ist der schnellste Weg, wenn das neue Image grundsätzlich das Problem ist.
2. Downgrade-Install: Rückinstallation der vorherigen Version. Achtung: Manche Plattformen erlauben kein direktes Downgrade über bestimmte Major-Releases.
3. Konfigurations-Rollback: Wenn das Image ok ist, aber Feature-Defaults oder Parser-Änderungen die Konfiguration anders interpretieren, brauchen Sie ein geprüftes Config-Backup und ggf. Anpassungen.

Planen Sie explizit, welche Ebene Sie zuerst ziehen. Und: Halten Sie die alte Firmware lokal verfügbar (Repo + erreichbarer Transferweg), nicht nur „im Internet“.

Rollback-Test im Canary ist Pflicht

Der häufigste Rollback-Fehler: Niemand hat ihn geübt. Im Canary-Setup sollten Sie deshalb mindestens einmal den „Boot auf altes Image“ und die Wiederherstellung eines Config-Backups durchspielen. Ziel: wissen, wie lange es dauert, und welche Zwischenzustände kritisch sind (z. B. temporär fehlende MLAG-Synchronisation).

Troubleshooting während und nach dem Upgrade: schnelle Diagnosepfade

Wenn nach dem Upgrade etwas „komisch“ ist, hilft ein kurzer, standardisierter Diagnosepfad, statt hektisch in alle Richtungen zu klicken.

Symptom: Endgeräte verlieren kurz die Verbindung

• Prüfen: LACP/Port-Channel Flaps? STP Topology Changes? Link-Events auf Uplinks?
• Warum es passiert: ein Member-Link rebootet, LACP neu verhandelt, STP recalculates. Wenn Edge/PortFast falsch ist, dauert’s länger.
• Gegenmaßnahme: STP-Edge korrekt setzen, LACP-Parameter konsistent, redundante Pfade validieren.

Symptom: Nachbarn (OSPF/BGP) flappen, obwohl Links up sind

• Prüfen: CPU/Memory-Spikes nach Boot, Timer/Keepalive, MTU, ACLs/CoPP (Control Plane Policing).
• Warum es passiert: Control Plane braucht nach Upgrade länger; neue Defaults für CoPP oder Routing-Policies greifen.
• Gegenmaßnahme: Stabilität abwarten (definierte Zeit), dann Rollback-Trigger prüfen; Policies vergleichen.

Symptom: Einzelne VLANs/Services „verschwinden“

• Prüfen: Trunk-Allowed-VLAN-Listen, native VLAN, VLAN-Datenbank, VTP/EVPN-Signaling je nach Design.
• Warum es passiert: Parser-Änderungen, neue Standard-Handling für untagged Frames, falsche Template-Übernahme.
• Gegenmaßnahme: Konfigurationsdiff gegen Backup, gezieltes Re-Apply kritischer Abschnitte.

Automatisierung und Dokumentation: weniger Tippfehler, bessere Nachvollziehbarkeit

Auch wenn Sie keine Vollautomation einsetzen: Ein Upgrade profitiert von standardisierten Abläufen. Zwei pragmatische Bausteine:

• Konfig-Backups und Diffs: Täglich automatisiert sichern und vor dem Change ein „Golden Backup“ erstellen. Diffs helfen, Nebeneffekte zu erkennen.
• Runbook als Checkliste: Schrittfolge mit Zeitstempeln, Verantwortlichen, Prüfpunkten, Rollback-Triggern. Das klingt bürokratisch, reduziert aber Fehler im Stress.

Wenn Sie bereits Netzwerkausrollungen automatisieren: Bauen Sie Pre-/Post-Checks als eigene Tasks ein (z. B. Interface-Status, Nachbarschaften, Error-Counter). Für viele Teams ist hier ein Einstieg über deklarative Automationsansätze sinnvoll. Passend dazu kann ein vertiefender Blick in den Leitfaden zur Netzwerkautomation mit Ansible für Switch-Config, Backups und Rollbacks helfen, um Upgrade-Runbooks reproduzierbar zu machen.

Fazit: Downtime-freie Firmware-Upgrades sind ein Architektur- und Prozess-Thema

Ein Switch-Firmware-Upgrade ohne Downtime gelingt, wenn Redundanz nicht nur vorhanden ist, sondern nachweislich funktioniert, und wenn Upgrade-Mechanismen (ISSU, Rolling, MLAG/vPC) zu Ihrer Topologie passen. Entscheidend sind saubere Vorab-Prüfungen, ein gestufter Rollout (Canary → Access → Distribution → Core) und ein Rollback-Plan, der geübt ist und klare Trigger hat. So wird das Firmware-Upgrade vom Risikoereignis zum kontrollierten Routine-Change – mit stabilen Services und nachvollziehbarem Betrieb.

Für dieses Thema sind auch Firmware-Update Switch und Stacking Upgrade wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.