Zwei Switches, ein logischer Switch
Wer im Access- oder Aggregation-Layer auf Redundanz setzt, kennt das Problem: Zwei Switches bedeuten meist auch zwei Managementpunkte, Spanning Tree zwischen ihnen und Uplinks, die man mühsam über Routing-Protokolle oder VRRP/HSRP absichern muss. Cisco StackWise Virtual (SVL) löst das, indem es zwei physische Chassis – meist aus der Catalyst-9000-Serie – zu einem einzigen logischen Switch verschmilzt. Nach außen erscheint das Paar als ein Gerät mit einer IP-Adresse, einer Konfiguration und einer MAC-Adresse-Tabelle. Intern bleibt es aber weiterhin ein Verbund aus zwei unabhängigen Hardware-Chassis, die über dedizierte Links synchron gehalten werden.
Das Grundprinzip: Einer der beiden Switches übernimmt die Rolle des Active, der andere die des Standby. Nur der Active betreibt die komplette Kontrollebene (Routing-Protokolle, STP, SNMP, CLI-Zugriff). Die Datenebene – also das eigentliche Weiterleiten von Paketen – läuft dagegen auf beiden Chassis parallel, denn beide haben ihre eigenen ASICs und Forwarding-Tabellen, die über die interne Verbindung synchron gehalten werden.
Hier lohnt sich der genaue Blick, denn StackWise Virtual braucht nicht nur eine, sondern typischerweise zwei unterschiedliche Arten von Links zwischen den Chassis.
Die Verbindungen im Detail
Hier lohnt sich der genaue Blick, denn StackWise Virtual braucht nicht nur eine, sondern typischerweise zwei unterschiedliche Arten von Links zwischen den Chassis.
Abb. 1: SVL- und DAD-Verbindungen zwischen den beiden Chassis
Der StackWise Virtual Link (SVL)
Der SVL ist das Rückgrat der Lösung. Über ihn laufen drei Dinge gleichzeitig:
- die interne Steuerungskommunikation zwischen den beiden Chassis (Zustand, Konfigurationssynchronisation, Heartbeats)
- die Synchronisation der Forwarding-Tabellen, damit beide Chassis wissen, wie sie Pakete weiterleiten müssen
- produktiver Datenverkehr, der zwischen den Chassis wechseln muss, etwa wenn ein Endgerät an Chassis 1 mit einem Server sprechen will, dessen Port an Chassis 2 hängt
Technisch gesehen kann der SVL aus mehreren physischen Ports bestehen, die zu einem logischen Link gebündelt werden. Cisco empfiehlt aus Redundanzgründen mindestens zwei physische Verbindungen auf unterschiedlichen Modulen oder ASICs, damit ein einzelner Hardwaredefekt den SVL nicht komplett lahmlegt. Dabei gelten ein paar feste Regeln, die in der Praxis öfter zu Stolperfallen werden, als man denkt: Alle Ports, die für einen SVL genutzt werden, müssen dieselbe Geschwindigkeit haben – eine Mischung aus 10G- und 40G-Ports im selben Link ist nicht zulässig. Außerdem werden für SVL- und Dual-Active-Detection-Links ausschließlich Cisco-eigene Transceiver-Module unterstützt, Drittanbieter-Optiken fallen hier raus.
Intern reserviert StackWise Virtual außerdem eine feste VLAN-ID für die eigene Steuerungskommunikation: Die gesamte Inter-Chassis-Systemkommunikation zwischen den Stack-Mitgliedern läuft über die reservierte VLAN-ID 4094 aus dem globalen VLAN-Bereich, weshalb diese VLAN-ID im restlichen Netzwerk nicht verwendet werden darf. Das ist einer der klassischen Fehler bei der Migration eines bestehenden Netzes auf SVL – wenn VLAN 4094 bereits anderweitig belegt ist, kollidiert das mit der internen Steuerungsebene.
Der Dual-Active-Detection-Link (DAD)
Der zweite, oft unterschätzte Baustein ist der DAD-Link. Er ist bewusst getrennt vom SVL aufgebaut und hat nur eine Aufgabe: erkennen, ob es zu einem sogenannten Split-Brain gekommen ist – also dem Zustand, in dem beide Chassis glauben, sie seien der Active.
Warum ist das überhaupt möglich? Wenn der Standby-Switch einen vollständigen Ausfall des SVL feststellt, geht er davon aus, dass der Active-Switch ausgefallen ist, und übernimmt selbst die Active-Rolle. Ist der ursprüngliche Active-Switch aber weiterhin funktionsfähig, sind beide Switches gleichzeitig aktiv. Das Problem dabei: Beide Switches nutzen dann dieselben IP-Adressen, SSH-Keys und STP-Bridge-IDs, was erhebliche Instabilität im Netzwerk verursachen kann.
Genau dafür gibt es den DAD-Link als unabhängigen, zusätzlichen Kommunikationsweg – er läuft nicht über dieselbe Hardware wie der SVL, damit ein SVL-Totalausfall nicht automatisch auch die Split-Brain-Erkennung lahmlegt. Er kann entweder als direkte Punkt-zu-Punkt-Verbindung zwischen den beiden Chassis oder über ein drittes Gerät (Fast-Hello-Mechanismus) realisiert werden. Praktisch reicht dafür bandbreitentechnisch oft schon ein 1G-Port, da nur kleine Hello-Pakete ausgetauscht werden – wie schnell die Split-Brain-Erkennung reagieren soll, bestimmt aber, wie man diesen Link dimensioniert.
Erkennt das System tatsächlich einen Dual-Active-Zustand, greift ein klar definierter Mechanismus: Der Active-Switch, der die Dual-Active-Situation erkennt, fährt alle seine Nicht-SVL- und Nicht-DAD-Schnittstellen herunter, um sich selbst aus dem Netzwerk zu nehmen, und wartet anschließend im Recovery-Modus, bis der SVL wiederhergestellt ist. Erst nach der physischen Reparatur der SVL-Verbindung lädt der betroffene Switch automatisch neu und reiht sich wieder als Standby ein.
Kann man einen Switch im laufenden Betrieb abschalten?
Das ist die Frage, die StackWise Virtual in der Praxis so attraktiv macht – und die Antwort ist differenziert, je nachdem, ob es sich um eine geplante Wartung oder einen ungeplanten Ausfall handelt.
Ungeplanter Ausfall: Fällt der Active-Switch unerwartet aus (Stromausfall, Hardwaredefekt), übernimmt der Standby automatisch die Active-Rolle. Da beide Chassis ihre Forwarding-Tabellen laufend synchron halten, ist dieser Wechsel aus Sicht der Datenebene sehr schnell – der neue Active muss keine komplette Netzwerkkonvergenz mehr durchlaufen, wie es bei zwei unabhängigen Switches mit STP oder Routing-Protokollen der Fall wäre. Wichtig für die Praxis: Downstream-Geräte sollten über Multichassis-EtherChannel (MEC) an beide Chassis angeschlossen sein. Nur dann bleiben ihre Uplinks beim Ausfall eines Chassis tatsächlich aktiv, weil der EtherChannel einfach mit den verbliebenen Links weiterläuft, statt erst neu konvergieren zu müssen.
Geplante Wartung, z. B. ein Software-Update: Hier kommt In-Service Software Upgrade (ISSU) ins Spiel. ISSU ist auf allen Catalyst-3850- und Catalyst-9000-Switches unterstützt, die StackWise Virtual beherrschen, ebenso auf eigenständigen Catalyst-9400/9600-Chassis mit doppelten Supervisoren. Der Ablauf: Zunächst wird nur der Standby-Switch mit der neuen Softwareversion neu gestartet, während der Active-Switch den gesamten Netzwerkverkehr weiter bedient. Ist der Standby wieder online und synchron, wird ein kontrollierter Switchover ausgelöst – der bisherige Standby übernimmt die Active-Rolle, der ehemalige Active lädt anschließend selbst neu und übernimmt die neue Software. Am Ende laufen beide Chassis auf demselben Stand, ohne dass es eine durchgehende Unterbrechung für angeschlossene Clients gab. Ein wichtiges Detail dabei: ISSU funktioniert nur, wenn beide Switches im Install-Modus gebootet sind – im Bundle-Modus wird der Vorgang verweigert. Das ist einer der häufigsten Gründe, warum ein geplantes ISSU in der Praxis scheitert, bevor es überhaupt beginnt.
Auch ganz ohne ISSU lässt sich einer der beiden Switches gezielt aus dem Betrieb nehmen, etwa für einen Hardwaretausch: Ein manueller Reload oder das Abschalten des Standby-Chassis unterbricht den Betrieb nicht, weil der Active ja ohnehin die gesamte Kontrollebene trägt und über MEC weiterhin volle Konnektivität zu den angeschlossenen Geräten hat. Schaltet man dagegen den Active ab, springt der Standby ein – funktional identisch zum ungeplanten Failover-Fall oben, nur eben bewusst herbeigeführt.
Stolpersteine, die es zu vermeiden gilt
Wie oben beschrieben, sind die beiden Switches über SVL und DAD eng miteinander verzahnt. Wichtig zu wissen: Diese Verbindungen sollten niemals einfach unkontrolliert getrennt werden. Reißt man beide Link-Typen gleichzeitig ab, kann es passieren, dass einer der Switches – oder sogar beide – in den Recovery-Modus fallen und dabei sämtliche Switchports heruntergefahren werden. Das Ergebnis ist dann kein sanfter Failover, sondern ein Totalausfall.
Muss tatsächlich einmal die physische Verbindung zwischen beiden Chassis vollständig getrennt werden, etwa weil einer der Switches gewartet oder an einen anderen Standort versetzt werden soll, gilt eine klare Reihenfolge: Der betroffene Switch muss zunächst komplett stromlos gemacht werden – erst danach dürfen die Kabel gezogen werden, niemals umgekehrt.
Vor einem solchen Eingriff lohnt sich ein Blick auf den aktuellen Zustand des Verbunds, um sicherzustellen, dass beide Chassis synchron sind und welche Rolle sie gerade einnehmen:
- show stackwise-virtual – zeigt, ob StackWise Virtual aktiviert ist, sowie die Domain-Nummer und die zugewiesenen Ports.
- show switch – zeigt die Rollen (Active und Standby) beider physischer Chassis im Verbund.
- show stackwise-virtual link – zeigt Details und Status des SVL an.
- show stackwise-virtual dual-active-detection – zeigt Informationen zur Erkennung eines aktivierten Dual-Active-Zustands.
Ein Wort zur Fehlertoleranz des Designs
Was StackWise Virtual von einer klassischen Lösung mit zwei unabhängigen Switches und einem First-Hop-Redundanzprotokoll unterscheidet, ist die Geschwindigkeit und Sauberkeit des Übergangs: Es gibt keinen STP-Reconvergence-Prozess, keine ARP-Neuermittlung, keine Neuverteilung von HSRP-Prioritäten – aus Sicht des restlichen Netzwerks bleibt es die ganze Zeit derselbe logische Switch. Der Preis dafür ist Komplexität an anderer Stelle: SVL und DAD müssen sauber getrennt geplant, dimensioniert und verkabelt werden, und ein Fehler bei der VLAN-4094-Reservierung oder bei der Transceiver-Wahl fällt einem oft erst auf, wenn es schon zu spät ist.
Quellenangaben:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-17/configuration_guide/ha/b_1717_ha_9500_cg/configuring_cisco_stackwise_virtual.html
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-9/configuration_guide/ha/b_179_ha_9500_cg/configuring_cisco_stackwise_virtual.html
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-15/configuration_guide/ha/b_1715_ha_9500_cg/configuring_cisco_stackwise_virtual.html
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9400/software/release/17-8/configuration_guide/ha/b_178_ha_9400_cg/configuring_cisco_stackwise_virtual.html
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9600/software/release/17-15/configuration_guide/ha/b_1715_ha_9600_cg/configuring_cisco_stackwise_virtual.html
https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/ha/c9610/svl-configuration-guide/configuring_cisco_stackwise_virtual.html
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9500-series-switches/214406-in-service-software-upgrade-issu-on-ca.html
https://community.cisco.com/t5/switching/catalyst-9500-dad/td-p/4786426
https://community.cisco.com/t5/switching/9500-stackwise-virtual-reload-issue/m-p/4089424
Schreibe einen Kommentar