Ein Core- oder Distribution-Design „ohne Spanning Tree“ klingt im Cisco-Kontext zunächst provokant – ist aber genau das Versprechen von Cisco VSS/StackWise Virtual: Zwei physische Switches verhalten sich wie ein logischer Switch, sodass Downstream-Geräte ihre Uplinks als einen einzigen EtherChannel (MEC) betreiben können. Damit entfällt die klassische STP-Blockierung zwischen den beiden Chassis, weil es aus Sicht der Access-Switches nur noch „ein“ Aggregationsgerät gibt. In der Praxis reduziert das die Layer-2-Komplexität, verbessert die nutzbare Bandbreite im Uplink und macht Failover-Szenarien planbarer, weil nicht erst ein STP-Reconvergence-Pfad abgewartet werden muss. Gleichzeitig ist es wichtig, präzise zu bleiben: VSS/StackWise Virtual eliminiert nicht jedes STP im Netzwerk, sondern verringert die Abhängigkeit von STP an einer kritischen Stelle – in der Aggregationsschicht – und ermöglicht dadurch ein stabileres, aktives Active/Active-Uplink-Modell. Dieser Artikel zeigt, wie Sie Cisco VSS (Virtual Switching System) und StackWise Virtual in Core/Distribution sauber designen, konfigurieren und betreiben: mit Fokus auf Architekturprinzipien, Dual-Active-Schutz, Link-Design, Upgrade-/Betriebsregeln und Troubleshooting. Ziel ist ein praxisfähiges Blueprint, das die Vorteile von „Core/Distribution ohne Spanning Tree-Blockierung“ wirklich nutzbar macht, ohne neue Risiken durch unklare Failure-Szenarien oder fehlende Governance zu erzeugen.
Begriffe und Zielbild: Was „ohne Spanning Tree“ in der Praxis bedeutet
In klassischen Campus-Designs sind Access-Switches redundant an zwei Distribution-Switches angebunden. Ohne Multi-Chassis-Link-Aggregation sieht STP zwei separate Wege und blockiert typischerweise einen, damit keine Loops entstehen. Das Ergebnis: Redundanz ist vorhanden, aber ein Teil der Bandbreite bleibt ungenutzt, und Failover kann STP-Transitions auslösen. VSS (häufig auf Catalyst 6500/6800 und bestimmten Catalyst 4500-E-Konzepten) und StackWise Virtual (auf modernen Catalyst-Plattformen wie 9k) verfolgen ein anderes Prinzip: Zwei Chassis werden zu einem logischen System zusammengeführt. Downstream kann dadurch einen Multi-Chassis EtherChannel (MEC) aufbauen, der wie ein normaler Port-Channel wirkt – nur eben über zwei physische Geräte verteilt.
- VSS (Virtual Switching System): Zwei Switches bilden ein logisches System mit gemeinsamer Control Plane, gemeinsamen Konfigurationsobjekten und MEC-Unterstützung.
- StackWise Virtual: Ein ähnliches Konzept für neuere Plattformen, bei dem zwei Chassis über Virtual-Links einen gemeinsamen Switch bilden.
- MEC (Multi-Chassis EtherChannel): Downstream-Port-Channel über beide Chassis; aus Downstream-Sicht ein logischer Uplink.
- „Ohne STP-Blockierung“: STP muss nicht mehr zwischen den beiden Aggregationschassis einen Uplink blockieren, weil der Uplink als Port-Channel zu einem logischen Switch gilt.
Wichtig: STP verschwindet nicht zwingend komplett aus dem Netz. In großen L2-Domänen oder an bestimmten Übergängen bleibt STP relevant. Der zentrale Gewinn liegt darin, dass die Aggregationsschicht nicht mehr als zwei getrennte STP-Knoten agiert, sondern als ein logisches Gerät – das reduziert die Wahrscheinlichkeit für Root-Drift, unerwartete Blocking-Ports und STP-bedingte Bandbreitenverschwendung.
Warum VSS/StackWise Virtual in Core/Distribution so attraktiv ist
Enterprise-Campus-Designs werden im Betrieb oft durch zwei Dinge belastet: Erstens durch Layer-2-Komplexität (STP, große VLAN-Flächen, Trunk-Sprawl), zweitens durch Failover-Szenarien, die schwer zu testen und zu erklären sind. VSS/StackWise Virtual adressiert genau diese Schwachstellen mit einem konsolidierten Modell.
- Active/Active Uplinks: Beide Uplinks vom Access können gleichzeitig genutzt werden, ohne dass STP einen blockt.
- Einfachere Topologie: Aus Sicht des Access existiert nur ein Aggregationsswitch, nicht zwei.
- Planbare Konvergenz: Link-Failover innerhalb eines Port-Channels ist häufig schneller und deterministischer als STP-Reconvergence.
- Weniger Design-„Tricks“: Root-Placement und HSRP-Active/Standby-Abgleich werden einfacher, weil das Gateway häufig auf dem logischen System sitzt.
Der praktische Nutzen zeigt sich besonders in Access-Blocks mit vielen Endgeräten, bei denen Link-Flaps oder Wartungsarbeiten sonst regelmäßig STP-Events auslösen. Mit MEC verhalten sich Uplinks deutlich „langweiliger“ – und das ist in Enterprise-Betrieb ein Qualitätsmerkmal.
Architekturprinzipien: Welche Komponenten Sie zwingend sauber planen müssen
VSS/StackWise Virtual sind keine reinen „Konfig-Features“, sondern Architekturen. Sie verändern Failure-Domains und Betriebsregeln. Deshalb sollten Sie im Design mindestens diese Bausteine sauber durchdenken:
- Virtual Link(s): Die interne Verbindung zwischen den beiden Chassis (VSL bei VSS bzw. Virtual Link bei StackWise Virtual). Das ist eine kritische Infrastrukturverbindung.
- Control Plane Rollen: Active/Supervisor und Standby-Controller. Rollenwechsel müssen planbar und beobachtbar sein.
- Dual-Active-Schutz: Mechanismen, die Split-Brain verhindern oder sicher abfangen, wenn der Virtual Link ausfällt.
- Uplink-Design (MEC): Downstream-Port-Channels müssen konsistent, sauber dokumentiert und standardisiert sein.
- Layer-3/First Hop: Gateway-Design und Routing-Adjacencies (z. B. OSPF/BGP) müssen zum logischen System passen.
Als Ausgangspunkt für plattformspezifische Konfigurationsdetails sind die offiziellen Cisco-Konfigurationsleitfäden am zuverlässigsten, z. B. die Cisco Switch Configuration Guides. Für StackWise Virtual finden sich Release- und Plattformdetails in den Catalyst-9000-Softwareguides.
Virtual Links richtig designen: Bandbreite, Redundanz und Fehlerfolgen
Der Virtual Link ist nicht „nur ein Kabel“. Er trägt Synchronisation, Steuerinformationen und – je nach Plattform und Betriebszustand – auch Datenverkehr in Sonderfällen. Unterdimensionierte oder instabile Virtual Links sind eine der häufigsten Ursachen für schwer zu diagnostizierende Störungen. In Enterprise-Designs gilt daher:
- Redundanz: Virtual Links sollten aus mehreren physisch getrennten Verbindungen bestehen (Port-Channel), um Einzelfehler abzufangen.
- Ausreichende Kapazität: Dimensionieren Sie so, dass auch Fehlerfälle (z. B. ein Downstream-Link fällt aus und Traffic nimmt alternative Pfade) nicht zu Engpässen führen.
- Physische Trennung: Idealerweise über getrennte Linecards/Module und getrennte Kabelwege, wo möglich.
- Klare Dokumentation: Virtual-Link-Ports sind kritisch. Sie müssen sofort erkennbar sein (Naming/Labeling).
Ein guter operativer Test ist nicht nur „Ping geht“, sondern Last- und Failover-Tests: Was passiert bei Verlust eines Virtual-Link-Members, bei kompletter Unterbrechung, bei asymmetrischen Linkproblemen? Diese Szenarien müssen vor dem produktiven Rollout geübt werden.
Dual-Active Detection: Split-Brain ist das zentrale Risiko
Das gefährlichste Szenario in VSS/StackWise Virtual ist Dual-Active (Split-Brain): Beide Chassis halten sich gleichzeitig für „active“ und treffen widersprüchliche Entscheidungen. Das kann zu MAC-Flaps, Blackholing und unvorhersehbaren Effekten führen. Deshalb gehört Dual-Active Detection in jede ernsthafte Design- und Betriebsplanung.
- Warum Dual-Active entsteht: Meist durch Ausfall/Unterbrechung der Virtual Links oder durch Kontrollpfadprobleme.
- Was Dual-Active auslöst: Falsche Rolleninterpretation, fehlende Synchronisation oder unerwartete Failure-Kombinationen.
- Was Dual-Active Detection leisten soll: Das System muss den Split-Brain erkennen und kontrolliert in einen sicheren Zustand gehen (z. B. ein Chassis isolieren).
Die konkrete Umsetzung hängt von Plattform und Software ab (z. B. spezielle Detection-Mechanismen über dedizierte Links oder über bestimmte Downstream-Signale). Entscheidend ist: Dual-Active ist kein theoretisches Randthema. Es ist der Kern der Risikoanalyse und muss in Runbooks, Monitoring und Change-Prozessen verankert sein.
MEC-Design: Uplinks als Port-Channel – aber richtig
Der größte Alltagsgewinn entsteht durch MEC: Access-Switches (oder Distribution-Downstreams) können Uplinks zu beiden Chassis als einen Port-Channel betreiben. Damit das stabil ist, muss die Konsistenzregel kompromisslos gelten: Alle Member-Links eines MEC müssen identische L2-Parameter haben, insbesondere Trunk-Mode, Allowed VLAN Lists, Native VLAN und – wenn relevant – MTU. Jede Inkonsistenz führt früher oder später zu schwer erklärbaren Fehlerbildern.
- Allowed VLAN Lists: Keine „allow all“-Trunks. Definieren Sie exakt, welche VLANs über den MEC laufen dürfen.
- Native VLAN: Konsistent und bewusst gewählt; in Enterprise-Designs idealerweise nicht für produktiven Traffic.
- LACP bevorzugen: LACP macht Membership und Inkonsistenzen sichtbarer als statische Bündelung.
- Port-Channel als Einheit: Änderungen immer am Port-Channel-Objekt durchführen, nicht an Einzelports.
Ein Experten-Tipp: Behandeln Sie MECs wie „kritische APIs“. Jede VLAN-Änderung ist eine Änderung am API-Vertrag zwischen Access und Distribution. Deshalb gehören VLAN-Änderungen an MECs in kontrollierte Change-Fenster mit Pre-/Post-Checks (STP-Status, MAC-Flaps, Counters, relevante Logs).
STP im VSS/StackWise Virtual Kontext: Weniger, aber nicht gleich null
Der große Vorteil ist, dass zwischen den beiden Aggregationschassis kein STP mehr einen Uplink blockieren muss, wenn Access via MEC angebunden ist. Dennoch bleibt STP in typischen Campusnetzen relevant:
- Edge-Ports: PortFast/BPDU Guard bleibt Pflicht, um Loops durch Fehlpatching zu verhindern.
- Rest-L2-Domänen: Wenn VLANs über weitere Switches oder Drittanbieter-Komponenten laufen, existieren weiterhin STP-Interaktionen.
- Übergänge: Bereiche, die nicht über MEC angebunden sind, können weiterhin STP-Blocking erzeugen.
Das Ziel ist daher nicht „STP abschaffen“, sondern „STP aus der kritischen Aggregationsentscheidung herausnehmen“ und die Topologie so zu gestalten, dass STP nicht mehr als Lastverteiler missbraucht wird.
Gateway- und Routing-Design: HSRP/VRRP, SVIs und IGP/BGP
In klassischen Dual-Distribution-Designs wird die First-Hop-Redundanz (HSRP/VRRP) oft genutzt, um Active/Standby pro VLAN zu steuern, und STP-Root-Placement muss dazu passen, damit Traffic nicht tromboniert. In einem VSS/StackWise Virtual Design kann sich diese Logik vereinfachen, weil das Aggregationspaar ein logischer Switch ist.
- SVIs auf dem logischen System: VLAN-Gateways können zentral und konsistent betrieben werden.
- IGP/BGP: Routing-Adjacencies sind auf dem logischen Gerät konsolidiert; Policies werden einfacher zu standardisieren.
- Failure-Domains bewusst: Obwohl zwei Chassis existieren, ist die Control Plane gemeinsam. Planen Sie, welche Ausfälle akzeptiert werden (z. B. ein Chassis-Ausfall) und welche nicht (z. B. Dual-Active).
Ein häufiges Missverständnis ist, dass ein logischer Switch automatisch „die beste“ Routing-Architektur liefert. In der Praxis gilt weiterhin: Layer-2-Flächen begrenzen, VLANs prunen, klare Routing-Policies definieren. VSS/StackWise Virtual hilft bei der Aggregationskomplexität, ersetzt aber kein sauberes L2/L3-Design.
Upgrade- und Wartungsmodell: Warum Betriebsregeln entscheidend sind
Der Erfolg von VSS/StackWise Virtual zeigt sich im Betrieb: Upgrades, Wartungsfenster und Geräteersatz müssen planbar sein. Viele Teams unterschätzen, dass ein logischer Switch zwar die Konfiguration vereinfacht, aber Upgrades und Failover trotzdem sorgfältig orchestriert werden müssen. Eine Enterprise-Baseline sollte daher klare Regeln definieren:
- Version Governance: Freigegebene Softwareversionen, definierte Upgrade-Zyklen, dokumentierte Interoperabilität.
- Pre-Checks: Control-Plane-Health, Virtual-Link-Status, Port-Channel-Konsistenz, Logs, CPU/Memory, Routing-Adjacencies.
- Post-Checks: Rollenstatus (Active/Standby), keine unerwarteten MAC-Flaps, stabile Neighbors, erwartete VLAN-/Trunk-Zustände.
- Backout-Kriterien: Objektive Signale (Flaps, Drops, Blackholing), ab denen zurückgerollt wird.
Für praktische Dokumentations- und Change-Standards kann ein Rahmen wie das NIST Cybersecurity Framework helfen, weil es Governance, Detect/Respond/Recover in eine auditierbare Struktur bringt.
Monitoring und Telemetrie: Die „unsichtbaren“ Signale früh erkennen
VSS/StackWise Virtual Fehlerbilder sind häufig indirekt: ein Teil der VLANs wirkt instabil, einzelne Access-Blöcke zeigen Paketverlust, oder MAC-Tabellen flappen sporadisch. Deshalb ist Observability Pflicht. Der Blueprint sollte mindestens diese Signale zentral überwachen:
- Virtual Link Health: Status, Errors, Flaps, Port-Channel-Members, Auslastung.
- Dual-Active Events: Detection-Events, Schutzaktionen, Syslog-Meldungen.
- MEC Consistency: VLAN-Allowed-List-Mismatches, Native VLAN Mismatches, LACP-States.
- STP Edge Events: BPDU Guard, Root Guard, Loop Guard, Topology Changes in Access-Bereichen.
- Routing Stability: Neighbor-Flaps, Routenanzahl, CPU-Spikes, Drops (Control Plane).
Zusätzlich sollten Sie bei großen Umgebungen eine „Configuration as Code“-Logik einführen, damit Änderungen versioniert sind und Drift sichtbar bleibt. Das reduziert die Wahrscheinlichkeit, dass ein MEC auf Chassis A anders aussieht als auf Chassis B.
Troubleshooting: Die häufigsten Fehlerbilder und ein reproduzierbarer Diagnosepfad
Der größte Zeitgewinn im Incident entsteht durch einen festen Diagnosepfad. Bei VSS/StackWise Virtual sollten Sie konsequent von „Systemzustand“ zu „Linkzustand“ zu „L2/L3-Konsistenz“ arbeiten.
- Symptom: Sporadische Erreichbarkeit: Prüfen Sie Virtual Link Stabilität, MEC/LACP-States und MAC-Flapping. Oft steckt eine inkonsistente Allowed List oder ein intermittierender Link dahinter.
- Symptom: Nur bestimmte VLANs betroffen: Sehr häufig VLAN-Allowed-List-Mismatch oder Native VLAN Inkonsistenz auf einem MEC- oder Virtual-Link-Kontext.
- Symptom: Massive MAC-Flaps: Prüfen Sie Dual-Active-Signale, Virtual-Link-Fehler, Downstream-Loops und Port-Channel-Mismatches.
- Symptom: Failover wirkt „kaputt“: Rollenstatus (Active/Standby), Detection-Mechanismen, Keepalive/Detection-Pfade (plattformabhängig) und Uplink-Verteilung prüfen.
Ein bewährter Ansatz ist, „Konsistenzfehler“ zuerst zu suchen: EtherChannel/VLAN/MTU/Native VLAN. Diese Fehler erzeugen die meisten schwer erklärbaren Effekte, sind aber mit klaren Checklisten gut beherrschbar.
Design-Fallstricke: Was in der Praxis am häufigsten schiefgeht
- Virtual Link unterdimensioniert: In Fehlerfällen wird er zum Engpass; Symptome sind Drops und instabile Zustände.
- Dual-Active nicht sauber abgesichert: Split-Brain-Risiko wird unterschätzt; das ist das gefährlichste Szenario.
- Inkonsistente MEC-Konfiguration: Allowed VLANs/Natives/MTU weichen ab; „nur manche VLANs gehen“ und MAC-Flaps sind typische Folgen.
- VLAN-Sprawl: Trotz MEC werden VLANs überall geführt; Broadcast-Domänen bleiben unnötig groß.
- Kein Upgrade-Runbook: Wartungsfenster werden zu ad hoc Aktionen; Recovery ist unsicher.
- Monitoring-Lücken: Dual-Active-Events oder Virtual-Link-Fehler werden erst bemerkt, wenn Nutzer betroffen sind.
Blueprint: Betriebsregeln für Core/Distribution mit VSS/StackWise Virtual
Ein Enterprise-tauglicher Blueprint ist nicht nur Konfiguration, sondern Regelwerk. Diese Betriebsregeln haben sich in vielen Umgebungen bewährt:
- Klare Topologie: Zwei Chassis als logisches System, Virtual Links als Port-Channel mit physischer Trennung.
- MEC überall konsequent: Downstream-Uplinks grundsätzlich als LACP-Port-Channel (MEC) ausrollen.
- Allowed Lists als Pflicht: Keine „allow all“-Trunks; VLANs nur dort transportieren, wo sie gebraucht werden.
- Dual-Active als Pflichtkontrolle: Detection aktiv, Events überwacht, Runbooks vorhanden.
- Upgrades als Produkt: Version Governance, Pre-/Post-Checks, Backout-Kriterien, Canary-Ansatz bei größeren Changes.
- Auditierbarkeit: Naming, Interface-Descriptions, Konfigurationsarchive und Change-Historie (AAA/Repo) standardisieren.
Outbound-Referenzen
- Cisco Switch Configuration Guides für plattformspezifische Details zu StackWise Virtual, EtherChannel, STP und High Availability.
- Catalyst StackWise System Architecture White Paper als Architektur-Referenz für Stacking- und HA-Prinzipien (hilfreich für Designverständnis).
- Cisco EtherChannel – Konfiguration und Troubleshooting für MEC-/Port-Channel-Konsistenz, LACP und typische Fehlerbilder.
- NIST Cybersecurity Framework als Rahmen für Governance, auditierbare Betriebsregeln und Incident-Response-Prozesse.
Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte
Cisco Networking • CCNA • Packet Tracer • Network Configuration
Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.
Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.
Leistungsumfang:
-
Netzwerkdesign & Topologie-Planung
-
Router- & Switch-Konfiguration (Cisco IOS)
-
VLAN, Inter-VLAN Routing
-
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
-
NAT, ACL, DHCP, DNS-Konfiguration
-
Troubleshooting & Netzwerkoptimierung
-
Packet Tracer Projektentwicklung & Dokumentation
-
CCNA Lern- & Praxisunterstützung
Lieferumfang:
-
Konfigurationsdateien
-
Packet-Tracer-Dateien (.pkt)
-
Netzwerkdokumentation
-
Schritt-für-Schritt-Erklärungen (auf Wunsch)
Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert
CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.
