Können verschiedene Catalyst 9500 Modelle in einem StackWise Virtual Paar gemischt werden?

Nein. Die beiden Switches in einer StackWise Virtual Domain müssen die exakt gleiche Modellnummer (PID) haben, die gleiche IOS XE-Version und das gleiche Lizenzniveau (z. B. DNA Advantage) ausführen. Dies gewährleistet eine vollständige Feature- und Leistungs-Parität zwischen den Chassis.

Wie groß ist die maximale Distanz für einen StackWise Virtual Link (SVL)?

Die physische Distanz wird durch die verwendete Optik bestimmt (z. B. ermöglicht 100G-LR4 10 km). Die eigentliche Einschränkung ist jedoch die Latenz. SVL Control Plane-Protokolle sind für nahezu keine Latenz ausgelegt, und eine praktische, sichere Grenze liegt unter 5 Millisekunden. Es wird dringend empfohlen, beide Chassis innerhalb desselben Rechenzentrums oder Kommunikationsraums zu halten.

Wie handhabt StackWise Virtual Quality of Service (QoS)?

QoS-Markierungen (DSCP, CoS) bleiben erhalten, wenn Frames den SVL durchlaufen. Warteschlangen-, Policing- und Shaping-Richtlinien werden jedoch auf Basis pro Chassis angewendet. Das bedeutet, dass Datenverkehr, der in Switch 1 eingeht, den Ausgangswarteschlangenrichtlinien von Switch 1 unterliegt, selbst wenn sein endgültiges Ziel ein Port auf Switch 2 ist.

Wie wird die Lizenzierung für ein StackWise Virtual Paar gehandhabt?

Beide Switches müssen dasselbe Cisco DNA Subscription-Lizenzniveau (z. B. Essentials, Advantage oder Premier) haben. Ein einzelnes DNA Center kann das Paar als eine logische Einheit verwalten, aber die Hardware- und Software-Lizenzen werden pro Chassis erworben und angewendet.

Kann ich 40G- und 100G-Ports in denselben SVL bündeln?

Nein. Alle Mitglieds-Links innerhalb des als StackWise Virtual Link vorgesehenen Port-Channels müssen die gleiche Geschwindigkeit haben. Sie können 40G- und 100G-Schnittstellen nicht im selben Bundle mischen. Sie müssen eine Geschwindigkeit wählen und mehrere Schnittstellen dieser Geschwindigkeit für Kapazität und Redundanz bereitstellen.

Was passiert konkret aus Sicht des Sekundär-Switches in einem Dual-Active-Szenario?

Wenn der SVL ausfällt und der Fast-Hello-Link ebenfalls ausfällt, geht der Sekundär-Switch davon aus, dass der Primär-Switch ausgefallen ist und wird selbst aktiv. Wenn er jedoch dann einen ePAgP-Hello von einem nachgelagerten Switch erhält, der anzeigt, dass der ursprüngliche Primär-Switch *ebenfalls* aktiv ist, weiß er, dass eine Dual-Active-Bedingung vorliegt. Er versetzt sofort alle seine Front-Panel, nicht-SVL-Schnittstellen in einen error-disabled Zustand, um Schleifen zu verhindern und das Netzwerk zu schützen.

Ist eine direkte Glasfaserverbindung für den Fast-Hello-Link wirklich zwingend erforderlich?

Obwohl es möglicherweise über einen Zwischen-Switch funktionieren könnte, ist dies ein schwerwiegender Designverstoß. Der Zweck des Fast-Hello-Links ist es, eine einfache, Out-of-Band-Prüfung der Betriebsbereitschaft des Peers zu sein. Ihn über ein anderes Gerät laufen zu lassen, führt zu Shared Fate; wenn dieses Gerät ausfällt, kann dies eine falsche Dual-Active-Erkennung auslösen. Ein direktes DAC-Kabel oder eine einzelne Glasfaserleitung ist das einzig unterstützte und architektonisch sinnvolle Design.

Cisco StackWise Virtual Deep Dive: Campus Core Design für 2026

StackWise Virtual (SVL) ist der definitive Nachfolger des Virtual Switching Systems (VSS) für den Aufbau von resilienten, hochbandbreiten Core- und Distributions-Layern in Unternehmenscampus-Netzwerken. Während das Konzept, zwei Chassis zu einem einzigen logischen Switch zu paaren, nicht neu ist, erfordert die Implementierung von SVL auf moderner Catalyst 9500- und 9600-Serien-Hardware ein nuanciertes Verständnis ihrer zugrunde liegenden Mechaniken, insbesondere des StackWise Virtual Link (SVL), der Dual-Active Detection und der In-Service Software Upgrade (ISSU)-Prozesse. Eine erfolgreiche SVL-Bereitstellung geht über eine einfache "Plug-and-Play"-Mentalität hinaus und erfordert präzise Engineering-Entscheidungen, die erhebliche Auswirkungen auf die Fabric-Stabilität und -Leistung haben.

StackWise Virtual vs. VSS und Backplane Stacking

Es ist entscheidend, SVL von seinen Vorgängern und seinen Catalyst 9200/9300-Serien-Cousins abzugrenzen. VSS, erstmals auf der Catalyst 6500-Serie implementiert, erforderte identische Chassis, spezifische Supervisor-Module (wie das VS-S2T-10G) und nutzte die physischen Port-Channels als Virtual Switch Link (VSL). SVL auf der Catalyst 9500/9600 erbt dies philosophisch, implementiert es aber auf der modernen UADP ASIC-Architektur mit IOS XE.

Im Gegensatz dazu verwendet das traditionelle StackWise, wie es auf der Catalyst 9300-Serie mit StackWise-1T zu sehen ist, proprietäre Backplane-Kabel (z. B. STACK-T1), um mehrere Switches in einer Ringtopologie zu verbinden. Dies erzeugt einen einzigen logischen Switch mit einer einheitlichen Daten- und Steuerungsebene, der eine einzige IP-Adresse teilt. SVL erreicht das gleiche logische Ergebnis, verwendet aber Standard-10/25/40/100G-Ethernet-Schnittstellen für die Verbindung, bekannt als StackWise Virtual Link. Diese Unterscheidung ist entscheidend: SVL ist für Paare von Hochleistungs-Distributions-/Core-Switches, während StackWise für das Stacking mehrerer Access-Layer-Switches in einem Verteilerschrank ist.

Auswahl der Core-Hardware-Plattform: Catalyst 9500 vs. 9600

Die Wahl zwischen der Catalyst 9500-Serie mit fester Konfiguration und der modularen Catalyst 9600-Serie für ein SVL-Paar hängt vollständig von Portdichte, zukünftiger Skalierbarkeit und Budget ab. Beide basieren auf Ciscos UADP ASICs und gewährleisten Feature-Parität für zentrale Campus-Funktionen.

Catalyst 9500: Hochleistungs-Fixed-Core

Die Catalyst 9500-Serie, insbesondere die Hochleistungsmodelle, ist ideal für kompakte Core- oder Distributionsblöcke. Eine gängige Paarung sind zwei C9500-48Y4C-Switches, die 48 Ports 1/10/25G SFP28 und 4 Ports 40/100G QSFP bieten. Für höhere Leistungsanforderungen bietet der C9500-32C 32 Ports 40/100G QSFP28. Diese Plattformen, die auf UADP 3.0 laufen, stellen erhebliche TCAM- und Pufferressourcen bereit, die für die meisten Enterprise Core-Anforderungen geeignet sind. Ihr fester Charakter bedeutet, dass das, was Sie kaufen, das ist, was Sie bekommen; zukünftige Erweiterungen erfordern einen Chassis-Austausch, keine Hinzufügung von Line Cards.

Catalyst 9600: Modulare Skalierung für große Campusse

Für große Unternehmens- oder Universitäts-Campus ist das Catalyst 9606R-Chassis mit einem Paar C9600-SUP-1-Supervisoren die logische Wahl. Die Modularität ermöglicht eine Mischung aus Line Cards, wie der C9600-LC-48YL (48 Ports 1/10/25G) und der C9600-LC-24C (24 Ports 40/100G). Dies ermöglicht ein Pay-as-you-grow-Modell und die Möglichkeit, zukünftige Technologien wie 400G über eine neue Line Card anstatt eines vollständigen Systemaustauschs zu implementieren. Ein SVL-Paar von 9606R-Chassis bietet ultimative Ausfallsicherheit und Skalierbarkeit, das Tausende von Benutzern und Geräten unterstützen kann.

Dimensionierung des StackWise Virtual Link (SVL)

Der SVL ist die wichtigste Komponente des Designs. Er trägt die gesamte Control Plane-Kommunikation und jeglichen Datenverkehr, der zwischen den beiden Chassis übertragen werden muss (d. h. "Inter-Chassis-Verkehr"). Eine Unterdimensionierung des SVL entzieht der Fabric Bandbreite und kann zu unvorhersehbaren Leistungsproblemen führen, während eine Überdimensionierung teure Hochgeschwindigkeitsports verschwendet. Ein pragmatischer Ansatz zur Dimensionierung ist unerlässlich.

Betrachten Sie einen Distributionsblock, der auf einem SVL-Paar von C9500-32C-Switches basiert. Dieser Block bedient zehn Access-Layer-Stacks von Catalyst 9300s, jeder mit dualen 40G-Uplinks, die in einem Multi-chassis EtherChannel (MEC) zum SVL-Paar konfiguriert sind. Die gesamte Uplink-Kapazität beträgt 10 * (2 * 40 Gbit/s) = 800 Gbit/s. Eine gängige Faustregel ist, den SVL mit einer Kapazität von 25-50 % der gesamten angeschlossenen Uplink-Bandbreite zu dimensionieren, unter Annahme einer gleichmäßigen Verteilung der Traffic-Terminierung über beide Chassis.

Beispielrechnung:

Gesamte Uplink-Bandbreite: 800 Gbit/s
Ziel-SVL-Kapazität (30 % Regel): 800 Gbit/s * 0,30 = 240 Gbit/s
Implementierung: Ein Drei-Port-Port-Channel von 100G-Schnittstellen (3 x 100 Gbit/s = 300 Gbit/s).

Auf jedem C9500-32C würden Sie die Ports HundredGigE1/0/30, 1/0/31 und 1/0/32 für den SVL bereitstellen. Dies bietet 300 Gbit/s Bandbreite, übertrifft das Ziel von 240 Gbit/s und bietet N+1 Redundanz; der Ausfall eines einzelnen Links lässt immer noch 200 Gbit/s Kapazität. Missionskritische Daten- und Steuerdaten über einen einzelnen Link zu führen, selbst einen 100G-Link, ist ein Design-Antimuster. Verwenden Sie immer einen Port-Channel mit mindestens zwei Mitgliedern für den SVL.

Dual-Active Detection: Das ultimative Sicherheitsnetz

Ein Dual-Active-Szenario ist der katastrophalste Fehlerzustand für ein virtualisiertes Switching-Paar. Es tritt auf, wenn der SVL ausfällt und beide Switches glauben, der aktive Chassis zu sein. Dies führt zu IP-Adressduplizierung, MAC-Adresstabellen-Instabilität und netzwerkweiten Schleifen. SVL verwendet einen mehrschichtigen Erkennungsmechanismus, eine Weiterentwicklung von VSS, um dies zu verhindern.

SVL Keepalives: Die primäre Methode. Cisco-proprietäre Header im SVL-Verkehr enthalten Keepalives. Wenn diese für den konfigurierten Zeitraum (Standardwerte sind aggressiv, im Bereich von Hunderten von Millisekunden) nicht empfangen werden, initiiert der sekundäre Switch eine Failover-Sequenz.
Fast-Hello: Dies ist ein obligatorischer, Out-of-Band-Link. Er umfasst eine direkte Layer-2-Verbindung (z. B. einen einzelnen 1G SFP-Port an jedem Switch, wie Gi1/0/1 <--> Gi1/0/1), die dem Senden von UDP-Keepalive-Paketen gewidmet ist. Wenn der SVL ausfällt, aber die Fast-Hello-Keepalives weiterhin empfangen werden, weiß der sekundäre Switch, dass der Primäre noch lebt und geht sofort in den Recovery-Modus, wobei er alle seine Front-Panel-Ports (außer dem SVL) herunterfährt, um Schleifen zu verhindern.
Enhanced PAgP (ePAgP) / MEC: Dies ist der letzte Tie-Breaker und eine deutliche Verbesserung gegenüber VSS. Wenn sowohl der SVL als auch die Fast-Hello-Links gleichzeitig ausfallen (z. B. ein Mehrkartenfehler oder ein Ausfall eines Zwischen-Switches), kann das SVL-Paar einen Downstream-Switch zur Kommunikation nutzen. Ein spezieller PAgP TLV auf dem Multi-chassis EtherChannel (MEC) informiert jedes SVL-Mitglied über die Existenz des anderen. Wenn ein Switch sich selbst und seinen Peer in den PAgP-Nachrichten eines Downstream-Geräts sieht, den Peer aber nicht über den SVL erreichen kann, weiß er, dass eine Dual-Active-Bedingung vorliegt.

Häufiger Fehler: Der gemeinsam genutzte Fast-Hello Link

Ein häufiger Fehler ist, den Fast-Hello-Link über ein anderes Netzwerkgerät, wie einen Management-Switch, zu führen, um Glasfaser zu sparen. Dies ist ein kritischer Designfehler. Wenn dieser Vermittlungs-Switch neu startet oder ausfällt, verlieren beide SVL-Mitglieder die Fast-Hello-Konnektivität, was einen Fehlalarm auslöst. Der Fast-Hello-Link MUSS eine direkte, dedizierte Verbindung zwischen den beiden SVL-Chassis sein – idealerweise eine einzelne Glasfaserleitung oder ein DAC-Kabel, wenn sie sich am selben Standort befinden. Hier zu sparen, untergräbt das gesamte Hochverfügbarkeitsdesign.

Wann StackWise Virtual NICHT verwendet werden sollte

SVL ist ein leistungsstarkes Tool, aber keine Universallösung für alle Campus-Designs. Die Anwendung im falschen Kontext schafft mehr Probleme als sie löst.

EVPN-VXLAN Fabrics: Für fortschrittliche Campus-Fabrics, die ein EVPN-VXLAN-Overlay mit einer BGP Control Plane verwenden, ist SVL das falsche Modell. Eine echte Spine-Leaf (CLOS)-Architektur basiert auf individuell gerouteten L3-Links zwischen Leaf- und Spine-Switches. Jeder Switch ist eine unabhängige Routing-Entität. SVL hingegen schafft einen großen L2-Domäne mit einem einzigen Kontrollpunkt, was den Prinzipien einer gerouteten Fabric widerspricht.
Geografisch verteilte Cores: Der Versuch, ein SVL-Paar zwischen verschiedenen Gebäuden oder Rechenzentren über DWDM oder Dark Fiber zu "strecken", ist gefährlich. Das SVL-Protokoll ist extrem empfindlich gegenüber Latenz und Jitter. Jede Latenz über wenige Millisekunden (Ciscos offizielles Limit wird oft basierend auf der optischen Reichweite genannt, aber 5 ms ist eine sichere praktische Obergrenze) kann zu Instabilitäten in der Control Plane-Kommunikation führen. Ein Ausfall der Langstreckenverbindung könnte zu einer Dual-Active-Bedingung führen, die schwer zu beheben ist. Der Fehlerbereich wird unakzeptabel groß.
Kleine Implementierungen: Für ein einfaches Top-of-Rack- oder Wiring Closet-Szenario mit 2-4 Switches ist ein vollwertiges SVL-Paar von Catalyst 9500s überdimensioniert. Ein Stack von Catalyst 9300s, der die dedizierten StackWise-1T-Backplane-Kabel verwendet, ist wesentlich kostengünstiger, einfacher zu konfigurieren und bietet eine einheitliche Management Plane in einem angemesseneren Formfaktor.

ISSU und Stateful Switchover (SSO)

In-Service Software Upgrade (ISSU) ist ein Hauptvorteil von SVL, der Software-Updates mit minimaler Traffic-Unterbrechung ermöglicht. Seine "Hitless"-Natur wird jedoch oft missverstanden. Der Prozess, der durch Stateful Switchover (SSO) gesteuert wird, funktioniert, indem zuerst die Standby-Chassis aktualisiert wird. Sie wird mit dem neuen Code neu geladen, während die aktive Chassis weiterhin Traffic weiterleitet. Sobald die Standby-Chassis wieder online und synchronisiert ist, wird ein manueller oder automatischer Switchover ausgelöst. Die neu aktive Chassis, die den neuen Code ausführt, übernimmt die Traffic-Weiterleitung. Die ehemals aktive (jetzt Standby) Chassis wird dann aktualisiert.

Dieser Prozess erhält die Data Plane aufrecht – die Weiterleitung erfolgt basierend auf bestehenden FIB- und Adjazenztabellen. Die Control Plane wird jedoch zurückgesetzt. Routing-Protokolle wie OSPF und EIGRP führen, wenn sie für Non-Stop Forwarding (NSF) konfiguriert sind, einen Graceful Restart durch, der Nachbar-Flaps verhindert. BGP-Sitzungen werden ebenfalls Graceful Restart durchführen. Es ist jedoch kein wirklich "unsichtbares" Ereignis. Der Prozess erfordert IOS XE 17.3.2 oder höher und die strikte Einhaltung der Kompatibilitätsmatrix für die Quell- und Zielversionen. Führen Sie ISSU immer in einem geplanten Wartungsfenster mit einem dokumentierten Rollback-Verfahren durch.

Migration von Catalyst VSS zu StackWise Virtual

Viele Unternehmen stehen vor dem End-of-Life ihrer Catalyst 6500/6800 VSS Cores. Die Migration zu einem Catalyst 9500/9600 SVL-Paar kann mit minimaler Ausfallzeit mithilfe eines Swing-Migrationsansatzes durchgeführt werden.

Pre-Staging: Rack und Stack des neuen SVL-Paares. Konfigurieren Sie SVL, Fast-Hello, alle SVIs, Routing-Protokolle, ACLs und QoS-Richtlinien. Halten Sie die SVIs in einem Shutdown-Zustand. Die neuen MEC-Port-Channels, die zum Access Layer zeigen, sollten konfiguriert sein, bleiben aber leer.
Swing Uplinks (Wartungsfenster): Führen Sie für jeden Downstream-Switch oder Stack, der über MEC mit dem VSS-Paar verbunden ist, den Swing durch. Nehmen wir an, ein Cat 9300 Stack hat einen Uplink zum VSS-Active und einen zum VSS-Standby.

Verschieben Sie den Uplink vom VSS-Standby-Chassis auf einen Port des neuen SVL-Standby-Chassis. Der Port-Channel auf dem Cat 9300 hat nun einen Member-Link down und einen up (zum VSS-Active).
Verschieben Sie den Uplink vom VSS-Active-Chassis auf einen Port des neuen SVL-Active-Chassis. Der Port-Channel auf dem Cat 9300 ist nun vollständig mit dem neuen SVL-Core verbunden. Der Traffic fließt immer noch nicht, da die SVIs down sind.

Routing Cutover: Dies ist der dienstbeeinträchtigende Schritt. Auf dem neuen SVL-Core führen Sie ein `no shutdown` auf allen Core-SVIs aus. Gleichzeitig `shutdown`-en Sie alle SVIs auf dem alten VSS-Core. Dies zwingt den gesamten gerouteten Traffic, über die neue Fabric zu fließen. Peer Routing Adjacencies werden vom alten Core abgebaut und mit dem neuen wiederhergestellt.
Außerbetriebnahme: Nach einer Überwachungsperiode zur Sicherstellung der Stabilität schalten Sie das alte VSS-Chassis aus und entfernen es.

StackWise Virtual, implementiert auf den robusten Catalyst 9500- und 9600-Plattformen, bietet eine formidable Lösung für den Aufbau der nächsten Generation von Enterprise Campus-Netzwerken. Seine Stärke liegt nicht in der Einfachheit seines Konzepts, sondern in der detaillierten Ausführung seiner unterstützenden Komponenten: ein ordnungsgemäß dimensionierter SVL, ein physisch isolierter Fast-Hello-Link und korrekt konfigurierte MECs. Durch die Vermeidung häufiger Fallstricke und die Einhaltung seiner Designgrenzen können Netzwerk-Ingenieure eine Core- und Distributions-Fabric aufbauen, die die erforderliche Stabilität und Leistung bis 2026 und darüber hinaus bietet. Um einen personalisierten Migrationsplan oder eine Architekturprüfung für Ihren Campus zu besprechen, kontaktieren Sie die Experten unter techleague.io.

Weitere Informationen zum Campus-Design finden Sie in unseren Beiträgen zu EVPN-VXLAN als Campus Fabric und einem Leistungsbericht des Catalyst 9300X mit StackWise-1T.