Zum Inhalt springen
Avanet

Sophos Switch als Access Layer für XGS HA planen

Sophos Switches können die Access Layer vor einem Sophos-Firewall-HA-Paar bilden. Die sichere Grundidee ist einfach: Der Dedicated HA Link verbindet die beiden XGS Firewalls direkt und bleibt von allen produktiven Switchpfaden getrennt. LAN, DMZ und gegebenenfalls WAN werden dagegen so auf zwei Switches verteilt, dass der Ausfall eines Switches nicht beide Firewall-Nodes gleichzeitig vom selben Netz trennt.

Dieses Runbook behandelt die Switch- und Verkabelungsseite. Die eigentliche Wahl zwischen Active-Passive und Active-Active sowie die vollständige Firewall-Konfiguration erklärt Sophos Firewall High Availability einrichten.

Wichtig: Zwei Firewalls allein beseitigen keinen gemeinsamen Switch, kein gemeinsames Netzteil und keinen gemeinsamen Providerpfad als Ausfallursache. Ein HA-Status Active-Passive oder Active-Active bestätigt nur den Firewall-Cluster, nicht die Redundanz der gesamten Access Layer.

Zielbild und Sicherheitsgrenzen

Ein robustes Design trennt drei Verkehrsarten:

  1. Dedicated HA Link: direkte physische Verbindung zwischen Primary und Auxiliary. Darüber laufen Heartbeat sowie die Synchronisierung von Konfiguration, Status und Sitzungen. In Active-Active dient der Link ausserdem der HA-internen Verkehrsverteilung zwischen Primary und Auxiliary. Er ist trotzdem keine gewöhnliche LAN-, DMZ- oder WAN-Schnittstelle und wird in keines dieser produktiven Netze eingebunden.
  2. Produktive Pfade: Verbindungen von jedem Firewall-Node zu LAN, DMZ und WAN. Beide Nodes müssen nach einem Rollenwechsel dieselben produktiven Netze erreichen können.
  3. Managementpfade: Zugriff auf Firewalls und Switches für Abnahme, Fehlersuche und Rückbau. Mindestens ein unabhängiger Zugang darf nicht von genau dem Link abhängen, der gerade geändert oder getestet wird.

Die von Sophos dokumentierte Referenz verwendet zwei CS210-48FP für LAN und DMZ. Jeder Firewall-Node ist mit einem der beiden Switches verbunden; zwischen den Switches transportiert ein direkter Port die LAN- und DMZ-VLANs Tagged. Ein separater CS110-24FP führt die WAN-Seite beider Firewalls und den Internetanschluss in einem Untagged VLAN. Der Dedicated HA Link der Firewalls ist auch in diesem Beispiel direkt verbunden.

Dieses Beispiel ist kein allgemeiner Portplan. Seine Portnummern und VLAN-IDs dienen nur dazu, die Rollen zu verstehen:

ZweckReferenzwertBedeutung
LANVLAN 100Firewall-, LAN- und Switch-Interlink-Ports
DMZVLAN 200Firewall-, DMZ- und Switch-Interlink-Ports
WANVLAN 300Beide Firewall-WAN-Ports und Internetübergabe
Switch-InterlinkPort 52VLAN 100 und 200 Tagged
Dedicated HA LinkFirewall-Port 7Direkte Verbindung, nicht über die Switches

Die eigenen VLAN-IDs, Ports und Interface-Namen werden aus dem bestehenden Netzplan übernommen. Man kopiert die Referenzwerte nicht in ein Produktivnetz, in dem sie bereits eine andere Bedeutung haben.

Was das Referenzdesign nicht automatisch redundant macht

Der einzelne WAN-Switch der Referenz bleibt eine gemeinsame Ausfallzone. Fällt er aus, verlieren beide Firewall-Nodes diesen WAN-Pfad. Soll auch die WAN-Switching-Schicht einen einzelnen Geräteausfall überstehen, braucht sie ein separat geprüftes Dual-Switch- und Providerdesign; XGS HA erzeugt diese Redundanz nicht von selbst.

Auch zwei nebeneinander montierte Switches sind noch keine getrennten Ausfallzonen. Für eine belastbare Trennung prüft man mindestens:

  • getrennte Stromversorgung beziehungsweise getrennte abgesicherte Strompfade;
  • getrennte Switchhardware und, soweit möglich, getrennte Rack- oder Patchpfade;
  • einen Firewall-Node pro Switch statt beide Nodes am selben Access Switch;
  • getrennte Kabelwege ohne gemeinsames Patch- oder Transceiver-Risiko;
  • Erreichbarkeit der produktiven Netze über jeden Switch einzeln;
  • Monitoring für beide Switches und beide Firewallpfade;
  • dokumentierte Zuständigkeit für Switch-, Firewall- und Providerfehler.

Diese Zuordnung wird nicht nur im Netzplan festgehalten, sondern als Teil der Sollmatrix bis in Test und Rückbau weitergeführt. So bleibt sichtbar, welche Strom-, Rack-, Patch-, Switch- und Providerabhängigkeit ein konkreter Pfad tatsächlich besitzt.

VLAN, LAG und STP gemeinsam entwerfen

Die Layer-2-Topologie wird vor dem Verkabeln vollständig festgelegt. Für jedes Netz enthält der Plan VLAN-ID, Tagged-/Untagged-Rolle, PVID, beteiligte Firewallports, Switchports und den erwarteten Pfad nach einem Ausfall. Die Umsetzung von Tagged, Untagged und PVID steht in Sophos Switch VLANs sicher konfigurieren.

VLANs über beide Switches konsistent halten

Im Sophos-Referenzaufbau sind die Firewall- und Netzanschlüsse für LAN und DMZ Untagged-Mitglieder ihres jeweiligen VLANs. Der Interlink zwischen den beiden CS210-Switches führt VLAN 100 und 200 Tagged. Die PVID der Untagged Ports entspricht dem jeweiligen VLAN; Sophos setzt im Beispiel Ingress filtering: On und Accept type: All.

Für das eigene Design gelten daraus folgende Prüfregeln:

  • Ein VLAN muss an jedem beteiligten Linkende dieselbe VLAN-ID haben.
  • Auf dem Interlink werden nur die VLANs Tagged zugelassen, die tatsächlich beide Switches erreichen müssen.
  • Untagged VLAN und PVID eines Access-Ports müssen zusammenpassen.
  • Der Dedicated HA Link wird in keines dieser produktiven VLANs aufgenommen.
  • Management-VLAN und Rückweg bleiben während der Umstellung erreichbar.
  • Ingress Filtering wird erst verschärft, nachdem VLAN-Mitgliedschaft und PVID nachgewiesen sind.

Die Referenz ist portbasiert und Untagged an den Firewallinterfaces. Nutzt die eigene Firewall stattdessen VLAN-Subinterfaces oder Trunks, darf man die Untagged-/PVID-Werte des Beispiels nicht übernehmen. Dann muss der Tagged-Pfad an Firewall, Switch und Interlink durchgängig zum eigenen Interface-Design passen.

LAG nicht mit Chassis-Redundanz verwechseln

Ein LAG bündelt mehrere Links zu einer logischen Gegenstelle. Es erhöht je nach Verkehrsverteilung Kapazität und kann den Ausfall eines Mitglieds abfangen. Es beweist aber nicht, dass ein kompletter Switch ausfallen darf.

Die beiden freigegebenen Sophos-Quellen dokumentieren für dieses XGS-HA-Beispiel kein Multi-Chassis-LAG über zwei unabhängige Sophos Switches. Deshalb wird ein Firewall-LAG nicht einfach mit je einem Mitglied an Switch A und Switch B verteilt. Ein solcher Aufbau ist nur zulässig, wenn die gesamte Switchlösung gegenüber der Firewall ausdrücklich als eine unterstützte logische LAG-Gegenstelle arbeitet und das konkrete Design separat belegt und getestet ist.

Ohne diesen Nachweis sind getrennte Firewallinterfaces zu getrennten Switches die sichere Planungsgrenze. LACP, statische LAGs, Mitgliedsaktivierung und Rückbau behandelt Sophos Switch Ports, LAG und Spanning Tree sicher konfigurieren.

STP vor einem redundanten Layer-2-Pfad planen

Sobald zwischen zwei Switches oder über nachgelagerte LAN-/DMZ-Infrastruktur mehr als ein Layer-2-Pfad entstehen kann, muss die schleifenfreie Topologie vor dem Einstecken des zusätzlichen Kabels feststehen. RSTP eignet sich für eine einfache gemeinsame Topologie; MSTP nur für ein bewusst konsistentes Region- und Instanzdesign.

Vor dem Change kommen gewünschte Root Bridge und Bridge-Prioritäten, weiterleitende beziehungsweise erwartbar blockierende Ports und das Verhalten bei Ausfall und Wiederkehr des Interlinks in die Sollmatrix. Bei MSTP gehört auch die VLAN-Zuordnung zur jeweiligen Instanz hinein. Edge-Ports bleiben echten Endgeräten vorbehalten, nicht Firewall-, Switch- oder unbekannten Bridge-Verbindungen. Für eine Fehlkonvergenz wird ein unabhängiger Managementzugang festgelegt.

Loopback Detection kann ergänzend helfen, ersetzt STP aber nicht. Ein blockierender STP-Port ist bei einem geplanten redundanten Pfad nicht automatisch ein Fehler.

Change vorbereiten

Vor der ersten Änderung wird eine Sollmatrix für beide Firewall-Nodes und beide Switches erstellt. Sie ist die verbindliche Arbeitsunterlage für Aufbau, Tests, Abnahme und Rückbau. Das folgende kompakte Beispiel zeigt die Struktur. XGS-A, SW-A, Portnummern und VLANs sind realistische Beispielwerte, keine Produktvorgaben; abweichende Werte werden aus dem eigenen Netz- und Patchplan übernommen. Angaben in eckigen Klammern sind noch auszufüllen und müssen vor der Freigabe durch konkrete Umgebungswerte ersetzt werden.

Sollmatrix CHG-[Nummer] — Beispielstand vor dem Change
HA: Active-Passive | XGS-A = Primary/Active | XGS-B = Auxiliary/Passive | synchron
Dedicated HA: XGS-A Port7 <-> XGS-B Port7 | direkt | nicht Teil des Ausfalltests
Management/Rückweg: [separater Adminpfad] | Verantwortlich: [Name]
STP: RSTP | Root: SW-A [Priorität] | Secondary: SW-B [Priorität]
Backups/Vorzustand: [Ablage Switch/Firewall] | Patchplan: [Version] | Rückbau-Freigabe: [Name]

P1 LAN: XGS-A Port1 <-> SW-A 1/0/47 | VLAN 100 Untagged/PVID 100
        kein LAG | RSTP Forwarding, nicht Edge | Monitored Port: ja | Strompfad A
P2 LAN: XGS-B Port1 <-> SW-B 1/0/47 | VLAN 100 Untagged/PVID 100
        kein LAG | RSTP Forwarding, nicht Edge | Monitored Port: ja | Strompfad B
P3 Interlink: SW-A 1/0/52 <-> SW-B 1/0/52 | VLAN 100,200 Tagged
        PVID [gemäss lokalem Native-VLAN-Konzept] | kein LAG | RSTP Forwarding
[DMZ-, WAN- und LAG-Pfade nach demselben Muster ergänzen; bei LAG logische Gegenstelle
 und alle Member nennen. Gemeinsame WAN-/Provider-Ausfallzonen ausdrücklich markieren.]

T1 Monitored-Port-Failover: Voraussetzung XGS-A Primary/Active, XGS-B Auxiliary/Passive,
   beide synchron; exakt XGS-A Port1/P1 trennen.
   Erwartung/Pfad: XGS-A verarbeitet keinen Traffic mehr; XGS-B wird Active;
   LAN-Verkehr läuft über P2 und SW-B.
   Validierung: Status beider Nodes, Synchronisierung nach Wiederkehr, Switchports/VLAN-Pfad,
   Gateway + [internes Ziel] + [externer Pfad] + [kritische Anwendung], Zeitstempel.
   Abbruch: beide Nodes Active, Managementverlust oder Verkehrsausfall > [freigegebene Dauer].
   Rückweg: P1 wieder verbinden, Synchronisierung abwarten, Datenpfad erneut prüfen;
   bevorzugte Rollen erst danach kontrolliert wiederherstellen, kein unkontrollierter Failback.
T2 Switchausfall: [SW-A isolieren] | Erwartung/Pfad: Dienst über XGS-B/SW-B und P2
   Validierung: [dieselben fachlichen Tests] | Abbruch: [Kriterium]
   Rückweg: SW-A/Links einzeln herstellen, STP stabil und HA synchron abwarten.

Für weitere Netze werden P-Zeilen kopiert, für jeden freigegebenen Fehlerfall eine eigene T-Zeile. Damit stehen physische Gegenstelle, Zone, VLAN/PVID, Tagged-/Untagged-Rolle, LAG- und STP-Zustand, Monitored Port, HA-Rolle und aktueller Status nicht in getrennten Checklisten. Erwarteter Ausfallpfad, fachliche Validierung, Abbruch und Rückweg bleiben direkt mit dem getesteten Interface verbunden.

Vor dem Wartungsfenster müssen die in der Kopfzeile referenzierten Switch- und Firewallkonfigurationen, der wirksame Port-, VLAN-, LAG- und STP-Vorzustand sowie der Kabel- und Patchplan tatsächlich gesichert und über den angegebenen unabhängigen Administrationsweg erreichbar sein. Ein bloss eingetragener Ablageort genügt nicht.

Ein Switch-Backup ersetzt nicht die Dokumentation des wirksamen Layer-2-Zustands. Den Unterschied zwischen Fusion- und lokalem Backup erklärt Sophos Switch sichern und wiederherstellen.

Access Layer kontrolliert aufbauen

1. Switches ohne parallele Schleife vorbereiten

  1. Die P-Zeilen der Sollmatrix nacheinander abarbeiten: VLANs, PVIDs und den geplanten Switch-Interlink zuerst konfigurieren und den Ist-Zustand direkt in derselben Zeile bestätigen.
  2. STP vor dem Aktivieren eines redundanten Layer-2-Pfads einschalten und Root Bridge sowie Portrollen prüfen.
  3. Zusätzliche Kabel noch getrennt lassen oder ihre Ports deaktiviert halten.
  4. Konfigurationsquelle und Konflikte zwischen Sophos Fusion und lokaler Switchkonfiguration klären.
  5. Managementzugriff nach jeder Änderung erneut testen.

Im lokalen Switch-Webinterface verwendet die Sophos-Referenz für VLANs:

Configure > VLAN settings > 802.1Q

PVID, Ingress filtering und Accept type werden dort unter PVID and ingress filter bearbeitet. Weitere UI-Schritte und ihre Sicherheitsgrenzen bleiben im verlinkten VLAN-Runbook, damit nicht zwei voneinander abweichende Anleitungen gepflegt werden.

2. Genau einen produktiven Pfad pro Netz aktivieren

Zuerst wird für LAN, DMZ und WAN jeweils nur der eindeutig geplante Einzelpfad aktiviert. Danach prüft man:

  • Linkzustand und vereinbarte Geschwindigkeit;
  • effektive VLAN-Mitgliedschaft und PVID;
  • Managementzugriff auf Switch und Firewall;
  • Erreichbarkeit des vorgesehenen Gateways;
  • erlaubten Testverkehr durch die aktuell aktive Firewall.

Erst wenn dieser Zustand stabil ist, wird ein zusätzlicher Switch-Interlink, LAG-Member oder zweiter Netzpfad einzeln aktiviert. Nach jedem Kabel werden STP-Rolle, LAG-Mitgliedschaft und Managementzugriff erneut geprüft.

Der Dedicated HA Link wird direkt zwischen denselben vorgesehenen Ports beider Firewalls verkabelt. Er wird nicht über den produktiven Switch-Interlink, ein LAN-/DMZ-/WAN-VLAN oder einen gemeinsamen Access Switch geführt. Damit bleibt ein Fehler in der produktiven Layer-2-Topologie vom Heartbeat-, Synchronisierungs- und HA-internen Verteilungspfad getrennt. In Active-Active kann dieser direkte Link auch Traffic zur Verarbeitung zwischen den Nodes verteilen; dadurch wird er nicht zu einem gewöhnlichen produktiven Netzanschluss.

Die Sophos-Referenz richtet die Firewall im Interactive mode ein: zuerst die Auxiliary, danach die Primary. Beide verwenden denselben Dedicated-HA-Link-Port und dieselbe Passphrase. Auf der Primary werden Cluster ID, Peer-Link-Adresse, Monitored Ports, Peer Administration und Keepalive-Werte festgelegt. Diese Firewallfelder werden nicht aus dem Referenzbeispiel blind übernommen; der vollständige Ablauf und die Voraussetzungen stehen im verlinkten Firewall-HA-Artikel.

4. Monitored Ports nach Fehlerdomäne wählen

Ein Monitored Port soll einen relevanten Pfadausfall erkennen. Welche Rollen- oder Statusänderung daraus folgt, hängt vom HA-Modus und davon ab, welcher Node beziehungsweise Pfad betroffen ist. Im Sophos-Beispiel überwacht die Primary ihre LAN- und DMZ-Ports. Für die eigene Umgebung werden nur dauerhaft angeschlossene, kritische Interfaces ausgewählt.

Nicht sinnvoll sind unbenutzte, nur zeitweise aktive oder absichtlich getrennte Ports. Sie würden einen unnötigen Failover auslösen. Der Dedicated HA Link und ein Monitored Port bleiben unterschiedliche Interfaces mit unterschiedlichen Aufgaben.

Abnahme und Ausfalltests

Die Tests finden in einem Wartungsfenster statt. Vor jedem Ausfalltest werden laufende produktive Änderungen gestoppt, aktuelle Rollen notiert und ein Verantwortlicher für den sofortigen Rückweg bestimmt. Es wird immer nur eine Fehlerdomäne gleichzeitig verändert.

Jeder Monitored-Port-Test folgt einer freigegebenen T-Zeile wie T1: HA-Modus, betroffener Node, konfigurierte Rolle, aktueller Active-/Passive-Status, exaktes Interface, Erwartung und Abbruchbedingung werden unmittelbar vor dem Trennen noch einmal bestätigt. Der normale Active-Passive-Failover-Test trennt gezielt ein überwachtes Interface des aktuell aktiven, Traffic verarbeitenden Nodes; der Peer muss den Traffic übernehmen. Für Active-Active oder einen Pfad des Auxiliary-Nodes wird eine eigene T-Zeile mit dem tatsächlich erwarteten Verhalten freigegeben, statt den Rollenwechsel aus T1 vorauszusetzen.

Grundzustand abnehmen

Vor einem Failover muss der Normalzustand eindeutig sein:

  • Beide Switches sind erreichbar und ihre erwarteten Ports sind stabil.
  • VLAN-Mitgliedschaften, PVIDs und Tagged Interlinks entsprechen der Sollmatrix.
  • LAGs enthalten ausschliesslich die geplanten Mitglieder.
  • Root Bridge, STP-Portrollen und Portzustände entsprechen dem Design.
  • Beide Firewalls zeigen den geplanten HA-Modus und einen synchronen Zustand.
  • Dedicated HA Link und alle ausgewählten Monitored Ports sind aktiv.
  • Testclients erreichen Gateway, ausdrücklich erlaubte interne Ziele und den vorgesehenen externen Pfad.
  • Peer-Administration beziehungsweise der unabhängige Managementzugang funktioniert.

Wartungs- und Fehlertests in sicherer Reihenfolge

  1. Ein LAG-Mitglied, falls vorhanden, kontrolliert trennen. Der logische Pfad muss über das verbleibende Mitglied funktionieren; danach das Mitglied wieder hinzufügen und seinen Beitritt prüfen.
  2. Switch-Interlink kontrolliert trennen. Nur durchführen, wenn der erwartete Datenpfad ohne ihn im Plan eindeutig beschrieben ist. Rollen, VLAN-Erreichbarkeit und STP-Zustand prüfen, dann den Link wiederherstellen und Rekonvergenz beobachten.
  3. Den in der Sollmatrix festgelegten überwachten Firewallpfad trennen. In Active-Passive wird dafür das exakte überwachte Interface des aktuell aktiven, Traffic verarbeitenden Nodes verwendet und geprüft, ob der Peer wie dokumentiert übernimmt. Active-Active- und Auxiliary-Pfad-Tests folgen nur ihrem separat dokumentierten Erwartungszustand. Bei einer Abweichung den Test abbrechen und den Pfad wiederherstellen. Danach Synchronisierung, Status beider Nodes und denselben Testverkehr prüfen; einen automatischen Failback nicht unkontrolliert ablaufen lassen.
  4. Einen Access Switch kontrolliert abschalten oder vollständig isolieren. Der andere Switch, der dazugehörige Firewall-Node und die vorgesehenen Netze müssen den im Design erwarteten Dienst liefern.
  5. Den bevorzugten Normalzustand kontrolliert wiederherstellen. Switch, Links und Firewallrollen dürfen erst nach stabiler Synchronisierung und überprüftem Datenpfad zurückgeführt werden.

Den Dedicated HA Link trennt man nicht als gewöhnlichen Verfügbarkeitstest im laufenden Produktivnetz. Sein Ausfall kann dazu führen, dass beide Firewalls den Peer nicht mehr sehen. Ein solcher Split-Brain-Test benötigt ein separates, ausdrücklich freigegebenes Verfahren mit isolierten produktiven Interfaces. Für die normale Abnahme genügt es, den Linkzustand, die HA-Synchronisierung und das dokumentierte Vorgehen für seinen Ausfall zu prüfen.

Ein Test gilt nicht allein deshalb als bestanden, weil ein Ping weiterläuft. Nach jedem Schritt werden zusätzlich Rollen, Synchronisierung, Switchportzustände, VLAN-Pfad und die für den Standort kritischen Anwendungen geprüft. Beobachtungen und Zeitstempel kommen ins Betriebsprotokoll; garantierte Umschaltzeiten werden ohne Messung nicht behauptet.

Fehler nach Symptom eingrenzen

HA ist grün, aber ein Netz ist nach dem Rollenwechsel nicht erreichbar

  • VLAN-ID und Tagged-/Untagged-Mitgliedschaft auf beiden Switches vergleichen.
  • PVID des betroffenen Untagged Ports prüfen.
  • Kontrollieren, ob das VLAN über den Interlink tatsächlich Tagged zugelassen ist.
  • Firewallport und physische Verkabelung gegen die Sollmatrix prüfen.
  • Bei einem LAG feststellen, ob alle Mitglieder zur richtigen logischen Gegenstelle führen.
  • STP-Portrolle prüfen; ein unerwartet blockierter oder deaktivierter Pfad kann die Erreichbarkeit verhindern.

Failover tritt unerwartet auf

  • Auf der Firewall prüfen, welcher Monitored Port den Zustand ausgelöst hat.
  • Link-Flaps, Transceiver, Kabel und Speed-/Duplexabgleich auf dem zugehörigen Switchport untersuchen.
  • Sicherstellen, dass kein optionaler oder absichtlich unverbundener Port überwacht wird.
  • LBD- und STP-Zustand prüfen, bevor ein Port wieder aktiviert wird.

Beide Firewalls sehen den Peer nicht mehr

Der Dedicated HA Link ist die erste Prüfgrenze. Keine produktiven Kabel wahllos umstecken und nicht beide Nodes gleichzeitig neu starten. Festlegen, welcher Node den Traffic weiterführen soll, den anderen kontrolliert vom Produktionsnetz trennen beziehungsweise herunterfahren und danach Kabel, Ports und Linkzustand des direkten HA-Links prüfen. Erst nach stabilem Peer-Kontakt und eindeutigen Rollen wird der zweite Node wieder vollständig eingebunden.

Nach Aktivierung des zweiten Pfads entstehen Paketverlust oder eine Schleife

  1. Den zuletzt aktivierten zusätzlichen Link kontrolliert trennen.
  2. Wieder einen eindeutigen Einzelpfad herstellen.
  3. STP Root Bridge, Portrollen und Portzustände beider Switches prüfen.
  4. Bei einem LAG Typ und Member Ports auf beiden Enden vergleichen.
  5. VLAN-Liste des Interlinks und eine mögliche unbeabsichtigte Untagged-Verbindung prüfen.
  6. Erst nach Korrektur genau einen zusätzlichen Link erneut aktivieren.

Switch ist nicht mehr administrierbar

Den vorbereiteten unabhängigen Managementzugang verwenden. Die letzte Änderung an Management-VLAN, PVID, Uplink, LAG oder STP anhand des Vorzustands zurücknehmen. Nicht vorsorglich beide Switches neu starten: Dadurch kann auch der noch funktionierende Datenpfad verloren gehen.

Rückbau

Ein Rückbau stellt den dokumentierten Vorzustand wieder her und beginnt an der zuletzt hinzugefügten Redundanz:

  1. Testverkehr stoppen und aktuellen HA-, Switch- und STP-Zustand sichern.
  2. Den zuletzt aktivierten zusätzlichen Link, LAG-Member oder Interlink kontrolliert trennen, bis wieder genau ein eindeutiger produktiver Pfad besteht.
  3. Firewallrollen nur dann zurückführen, wenn der vorgesehene Normalpfad stabil ist.
  4. LAG-, STP- und VLAN-Änderungen auf beiden Linkenden in umgekehrter Reihenfolge zurücknehmen.
  5. Die vorherigen Tagged-/Untagged-Mitgliedschaften und PVIDs aus der Sollmatrix wiederherstellen.
  6. Managementzugriff, HA-Synchronisierung und denselben funktionalen Test wie vor dem Change wiederholen.
  7. Den Dedicated HA Link unverändert direkt verbunden lassen, sofern nicht genau dieser Link nach einem eigenen freigegebenen Verfahren repariert wird.

Wenn der Vorzustand selbst nur einen gemeinsamen Switch oder einen einzelnen Uplink hatte, stellt der Rückbau bewusst auch dessen geringere Verfügbarkeit wieder her. Das wird im Changeabschluss als verbleibendes Risiko dokumentiert und nicht als vollständig redundanter Erfolg bezeichnet.

Betriebscheckliste

  • Jede P-Zeile der Sollmatrix enthält den bestätigten Ist-Zustand; Abweichungen sind behoben oder als verbleibendes Risiko freigegeben.
  • Jede T-Zeile enthält Ergebnis, Zeitstempel und Prüfer. Die Tests wurden einzeln ausgeführt, nicht als kombinierter Ausfall.
  • Dedicated HA Link, HA-Rollen, Synchronisierung, STP-Zustand und Managementzugang entsprechen wieder dem freigegebenen Normalzustand.
  • Switch- und Firewallkonfiguration, aktualisierter Patchplan sowie das Protokoll der fachlichen Tests sind am eingetragenen Ablageort gesichert.
  • Rückbauweg, Verantwortliche und verbleibende gemeinsame Strom-, Patch-, Rack-, WAN- oder Provider-Ausfallzonen sind im Changeabschluss festgehalten.