Warum Redundanz kein Selbstläufer ist – und wie STP unsere Netzwerke schützt

In der Netzwerktechnik ist Redundanz ein zentraler Begriff. Sie steht für Ausfallsicherheit, Stabilität und eine unterbrechungsfreie Kommunikation – zumindest in der Theorie. In der Praxis allerdings kann Redundanz zur Falle werden. Genauer gesagt: zur gefährlichen Endlosschleife, auch Loop genannt.

Gerade in klassischen Layer-2-Ethernet-Netzen ohne Routing greift bei einer Schleife keine Time-to-Live (TTL), wie es auf Layer 3 der Fall ist. Frames können unendlich zirkulieren – es entsteht ein sogenannter Broadcast Storm, der das gesamte Netzwerk innerhalb weniger Sekunden lahmlegen kann. Wer schon einmal erlebt hat, wie plötzlich weder Drucker noch Gateways erreichbar sind und Switch-LEDs im Dauerfeuer blinken, weiß: Loops sind keine akademische Gefahr, sondern reale Betriebsrisiken.

Und genau hier kommt das Spanning Tree Protocol (STP) ins Spiel. Es sorgt dafür, dass redundante Pfade im Netzwerk zwar physisch vorhanden, aber logisch nur dann aktiv sind, wenn sie gebraucht werden. STP spannt also einen Baum über die Netzwerktopologie – mit dem Ziel, Loops zuverlässig zu verhindern.

Dieser Beitrag richtet sich an alle, die Netzwerke professionell betreiben, verstehen oder gerade auf das Cisco CCNA-Zertifikat hinarbeiten. Wir beleuchten:

  • die technischen Grundlagen von STP und seinen Cisco-Varianten (PVST+, Rapid PVST+, MSTP),
  • wichtige Schutzmechanismen wie BPDU Guard und Loop Guard,
  • die Integration in moderne Netzarchitekturen mit EtherChannel und Overlay-Protokollen,
  • sowie Exkurse, die über das CCNA-Niveau hinausgehen – etwa zu Timer-Optimierung, BPDU-Manipulation oder VXLAN.

Tipp: Wer sich zunächst mit den Grundlagen der Kommunikation im Ethernet vertraut machen möchte, findet im Beitrag Warum jedes Bit seinen Weg braucht – Der Weg zur intelligenten Kommunikation einen fundierten Einstieg in die Funktionsweise moderner Netzwerke.

Im nächsten Abschnitt schauen wir uns an, warum Loops im Ethernet so gefährlich sind – und wieso Redundanz ohne Kontrolle alles andere als stabil ist.

Die Gefahr von Loops im Ethernet

Ethernet, wie es im LAN-Bereich weit verbreitet ist, arbeitet standardmäßig auf Layer 2 des OSI-Modells. Das hat viele Vorteile: Kommunikation ist schnell, Adressierung über MAC-Adressen unkompliziert, und die Infrastruktur lässt sich relativ einfach erweitern. Doch diese Einfachheit hat eine Schattenseite: Es gibt keinen Schutzmechanismus gegen Endlosschleifen.

Im Gegensatz zu IP-Paketen auf Layer 3, die eine sogenannte Time to Live (TTL) besitzen und damit nach einer bestimmten Anzahl von Hops verworfen werden, kennen Ethernet-Frames keine Lebensdauerbegrenzung. Das bedeutet: Wenn ein Frame in eine Schleife gerät, zirkuliert er unbegrenzt – und das kann fatale Folgen haben.

Beispielgrafik: Broadcast Loop in einem nicht abgesicherten Ethernet-Netz

In diesem Szenario ist kein Spanning Tree aktiv – ein Broadcast-Frame (z.B. ARP-Anfrage oder DHCP-Discover) wird:

  • von Switch 1 an Switch 2 und 3 gesendet (grüne Pfeile)
  • dort jeweils erneut weitergeleitet, auch an den jeweils anderen Switch (rote Pfeile)
  • zurück an Switch 1 gesendet, der ihn nicht als Duplikat erkennt
  • und wieder neu verteilt

Das Ergebnis: Der Broadcast kreist unendlich – der Frame vervielfältigt sich, belegt Bandbreite, blockiert MAC-Tabellen und führt letztlich zu einem Broadcast Storm, der das Netzwerk vollständig lahmlegen kann. Interessant auch die Betrachtung, dass der ursprüngliche gesendete Broadcast (Schritt 1) nun bereits doppelt zum Absender zurückkehrt (Schritt 5). Dies für neben der Überlastung der Netzwerkinfrastruktur auch zur zunehmender Belastung der Endgeräte im Netzwerk und wirft die Frage auf, wie die entsprechenden (Betriebs-)Systeme mit dieser Situation umgehen.

 Typische Symptome eines Layer-2-Loops:

  • Broadcast Storms, die alle Endgeräte massiv beeinträchtigen
  • DHCP funktioniert nicht mehr zuverlässig
  • Geräte (z.B. Router, Drucker, Server) sind nicht mehr erreichbar
  • Plötzlich hohe Auslastung auf eigentlich unkritischen Ports
  • Switches arbeiten im Dauerbetrieb – LEDs blinken ununterbrochen
  • Ungewöhnlich hohe CPU-Auslastung von Hosts innerhalb der Broadcastdomäne
  • Zugriff auf Gateways oder VLANs ist nicht mehr möglich

Diese Art von Fehlerbildern tritt oft nach trivialen Änderungen auf – ein falsch gestecktes Kabel, ein versehentlich aktivierter Trunk-Port oder ein nicht dokumentierter Switch können ausreichen, um das gesamte Netz lahmzulegen.

Die gute Nachricht: Es gibt einen bewährten Mechanismus, um genau solche Situationen zu vermeiden – das Spanning Tree Protocol (STP). Bevor wir in die Details einsteigen, werfen wir bei Bedarf einen genaueren Blick auf das Verhalten von Ethernet bei Broadcasts.

Exkurs: Wie Ethernet mit Broadcasts umgeht – und warum das zum Problem wird

Auf Layer 2 erfolgt die Kommunikation über MAC-Adressen, wobei bestimmte Zieladressen wie FF:FF:FF:FF:FF:FF für Broadcasts reserviert sind. Das bedeutet: Ein solcher Frame wird an alle Ports außer dem Eingangsport eines Switches weitergeleitet – also an alle anderen Geräte im gleichen Segment.

Das allein ist unkritisch – so lange die Topologie baumförmig und damit loopfrei ist. Kritisch wird es, wenn es mehrere Verbindungswege zwischen Switches gibt, etwa durch Redundanz ohne Loopschutz.

  • In solchen Szenarien kann der gleiche Broadcast-Frame zur gleichen Zeit über verschiedene Pfade eintreffen – zum Beispiel auf Port 1 und Port 2 eines Switches
  • Der Frame, der auf Port 1 empfangen wurde, wird über Port 2 weitergeleitet – und umgekehrt
  • Dadurch entsteht eine Rückkopplungsschleife, in der sich die Broadcasts gegenseitig endlos wiederholen – ohne TTL, ohne Abbruchbedingung

Dem ersten Broadcast folgt der zweite, der dritte und so fort. Das Resultat: Ein Broadcast Storm, bei dem sich die Netzwerkgeräte praktisch gegenseitig lahmlegen. Besonders betroffen sind Dienste wie DHCP oder ARP, die auf Broadcasts angewiesen sind und nun im Broadcast-Chaos untergehen.

Dieses Verhalten ist im Beitrag Warum jedes Bit seinen Weg braucht ausführlich erläutert. Wer sich für die Grundlagen der Bitübertragung, Switch-Funktion und logischen Pfadwahl interessiert, findet dort den passenden Einstieg.

Spanning Tree Protocol (STP) nach IEEE 802.1D – Das Fundament der Loopvermeidung

Damit in einem Ethernet-Netzwerk trotz redundanter physischer Verbindungen keine Loops entstehen, benötigt es eine logische Kontrolle – ein Regelwerk, das entscheidet, welche Pfade aktiv genutzt werden dürfen und welche blockiert werden müssen. Genau dafür wurde das Spanning Tree Protocol (STP) entwickelt, das erstmals 1990 in IEEE 802.1D standardisiert wurde.

STP bildet aus allen verfügbaren Switchverbindungen einen loopfreien logischen Baum – der sogenannte Spanning Tree. Dabei gilt: Nur ein einziger aktiver Pfad zu jedem Ziel ist erlaubt. Redundante Verbindungen bleiben im Hintergrund und werden erst aktiviert, wenn der Hauptpfad ausfällt. Das sichert Redundanz ohne Loops.

Wie funktioniert STP?

Das Spanning Tree Protocol basiert auf einem strukturierten Entscheidungsprozess, der in drei aufeinanderfolgenden Schritten erfolgt – dynamisch und verteilt von allen Switches im Netzwerk durchgeführt. Ziel ist es, einen loopfreien Pfadbaum zu erzeugen, der von einem zentralen Punkt ausgeht:

  1. Wahl der Root Bridge – Bestimmung des zentralen Bezugspunkts der Topologie
  2. Wahl der Root Ports – alle Nicht-Root-Switches ermitteln ihren jeweils besten Pfad zur Root Bridge
  3. Bestimmen der Designierten Ports – innerhalb jedes Netzwerkssegments wird der Port mit dem besten Weg zurück zur Root Bridge als aktiv markiert

Ports, die nicht in einem dieser drei Schritte als aktiv ausgewählt wurden, werden automatisch in den Blocking-Zustand versetzt, um Loops zu verhindern. So entsteht aus der physisch vermaschten Struktur ein logischer Baum, der eine kontrollierte Kommunikation ermöglicht – mit Redundanz, aber ohne Endlosschleifen.

Wahl der Root Bridge

Zentrales Element im STP ist die sogenannte Root Bridge – also der Master-Switch im Netzwerk. Alle anderen Switches berechnen ihre besten Pfade zur Root Bridge und richten sich nach ihr aus. Die Wahl erfolgt automatisch anhand der Bridge-ID, die sich wie folgt zusammensetzt:

  • eine konfigurierbaren Priority (Standard: 32.768)
  • einer MAC-Adresse des Switches (als Tiebreaker)

Der Switch mit der niedrigsten Bridge-ID wird zur Root Bridge erklärt. Verwenden alle Switches in der lokalen Broadcastdomäne den Standardwert für Priority, erfolgt die Wahl der Root Bridge auf Basis der besten MAC-Adresse – hier die MAC-Adresse mit dem niedrigsten Wert. Damit wird die Wahl zu einem unkontrollierten Zufall und wird mitunter nicht das beste Ergebnis liefern.

Wichtig: Diese Wahl ist nicht dauerhaft. Sollte ein neuer Switch ins Netzwerk eingebunden werden, der eine niedrigere Bridge-ID besitzt (z.B. durch eine niedrigere MAC-Adresse oder eine aggressive Priorität), kann dieser sich automatisch zur neuen Root Bridge erheben – ohne Vorwarnung. Das STP reagiert strikt nach Protokoll – nicht nach Netzwerkdesign. Temporäre Kommunikationsprobleme können die Folge sein.

In Unternehmensnetzen kann genau dieses Verhalten gezielt ausgenutzt werden – etwa durch BPDU-Injection oder unsachgemäß angeschlossene Switches. Aus diesem Grund sind Schutzmechanismen wie Root Guard essenziell, um unerwünschte Root-Übernahmen zu verhindern. Diese Sicherheitsfunktionen schauen wir uns im späteren Abschnitt über STP-Erweiterungen noch genauer an.

Exkurs: Die Root Bridge gezielt festlegen – Design mit Weitblick

Die Wahl der Root Bridge ist kein technisches Detail, sondern eine entscheidende Designentscheidung – vor allem in Netzen mit mehreren Switches, VLANs und Redundanzmechanismen.

Das hierarchische Netzwerkmodell von Cisco

Cisco empfiehlt seit Jahrzehnten ein dreistufiges, hierarchisches Netzwerkdesign, das sich auch heute noch in vielen Campus-Netzen findet:

  • Access Layer
    Hier sind Endgeräte wie Clients, Drucker, IP-Telefone und Access Points angeschlossen. Switches in dieser Schicht haben typischerweise Uplinks, aber keine übergeordneten Switching-Funktionen.
  • Distribution Layer
    Aggregiert die Access-Switches, übernimmt Routingfunktionen, Filterung, VLAN-Trennung, Redundanz. Oft mit Layer-3-Funktionalität.
  • Core Layer
    Das schnelle, stabile Rückgrat des Netzwerks – hochperformant, redundant, mit minimaler Komplexität. Bindeglied zu Datacenter, WAN oder Internet.

Designziel

Die Root Bridge des Spanning Tree sollte in einer solchen Topologie nicht zufällig entstehen, sondern bewusst im Distribution- oder Core-Layer platziert werden. Nur so lassen sich optimale Pfade, schnelle Konvergenz und Loop-Schutz sinnvoll kombinieren.

Empfohlene Praxis für Root Bridge und Backup-Root

  • Die Root Bridge sollte zentral und leistungsfähig platziert sein – meist im Core oder zentralen Distribution Layer.
  • Zusätzlich empfiehlt sich eine Backup Root Bridge mit etwas höherer Priorität, die im Fehlerfall nahtlos übernehmen kann.
  • In Cisco-Netzen kann die Priorität gezielt gesetzt werden mit:
    spanning-tree vlan 1 priority 24576
    oder durch die vereinfachten, dynamischen Varianten:
    spanning-tree vlan 1 root primary
    spanning-tree vlan 1 root secondary

Was bewirken diese Befehle?

  • root primary: Der Switch prüft die aktuelle STP-Topologie und setzt seine Priorität so, dass sie mindestens 8192 niedriger ist als die aktuell niedrigste festgestellte Bridge Priority im Netzwerk (unter Einhaltung der Untergrenze 0). Ziel ist es, aktiv Root Bridge zu werden.
  • root secondary: Der Switch reduziert seine aktuelle STP-Priorität um genau 4096, unabhängig davon, welche anderen Switches im Netzwerk vorhanden sind oder welche Priorität diese haben. Ziel ist es, eine bevorzugte Backup-Rolle einzunehmen, ohne automatisch Root Bridge zu werden – es sei denn, kein anderer Kandidat mit niedrigerer Priorität ist vorhanden.

STP-Prioritäten müssen in einer Cisco-Infrastruktur Vielfache von 4096 sein (z.B. 0, 4096, 8192, … bis 61440). Standardmäßig nutzen Switches den Wert 32768 – daher sind manuelle Anpassungen dringend empfohlen.

Achtung: Wenn man STP sich selbst überlässt, kann ein beliebiger Switch mit niedriger MAC-Adresse zur Root Bridge werden – auch ein Access-Switch mit nur 100-Mbit-Uplink. Das kann die gesamte STP-Topologie ineffizient machen.

Was ist ein Collapsed Core?

In kleineren oder mittelgroßen Netzwerken werden Distribution- und Core-Layer oft zusammengelegt – man spricht dann vom Collapsed Core. Hier übernehmen zentrale Switches sowohl Routing- als auch Backbone-Funktionen.

Das hat direkte Auswirkungen auf die STP-Planung:

  • Der Root Bridge-Kandidat wird in einem Collapsed-Core-Design nicht im reinen Core platziert, sondern in einem multifunktionalen Distribution/Core-Switch
  • Der Vorteil: reduzierte Kosten, weniger Geräte, einfacheres Design – aber: höhere Verantwortung für wenige Geräte → Root-Bridge-Auswahl ist hier kritisch

Portrollen im Spanning Tree

STP bestimmt auf jedem Switch, welcher Port welche Rolle einnimmt:

  • Root Port (RP): bester Pfad zur Root Bridge
  • Designated Port (DP): aktiver Port in einem Segment – zuständig für die Weiterleitung Richtung Root Bridge
  • Blocking Port: Ports, die in der aktuellen Topologie nicht benötigt werden und potenziell zu Loops führen würden

Beispielgrafik: Portrollen im STP bei identischer Bridge Priority
In diesem Beispiel weisen alle drei Switches dieselbe Bridge Priority (32.768) auf. Die Entscheidung über die Root Bridge fällt daher auf Basis der niedrigsten MAC-Adresse. Switch 1 übernimmt die Rolle der Root Bridge – die übrigen Switches wählen ihren Root Port, und die Verbindung zwischen Switch 2 und Switch 3 wird teilweise blockiert, um eine Schleife zu verhindern. Der Designatet Port fällt in diesem Segment dem Switch 2 zu, da er – im direkten Vergleich mit Switch 3 – die bessere (weil niedrigere) MAC-Adresse aufweist.

Wichtig:
Nur Root Ports und Designated Ports leiten Datenverkehr weiter und lernen MAC-Adressen. Blocking Ports hingegen nehmen keine Datenframes an und senden keine weiter – aber sie empfangen und analysieren BPDUs. So bleiben sie über die Netzwerktopologie informiert und können bei Änderungen aktiviert werden.

Timer und BPDU-Austausch

Switches tauschen regelmäßig sogenannte Bridge Protocol Data Units (BPDUs) aus. Diese enthalten Informationen zur Topologie und ermöglichen es jedem Switch, seine Rolle und die optimale Pfadwahl dynamisch anzupassen.

Die wichtigsten STP-Timer im Überblick:

  • Hello Time (Default: 2 Sekunden) – in diesem Intervall sendet die Root Bridge BPDUs aus.
  • Max Age (Default: 20 Sekunden) – so lange werden empfangene BPDUs als gültig betrachtet.
  • Forward Delay (Default: 15 Sekunden) – definiert die Dauer, die ein Port im Listening- und Learning-Zustand verbringt.

Warum dauert eine STP-Konvergenz bis zu 50 Sekunden?

Beim Ausfall einer Verbindung wird kein unmittelbarer Wechsel durchgeführt. Stattdessen läuft ein mehrstufiger Prozess ab:

  1. Die betroffenen Switches bemerken zunächst das Ausbleiben von BPDUs (maximal 20 Sekunden – Max Age).
  2. Danach wechseln potenzielle Ersatzports in den Listening-Zustand (15 Sekunden) und anschließend in den Learning-Zustand (weitere 15 Sekunden).
  3. Erst dann gehen sie in den Forwarding-Zustand über – also nach insgesamt bis zu 50 Sekunden.

Im Listening-Zustand verarbeitet der Switch noch keine Datenframes und lernt keine MAC-Adressen – er lauscht ausschließlich auf BPDUs, um sicherzustellen, dass die neue Verbindung nicht Teil eines Loops ist. Im anschließenden Learning-Zustand bleibt der Port weiterhin blockiert für Nutzdaten, beginnt jedoch damit, eingehende MAC-Adressen zu lernen und seine Forwarding-Tabelle vorzubereiten – ohne den Datenverkehr schon weiterzuleiten. Dieser Zustand ist somit nicht mehr bedeutsam für die eigentliche Loop-Erkennung, verhindert jedoch, dass der Switch beim anschießenden Wechsel in den Forwarding-Zustand direkt Datenframes fluten muss.

Diese Verzögerung war zur Zeit der ursprünglichen STP-Entwicklung (Anfang der 1990er Jahre) akzeptabel – heute ist sie für moderne Netzwerke mit VoIP, Echtzeitdiensten oder Streaming kritisch.

Im nächsten Abschnitt schauen wir uns an, wie das klassische STP modernisiert wurde – und wie RSTP (802.1w) deutlich schnellere Reaktionszeiten ermöglicht.

Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) – Schneller zum Ziel

Klassisches STP nach IEEE 802.1D leistet gute Arbeit – hat aber einen gravierenden Nachteil: Es ist langsam. Bei Topologieänderungen kann es bis zu 50 Sekunden dauern, bis ein Port aus dem Blocking-Status in den Forwarding-Zustand übergeht. In modernen Netzwerken mit Echtzeitanforderungen ist das kaum akzeptabel.

Um dieses Problem zu lösen, hat die IEEE mit dem Standard 802.1w im Jahr 2001 eine optimierte Variante vorgestellt: das Rapid Spanning Tree Protocol (RSTP). Es ersetzt STP vollständig, ist aber abwärtskompatibel, sodass es sich schrittweise einführen lässt – auch in gemischten Netzen.

Die drei großen Unterschiede zu klassischem STP

Schnelle Konvergenz

  • Klassisches STP nutzt Timer und durchläuft mehrere Zustände (Blocking → Listening → Learning → Forwarding)
  • RSTP erkennt Topologieänderungen ereignisgesteuert und ermöglicht direkte Übergänge zu Forwarding – insbesondere bei Point-to-Point-Links
  • Das reduziert die Umschaltzeit im Fehlerfall auf unter eine Sekunde in optimalen Szenarien

Neue Portrollen

RSTP ersetzt die alten STP-Rollen durch eine feinere Unterscheidung:

  • Root Port (RP): bester Pfad zur Root Bridge (wie bei STP)
  • Designated Port (DP): aktiv auf dem besten Pfad vom Segment zur Root Bridge
  • Alternate Port: Backup-Pfad zur Root Bridge (ersetzt Blocking Port)
  • Backup Port: redundanter Port auf dem gleichen Segment wie ein DP

Diese Rollen ermöglichen parallele Pfade und schnellere Wiederherstellung bei Ausfällen.

Neue Portzustände in RSTP

Klassisches STP kennt vier Portzustände: Blocking, Listening, Learning und Forwarding. Diese Übergänge erfolgen sequentiell und basieren auf Timern – das kostet Zeit.

RSTP vereinfacht dieses Modell auf drei Zustände:

  • Discarding – kein Datenverkehr, aber aktive Topologieüberwachung
  • Learning – MAC-Adressen werden gelernt, aber noch kein Forwarding
  • Forwarding – voller Datenverkehr möglich

Was ist das Besondere am Discarding-Zustand?

Der Discarding-Zustand in RSTP ersetzt die Zustände Blocking und Listening aus STP. Dabei gibt es jedoch einen zentralen Unterschied:

  • Bei klassischem STP blockiert ein Port den Verkehr und hört zwar auf BPDUs, entscheidet aber erst dann neu, wenn die aktuelle Topologie nicht mehr gültig ist (z.B. durch das Ausbleiben von BPDUs über 20 Sekunden).
  • RSTP hingegen verarbeitet BPDUs laufend aktiv – auch auf Ports im Discarding-Zustand. Es evaluieren Ports kontinuierlich, ob sie besser positioniert wären als aktuell aktive Ports – etwa durch einen niedrigeren Pfadkostenwert.

Dadurch kann RSTP innerhalb von Millisekunden auf Topologieänderungen reagieren, ohne erst Timer abwarten zu müssen. Der Discarding-Zustand in RSTP ist somit kein Warten im Leerlauf, sondern ein aktiver Beobachtungszustand – genau das macht die schnelle Konvergenz möglich.

Learning-Zustand bei RSTP – mit und ohne Proposal-Agreement

RSTP ist so konzipiert, dass Ports – wenn möglich – sofort in den Forwarding-Zustand übergehen können. Dafür nutzt RSTP das Proposal-Agreement-Verfahren, das nur auf Punkt-zu-Punkt-Links (typischerweise Vollduplex) angewendet wird.

Was ist das Proposal-Agreement-Verfahren?

Wenn ein Switch einen neuen Port aktiviert (z.B. nach einem Link-Up), sendet er auf diesem Port ein Proposal, das sinngemäß besagt:

Ich möchte diesen Pfad zur Root Bridge verwenden – ist das aus Deiner Sicht in Ordnung?

Der benachbarte Switch, der das Proposal empfängt, prüft daraufhin:

  • Ob dieser Pfad aus seiner Sicht auch gültig ist (z.B.  kürzer oder gleichwertig zum bisherigen Root Path)
  • Ob es zu einer Schleife kommen könnte

Nur wenn er sicher ist, dass kein Loop entsteht, antwortet er mit einem Agreement – also der aktiven Zustimmung. Währenddessen blockiert er seine anderen Ports kurzzeitig, um Loops zu vermeiden.

Sobald dieses Proposal-Agreement abgeschlossen ist, kann der betroffene Port direkt in den Forwarding-Zustand wechseln – ohne einen zusätzlichen Learning-Zwischenschritt durchlaufen zu müssen.

Was passiert, wenn kein Agreement möglich ist?

In Situationen, in denen kein Proposal-Agreement abgeschlossen werden kann – etwa bei Shared Media (Halbduplex), an Edge-Ports ohne STP-Nachbarn oder bei komplexen Topologieänderungen – geht RSTP vorsichtiger vor:

Der betroffene Port durchläuft dann – wie bei klassischem STP – einen Learning-Zustand, bevor er Forwarding aktiviert.

Learning-Zustand im Detail:

  • Der Switch blockiert noch den Datenverkehr
  • Er beginnt jedoch, eingehende MAC-Adressen zu lernen und seine Forwarding-Tabelle aufzubauen
  • So kann er später Frames gezielt zustellen, ohne Flooding zu erzeugen
  • Der Zustand ist zeitlich flexibel und wird dynamisch beendet, sobald ausreichende Stabilität erkannt wird

Fazit

Der Learning-Zustand bei RSTP ist kein Standard-Zeitpuffer wie bei STP, sondern ein kontextabhängiger Zwischenschritt, wenn keine sofortige Weiterleitung möglich ist.

Zusammenfassung: RSTP-Portzustände im Überblick

Die folgende Tabelle zeigt die drei Portzustände von RSTP im direkten Vergleich – mit Fokus auf Datenverkehr, MAC-Learning und der jeweiligen Funktion im Konvergenzprozess:

Zustand

Datenverkehr erlaubt

MAC-Adressen lernen

Beschreibung

Discarding

Nein

Nein

Kein Weiterleiten, keine Lernaktivität, nur BPDUs

Learning

Nein

Ja

MAC-Adressen werden gelernt, aber noch kein Traffic

Forwarding

Ja

Ja

Port ist aktiv für Daten und MAC-Learning

Cisco-Varianten von Spanning Tree – PVST+, Rapid PVST+ und MST im Überblick

Während IEEE-Standards wie 802.1D (STP) oder 802.1w (RSTP) herstellerneutral sind, hat Cisco früh eigene, erweiterte Implementierungen des Spanning Tree Protocol entwickelt. Diese Varianten bieten in Cisco-Umgebungen mehr Flexibilität und eine bessere Anpassung an VLAN-basierte Architekturen, wie sie in Campus-Netzen üblich sind.

Hier ein Überblick über die drei relevanten Varianten:

PVST+ (Per VLAN Spanning Tree Plus)

Cisco entwickelte PVST+ als proprietäre Erweiterung von STP. Der Hauptvorteil: Jedes VLAN bekommt seine eigene Spanning-Tree-Instanz.

Vorteile:

  • Erhöhte Redundanznutzung bei richtiger Platzierung
  • Optimierung des Pfaddesigns pro VLAN
  • Unabhängige Root Bridges für verschiedene VLANs möglich

Nachteil: Ressourcenintensiv – bei vielen VLANs kann das CPU und Speicher auf den Switches stark belasten.

PVST+ basiert intern auf dem klassischen STP (802.1D) – das bedeutet auch: langsame Konvergenzzeiten, wie bereits beschrieben.

Rapid PVST+

Rapid PVST+ kombiniert die Vorteile von PVST+ mit den Mechanismen von RSTP (802.1w) – also schnelle Konvergenz mit VLAN-spezifischer Trennung.

Vorteile:

  • Kompatibel mit älteren PVST+-Switches
  • Pro VLAN eine eigene RSTP-Instanz
  • Schnelle Umschaltung (unter 1 Sekunde)

Typische Cisco-Empfehlung: Rapid PVST+ ist in vielen Netzen die Standardwahl, wenn keine massive VLAN-Skalierung nötig ist.

MST (Multiple Spanning Tree)

Wenn die Zahl der VLANs steigt, stößt Rapid PVST+ an Grenzen. MST (Multiple Spanning Tree) schafft Abhilfe, indem es mehrere VLANs in logische Instanzen gruppiert, die gemeinsam eine Spanning-Tree-Berechnung durchführen.

Beispiel:

  • VLANs 10–20 verwenden Instanz 1
  • VLANs 30–40 verwenden Instanz 2
  • Der Rest bleibt bei Instanz 0 (Default)

Vorteile:

  • Kompatibel mit IEEE 802.1s
  • Skalierbar für große Netze
  • Weniger CPU- und Speicherbelastung auf Switches

Nachteil: Komplexere Konfiguration (Mapping, Instanznamen, Region-Konsistenz)

Hinweis zur Interoperabilität
Während PVST+ und Rapid PVST+ in Cisco-Umgebungen Standard sind, handelt es sich dabei um proprietäre Protokolle. Eine vollständige Interoperabilität mit Switches anderer Hersteller ist meist nur über den gemeinsamen Nenner 802.1D (STP) oder 802.1w (RSTP) möglich.

MST hingegen basiert auf dem IEEE-Standard 802.1s und ist in vielen Multi-Vendor-Umgebungen die bevorzugte Wahl – vorausgesetzt, die MST-Konfiguration ist auf allen Geräten identisch abgestimmt (MST-Region).

Cisco CLI-Befehle – PVST+/RSTP/MST analysieren und konfigurieren

Typische Befehle zur Anzeige des STP-Status auf einem Cisco-Switch:

show spanning-tree             # Übersicht über alle VLANs
show spanning-tree vlan 10     # Detailansicht für VLAN 10
show spanning-tree summary     # STP-Modus und Aktivität prüfen

Setzen des STP-Modus:

spanning-tree mode pvst        # Klassisches PVST+
spanning-tree mode rapid-pvst # Schnelles RSTP-basiertes PVST+
spanning-tree mode mst         # MST aktivieren

Priorität setzen (z.B. zur Root-Wahl):

spanning-tree vlan 10 priority 24576

Best Practices

  • Für kleine bis mittlere Netze: Rapid PVST+
  • Für Netze mit vielen VLANs: MST
  • PVST+ (klassisch) nur noch in Alt-Umgebungen oder zur Kompatibilität

Erweiterte STP-Mechanismen für Stabilität und Sicherheit

Das Spanning Tree Protocol sorgt für eine loopfreie Topologie – doch in realen Netzwerken reicht das allein nicht aus. Denn was in der Theorie sauber funktioniert, kann in der Praxis schnell durch Fehlkonfigurationen, veraltete Verkabelung oder sogar gezielte Angriffe kompromittiert werden.

Cisco bietet deshalb eine Reihe von erweiterten STP-Funktionen, die helfen, das Netz robuster und sicherer zu gestalten. Sie ergänzen das Grundprotokoll und sind besonders für Edge-Ports, redundante Uplinks und kritische Infrastrukturen relevant.

PortFast – sofortiges Aktivieren von Edge-Ports

Standardmäßig durchläuft ein Switchport nach dem Link-Up die STP-Zustände Listening und Learning. Das ist für Edge-Ports (z.B. PCs, Server, Drucker) unnötig und führt zu Verzögerungen. PortFast sorgt dafür, dass solche Ports sofort in den Forwarding-Zustand wechseln.

Portbasierte Konfiguration:

interface FastEthernet0/1
 spanning-tree portfast

Globale Konfiguration (automatisch für alle Edge-Ports):

spanning-tree portfast default

Achtung: Der Befehl portfast default aktiviert PortFast nur auf Ports, die keine Trunks sind. Für Trunk-Ports (z.B. zu IP-Telefonen mit Voice-VLAN) muss explizit spanning-tree portfast trunk verwendet werden.

BPDU Guard – Schutz vor unerwünschten Switches an PortFast-Ports

Ein mit PortFast aktivierter Port soll keine STP-BPDUs empfangen. Wenn doch – z.B. durch den Anschluss eines Mini-Switches – deaktiviert BPDU Guard den Port sofort (Errdisable).

Portbasierte Konfiguration:

interface FastEthernet0/1
 spanning-tree bpduguard enable

Globale Konfiguration (wirksam auf allen PortFast-Ports):

spanning-tree portfast bpduguard default

Diese Variante aktiviert BPDU Guard automatisch auf jedem Port, für den PortFast aktiviert wurde – auch wenn das per Port oder global geschehen ist.

Root Guard – Verteidigung der Root Bridge gegen Fremdübernahmen

Ein Angreifer oder ein falsch konfigurierter Switch könnte versuchen, selbst Root Bridge zu werden, indem er BPDUs mit niedriger Priorität sendet. Root Guard schützt ausgewählte Ports davor: Wenn ein besserer Root-Kandidat erkannt wird, wird der Port in den Root-Inconsistent-State versetzt – ohne sofort zu blockieren.

CLI:

interface GigabitEthernet 1/0/1
 spanning-tree guard root

Ideal für Uplinks von Access- zu Distribution-Switches, bei denen man nicht möchte, dass sie jemals Root Bridge werden.

Loop Guard – Schutz bei unidirektionalem BPDU-Verlust

In manchen Situationen (z.B. durch defekte Kabel) kann ein Port keine BPDUs mehr empfangen, obwohl die Verbindung physisch besteht. Klassisches STP würde den Port dann eventuell in den Forwarding-Zustand versetzen – ein Loop entsteht.

Loop Guard erkennt diesen Zustand und verhindert aktiv den Übergang.

CLI:

interface GigabitEthernet 1/0/2
 spanning-tree guard loop

Besonders sinnvoll auf Root- und Alternate-Ports in kritischen Pfaden.

(Optional) UDLD – Einseitige Verbindungen erkennen und Loops verhindern

UDLD steht für Unidirectional Link Detection und ist ein von Cisco entwickeltes Protokoll, das physikalisch fehlerhafte Punkt-zu-Punkt-Verbindungen erkennt, die in klassischen STP-Mechanismen nicht auffallen würden.

Solche Fehler können insbesondere bei folgenden Verbindungswegen asuftreten:

  • Glasfaserverbindungen (LWL)
  • Kupferverbindungen mit defekten Transceivern
  • fehlerhaft gepatchten Kabelwegen oder SFP-Modulen

Warum STP alleine nicht ausreicht

Ein klassischer Ethernet-Link besteht aus einem Sendepfad (TX) und einem Empfangspfad (RX). Wird z.B. nur der Empfangspfad beschädigt oder die Sendeeinheit eines Endpunkts fällt aus, erkennt der Switch unter Umständen dennoch eine physisch bestehende Verbindung – denn der Link-Status basiert auf der elektrischen oder optischen Verbindung, nicht auf logischer Kommunikation.

  • STP verlässt sich auf den physischen Linkstatus und den BPDU-Empfang
  • Fällt aber nur eine Richtung aus, bleiben BPDUs aus, obwohl der Port weiterhin aktiv ist
  • Das kann zu Loops oder Fehlinterpretationen im STP führen – besonders bei alternativen Pfaden

Wie UDLD funktioniert

UDLD arbeitet unabhängig von STP und prüft, ob beide Enden einer Verbindung:

  • gegenseitig Pakete empfangen
  • und sich dabei korrekt identifizieren (Switch-ID, Portnummer, etc.)

Jeder UDLD-fähige Port sendet in regelmäßigen Abständen kleine Hello-Nachrichten an seinen Nachbarport. Bleibt eine Antwort aus, kann der Switch die Verbindung als unidirektional identifizieren und deaktivieren – bevor STP eine potenziell gefährliche Entscheidung trifft.

Betriebsmodi von UDLD

  • Normal Mode
    • Erkennt einseitige Links, meldet sie aber nur
    • Der Port bleibt weiterhin aktiv
    • Einsatz z.B. im Monitoring
  • Aggressive Mode (empfohlen für kritische Links)
    • Sendet mehrfach Hello-Pakete in kurzen Abständen (Default: 8x jede Sekunde)
    • Erfolgt keine Antwort, wird der Port in den Zustand Errdisable versetzt
    • Netzwerkschutzmechanismus ist aktiv

CLI-Konfiguration von UDLD

Global aktivieren (für alle unterstützten Ports):

udld enable
udld aggressive   ! (für Betriebsart Aggressive)

Portbasiert aktivieren:

interface GigabitEthernet1/0/3
udld enable
 udld aggressive

Hinweis:

  • UDLD funktioniert nur auf Punkt-zu-Punkt-Links.
  • Unterstützt wird UDLD meist nur auf LWL-Ports (Glasfaser) und auf bestimmten Plattformen.
  • Errdisable Recovery kann per Timer automatisch erfolgen:
    errdisable recovery cause udld
    errdisable recovery interval 30

Best Practices
Kritische Uplinks – insbesondere Glasfaserverbindungen zwischen Core- und Distribution-Switches – sollten mit UDLD (aggressiv) und Loop Guard abgesichert werden. Diese Kombination bietet eine doppelte Sicherheitsbarriere gegen Loop-Fehlverhalten durch unbemerkte physische Defekte.

Vergleich: Loop Guard vs. UDLD – zwei Seiten derselben Medaille?

Sowohl Loop Guard als auch UDLD dienen dem Schutz vor Layer-2-Loops – doch sie greifen an unterschiedlichen Stellen und ergänzen sich ideal.

Merkmal

Loop Guard

UDLD

Abhängigkeit von STP

Ja – STP muss aktiv sein

Nein – unabhängig vom STP-Protokoll

Einsatzbereich

Spanning Tree (STP/RSTP)

Physikalische Linküberwachung

Funktionsweise

Erkennt ausbleibende BPDUs auf Root/Alternate-Ports

Erkennt einseitige Kommunikation durch bidirektionalen Hello-Austausch

Layer

Datenlink Layer (STP-Protokollebene)

Physikalisch / logische Verbindungsschicht

Reaktion im Fehlerfall

Port wird in Loop-Inconsistent gesetzt – kein Forwarding

Port wird errdisabled, ggf. mit Recovery-Timer

Typischer Einsatz

Uplinks, Blocking Ports, redundante Pfade

Glasfaserstrecken, kritische Uplinks

Voraussetzung

Aktives STP auf dem Port

Punkt-zu-Punkt-Verbindung und UDLD-Unterstützung

Zielsysteme

Alle STP-fähigen Ports

Meist LWL-Ports oder spezifische Plattformen

Fazit

  • Loop Guard schützt STP vor Fehleinschätzungen, wenn BPDUs durch einseitige Verbindungen nicht mehr empfangen
  • UDLD erkennt und unterbindet solche physikalischen Fehler proaktiv, bevor STP überhaupt reagieren muss.

Best Practices

Beide Funktionen sollten kombiniert werden, insbesondere bei Glasfaserverbindungen in der Core-Distribution oder bei Stack-Uplinks. So schützt UDLD die physikalische Integrität, während Loop Guard die logische Konsistenz innerhalb von STP bewahrt.

Exkurs: BPDU-Manipulation – STP als Angriffsvektor

Das Spanning Tree Protocol (STP) wurde entwickelt, um Netzwerke loopfrei zu halten – nicht, um sie abzusichern. Das heißt: STP vertraut jedem Gerät im Netzwerk, das sich als Switch ausgibt und BPDUs (Bridge Protocol Data Units) sendet. Dieses Grundprinzip macht STP in vielen Umgebungen – besonders auf Access-Layern – potenziell angreifbar.

Wie ein Angriff funktioniert – drei typische Szenarien

  1. Anschluss eines manipulierten Switches mit niedriger Bridge Priority

Ein Gerät wird in ein Netzwerksegment eingesteckt und sendet BPDUs mit niedriger Bridge Priority – z.B. 0.

  • STP erkennt das Gerät als neuen Root Bridge-Kandidaten
  • Die Topologie wird umgebaut, Verkehrswege ändern sich plötzlich – unter Umständen mit Performanceverlust, Paketverlust oder Netzwerkausfall
  1. BPDU-Flooding und gezielte Manipulation mit Tools

Angreifer:innen können mit Tools wie:

  • Scapy (Python-basiertes Paket-Framework)
  • Yersinia (Linux-Tool zur Netzwerkprotokoll-Manipulation)

gezielt gefälschte oder manipulierte BPDUs erzeugen – z.B. mit gefälschten MAC-Adressen, Root-Prioritäten oder Bridge-IDs. Dadurch lässt sich der Datenverkehr umleiten, Netzwerksegmentierung untergraben oder sogar ein Denial-of-Service (DoS) verursachen.

  1. Fehlkonfiguration durch Unachtsamkeit

Nicht jeder Angriff ist böswillig – auch versehentlich angeschlossene Switches, falsch konfigurierte VLAN-Trunks oder Testgeräte können dazu führen, dass eine unerwünschte STP-Neuberechnung ausgelöst wird.

Fazit: STP schützt nicht vor allem – aber lässt sich schützen

STP ist nicht sicher per Design – aber es lässt sich sicher einsetzen, wenn:

  • Edge-Ports mit PortFast und BPDU Guard abgesichert werden
  • Monitoring und Logging von STP-Ereignissen aktiv ist
  • Uplinks mit Root Guard geschützt sind

In modernen Netzen mit hoher Sicherheitsanforderung gilt:

Sichere Loops sind keine – sie sind sicher ausgeschlossen.

EtherChannel – Redundanz ohne Blocking

Das klassische Spanning Tree Protocol (STP) blockiert physikalische Pfade, um Loops zu verhindern. Das sorgt zwar für Stabilität – bedeutet aber auch, dass ein Teil der Netzwerkbandbreite brachliegt. Genau hier kommt EtherChannel ins Spiel.

Mit EtherChannel lassen sich mehrere physische Links zu einem logischen Kanal bündeln, der aus Sicht von STP wie eine einzige Verbindung behandelt wird. So kann Redundanz genutzt werden, ohne dass STP Ports blockieren muss.

Wie EtherChannel funktioniert

EtherChannel bündelt zwei bis acht Ports zu einer logischen Einheit – dem sogenannten Port Channel. Diese physischen Verbindungen müssen:

  • auf beiden Seiten konsistent zugewiesen werden
  • dieselbe Bandbreite nutzen (z.B. 1 Gbit/s)
  • gleich konfiguriert sein (Trunk vs. Access, VLAN-Zugehörigkeit)

Der Datenverkehr wird dann per Hashing gleichmäßig auf die physikalischen Links verteilt – abhängig von MAC-Adressen, IP-Adressen oder TCP-Ports.

Varianten von EtherChannel – statisch oder dynamisch verhandelt

EtherChannel lässt sich auf unterschiedliche Weise konfigurieren. Entscheidend ist, wie die beiden Endpunkte des Channels die Bündelung aushandeln – ob sie sich über ein Protokoll abstimmen oder die Konfiguration auf beiden Seiten manuell erfolgen muss.

In der Praxis unterscheidet man zwischen:

  • Statischer Konfiguration („mode on“) – keine Aushandlung, der Administrator trägt alles manuell auf beiden Seiten ein.
  • Dynamischer Aushandlung über ein Protokoll – dabei verhandeln die Switches automatisch, ob und wie die Channel-Ports gebildet werden.

Die folgende Tabelle zeigt die drei typischen Varianten – inklusive ihrer Herkunft und ob sie dynamisch aushandeln können:

Variante

Beschreibung

Standard

Dynamik

Static

Manuelle Konfiguration – keine Aushandlung

Nein

Nein

PAgP

Cisco-Protokoll – proprietär

Nein

Ja

LACP

IEEE 802.3ad – herstellerübergreifender Standard

Ja

Ja

Empfohlen: LACP ist heute der De-facto-Standard – interoperabel, flexibel und stabil.

Cisco-Schlüsselwörter für die Channel-Gruppierung

Bei der Konfiguration eines EtherChannels kommt es auf die Kombination der Modi an beiden Enden an. Je nach verwendetem Protokoll (LACP oder PAgP) nutzt Cisco spezifische Schlüsselwörter, um das Verhalten des Ports zu steuern:

LACP (Link Aggregation Control Protocol, IEEE 802.3ad)

  • active → initiiert aktiv LACP-Nachrichten zur Bündelung
  • passive → wartet auf eine LACP-Initiative von der Gegenseite

Mindestens eine Seite muss auf active stehen, damit ein Channel gebildet wird.

Beispiel:

interface GigabitEthernet1/0/1
 channel-group 1 mode active

Praxisfall: LACP funktioniert – aber nur in der Theorie

Ein reales Beispiel aus dem Netzwerkalltag: Ein mittelständisches Unternehmen möchte einen LANCOM 1793VA Router mit zwei 1-Gbit/s-Ports per LACP an einen Cisco CBS250-48T-4G Switch anbinden. Ziel ist es, einen Port Channel (EtherChannel) zur Erhöhung der Bandbreite und Redundanz einzurichten.

Beide Geräte weisen nach den jeweiligen Herstellerangaben LACP-Support auf. Die Konfiguration wird auf beiden Seiten entsprechend eingerichtet. Doch: Es kommt kein Port Channel zustande. Der Link bleibt ohne Funktion, es erfolgt kein Datenaustausch.

Die Ursache:
Beide Geräte – sowohl der LANCOM-Router als auch der Cisco CBS-Switch – unterstützen LACP nur im passiven Modus. Da kein Gerät aktiv LACP-Pakete initiiert, warten beide vergeblich auf einen Start der Aushandlung. Der Port Channel wird folglich nie aufgebaut.

Was passiert, wenn nur ein Link verwendet wird?

Wird auf der Seite des LANCOM-Routers einer der beiden Ports aus dem LACP-Verbund entfernt, funktioniert die Verbindung plötzlich – über den verbleibenden einzelnen Port. Hier greift ein integrierter Fallback-Mechanismus des Routers und des Switches: Stellt der LANCOM Router fest, dass kein Port Channel zustande kommt, nutzt er den verbleibenden Link als Einzelverbindung. Der Cisco-Switch erkennt das physische Link-Up, und der Datenverkehr fließt – aber ohne LACP, Redundanz oder Lastverteilung.

Fazit und Empfehlungen

  • Besonders bei Small-Business- oder Entry-Level-Hardware ist LACP oft nur teilweise implementiert (z.B. nur passiv).
  • Fallback-Verhalten kann täuschen: Die Verbindung wirkt funktional, ist aber nicht redundant und entspricht nicht dem Designziel.
  • LACP setzt nicht nur Support, sondern auch die richtige Modi-Kombination voraus: Mindestens ein Gerät muss im Modus active

PAgP (Port Aggregation Protocol, Cisco-proprietär)

  • desirable → sendet aktiv PAgP-Pakete
  • auto → lauscht passiv auf PAgP von der Gegenseite

Auch hier: Mindestens eine Seite muss desirable sein, sonst wird kein Channel aufgebaut.

Static (keine Aushandlung, kein Protokoll)

  • on → EtherChannel wird ohne Protokollbildung sofort aktiviert

Vorsicht bei on
Wenn beide Seiten on setzen, aber unterschiedliche Parameter (z.B. VLANs, Duplex) haben, entsteht kein funktionierender Channel, aber die Switches erkennen den Fehler meist erst spät – das kann zu schwer nachvollziehbaren Fehlerbildern führen.

CLI-Beispiele für LACP-Konfiguration

interface range GigabitEthernet 1/0/1 - 2
channel-group 1 mode active         ! LACP aktiv
exit
interface Port-Channel 1
 switchport mode trunk

STP-Verhalten mit EtherChannel

Da STP den EtherChannel als eine einzige logische Verbindung betrachtet, wird keiner der beteiligten Ports blockiert. Das heißt:

  • Keine Blockierung durch STP
  • Schnellere Konvergenz, da weniger Pfade bewertet werden müssen
  • Volle Bandbreite (eingeschränkt) nutzbar

Wichtig: Auch EtherChannels können redundant ausgelegt werden – z.B. zwischen Access und Distribution Layer – ohne STP-Blockierung.

Exkurs: Hashing und Fehlerbilder – was bei EtherChannel schieflaufen kann

EtherChannel nutzt Load Balancing via Hashing, typischerweise basierend auf:

  • Quell- oder Ziel-MAC-Adresse
  • IP-Adressen
  • TCP-/UDP-Portnummern

Das bedeutet: Jeder Datenfluss bleibt auf einem einzelnen physikalischen Link, da das Hashing deterministisch ist. Nur bei vielen parallelen Flows kann die Last sinnvoll auf mehrere Leitungen verteilt werden.

Anzeige des Load-Balancing-Typs:

show etherchannel load-balance

Aus der Praxis:

Auch wenn zwei 1-Gbit/s-Leitungen gebündelt sind, ergibt das nicht automatisch 2 Gbit/s für einen einzelnen Datenstrom.
Es bleibt bei maximal 1 Gbit/s pro Flow, da der Hashwert immer nur einen Link auswählt. Erst bei mehreren gleichzeitigen Verbindungen (z.B. viele Clients, parallele Sessions) wird die Bündelung effizient ausgenutzt.

Typische Fehlerbilder:

  • Asymmetrisches Hashing zwischen Switches
  • Falsche Konfiguration → Port wird nicht Mitglied des Channels
  • Nur ein Link wird ausgelastet → ungleichmäßige Verteilung
  • VLAN-Inkonsistenz → Traffic wird verworfen

Tipp: In Lab-Umgebungen lassen sich unterschiedliche Hashing-Methoden testen – z.B. mit port-channel load-balance und gezielter Traffic-Erzeugung via Ping oder iperf.

STP-Varianten im Vergleich – Welche passt zu welchem Netzwerk?

Über die Jahre hat sich das Spanning Tree Protocol weiterentwickelt – vom klassischen IEEE 802.1D STP bis hin zu leistungsfähigen Varianten wie Rapid PVST+ oder MST. Jede dieser Varianten hat ihre Vor- und Nachteile – und je nach Netzwerkanforderung ist eine andere Lösung optimal.

Die folgende Übersicht zeigt die wichtigsten Varianten im Vergleich:

Variante

Standard

Konvergenz

VLAN-Unterstützung

Proprietär

Besonderheiten

MST

IEEE 802.1s

mittel bis schnell

Instanz-Gruppen (z.B. VLAN 10–20)

Ja

Gute Skalierung, etwas komplexer

PVST+

Cisco-proprietär

langsam (wie STP)

1 Instanz pro VLAN

Nein

Separate Topologie je VLAN

Rapid PVST+

Cisco-proprietär

schnell (< 1 s)

1 Instanz pro VLAN

Nein

RSTP für Cisco-VLAN-Umgebungen

RSTP

IEEE 802.1w

schnell (< 1 s)

1 Instanz für alle VLANs

Ja

Empfohlen für einfache Netze

STP

IEEE 802.1D

langsam (bis 50 s)

1 Instanz für alle VLANs

Ja

Basisversion, heute veraltet

Wann welche Variante wählen?

Kleine bis mittlere Netze (wenige VLANs):

  • Rapid PVST+ ist die beste Wahl in reinen Cisco-Umgebungen
  • Bietet schnelle Konvergenz pro VLAN, einfache Konfiguration

Gemischte Netze mit mehreren Herstellern:

  • RSTP (802.1w) für maximale Kompatibilität
  • Kein VLAN-spezifisches STP – dafür interoperabel

Große Campus-Netze mit vielen VLANs:

  • MST (Multiple Spanning Tree) reduziert die Zahl der STP-Instanzen
  • VLANs werden zu logischen Instanzgruppen zusammengefasst – das spart CPU und Speicher auf den Switches
  • Wichtig: Region-Name, Revision-Number und VLAN-Mapping müssen auf allen Switches identisch sein.

Best Practices

„Verwende Rapid PVST+, solange die VLAN-Zahl überschaubar ist und Du in einem homogenen Cisco-Netz arbeitest. Bei skalierenden Umgebungen mit vielen VLANs, mehreren Standorten oder Multi-Vendor-Szenarien ist MST die zukunftssichere Wahl.“

Achtung: Klassisches STP (802.1D) oder PVST+ gelten heute als veraltet und sollten nur in Legacy-Umgebungen verwendet werden.

Troubleshooting und Best Practices – STP verstehen, interpretieren und absichern

Wer mit Spanning Tree arbeitet, sollte nicht nur die Theorie beherrschen, sondern auch in der Lage sein, Fehlerbilder zu analysieren, Root Causes zu finden und Designentscheidungen zu begründen. Denn STP-Probleme sind oft nicht offensichtlich – sie äußern sich als merkwürdige Aussetzer, instabile Verbindungen oder unerklärlicher Paketverlust.

Typische Fehlerquellen bei STP

  • Einseitige Glasfaserverbindung → keine BPDUs → Loop durch Fehlinterpretation
  • Link Down auf Root Port → lange Umschaltzeiten (bei klassischem STP)
  • Loop durch unbedachten PortFast-Einsatz ohne BPDU Guard
  • Mismatched VLAN-Konfigurationen auf Trunks → STP-Instanzen fehlen
  • STP-Blocking auf falschem Pfad → suboptimale Bandbreitennutzung
  • Ungewollter Root-Switch durch niedrige MAC-Adresse (z.B. billiger Access-Switch)

Wichtige CLI-Kommandos zur Analyse

STP-Status anzeigen

show spanning-tree
show spanning-tree vlan 10

Root Bridge identifizieren

show spanning-tree root

STP-Zusammenfassung (Modus, Instanzen, aktivierte Ports)

show spanning-tree summary

Fehlermeldungen und Events analysieren

show logging
show interfaces status err-disabled

Tipp: Ports, die durch BPDU Guard, UDLD oder Loop Guard deaktiviert wurden, erscheinen im Zustand errdisabled – das sollte regelmäßig geprüft und mit Recovery-Timern abgesichert werden.

Best Practices für stabiles STP-Design

Root Bridge aktiv festlegen

  • Nicht dem Zufall überlassen: Prioritäten bewusst setzen
  • Bei mehreren VLANs ggf. unterschiedliche Root Switches für Lastverteilung wählen

Edge-Ports sauber behandeln

  • PortFast aktivieren – aber immer mit BPDU Guard
  • Trunk-Ports zu IP-Telefonen: spanning-tree portfast trunk

Redundanz kontrollieren

  • EtherChannel nutzen statt paralleler Einzellinks
  • Redundante Pfade absichern mit Loop Guard und/oder UDLD

Dokumentation und Topologiepflege

  • Wer ist Root Bridge? Welche Pfade sind aktiv? → visuell dokumentieren
  • VLAN-Zuweisung je Port konsequent prüfen

Design konsistent umsetzen

  • Bei MST: auf identische Region-Konfiguration achten
  • Keine Mix-Konfiguration aus PVST+ und MST ohne klares Migrationskonzept

Aus der Praxis

Probleme mit STP zeigen sich selten als Fehlermeldung – sondern als Instabilität, Zeitüberschreitungen oder fehlendes DHCP. Wer STP-Fehler erkennt, bevor sie kritisch werden, hat das Netz im Griff.

Im nächsten Abschnitt folgt der Ausblick auf moderne Netzarchitekturen, in denen STP an seine Grenzen stößt – und welche Technologien diese Aufgaben heute übernehmen.

Moderne Architekturen – Hat Spanning Tree ausgedient?

Das Spanning Tree Protocol ist ein bewährtes Werkzeug, das seit Jahrzehnten für loopfreie Layer-2-Netze sorgt. Doch in modernen Netzwerkarchitekturen – mit Fokus auf Skalierbarkeit, Virtualisierung und Automatisierung – stößt STP zunehmend an seine Grenzen.

Gerade in Rechenzentren, Campus-Fabrics und Overlay-Umgebungen wird STP heute oft bewusst nicht mehr eingesetzt, sondern durch modernere Verfahren ersetzt oder kontrolliert eingefroren.

Warum STP in modernen Designs problematisch ist

  • STP basiert auf relativ langsamer Konvergenz (selbst RSTP ist zu träge für Rechenzentrumsanforderungen)
  • STP blockiert Pfade → Bandbreitenverschwendung
  • STP ist broadcast-basiert und nicht segmentiert
  • STP ist nicht für automatisierte Netztopologien oder Self-Healing-Designs gedacht
  • STP kennt keine Pfadpriorisierung jenseits der Root-Bridge-Logik

Was ersetzt STP in modernen Netzwerken?

In modernen Netzwerkarchitekturen wird die Rolle des klassischen Spanning Tree Protocols zunehmend durch intelligentere, kontrollierbare und skalierbare Technologien ersetzt. Diese fokussieren nicht mehr auf Pfadblockierung, sondern auf aktive Pfadnutzung, segmentierte Kontrolle und automatisiertes Failover.

VXLAN mit EVPN – das Overlay-Prinzip für das nächste Jahrzehnt

VXLAN (Virtual Extensible LAN) wurde entwickelt, um Layer-2-Segmentierung über ein Layer-3-Netzwerk hinweg zu ermöglichen. In Kombination mit EVPN (Ethernet VPN) als Control Plane entsteht eine leistungsstarke Overlay-Technologie, die klassische Layer-2-Domänen virtualisiert.

Statt BPDUs nutzt EVPN das Routingprotokoll BGP, um MAC-Adressen und Pfadinformationen kontrolliert und deterministisch zu verteilen – ohne Flooding und ohne STP.

Besonders relevant:

  • Native Integration in Rechenzentrums- und Campus-Fabrics
  • Segmentierung auf Fabric-Ebene
  • Volle Pfadnutzung (ECMP)

Vertiefung
Ein praktischer Einstieg in VXLAN und andere Overlay-Technologien findet sich im Beitrag Wenn die Computerkommunikation intelligent wird – Zukunftsarchitekturen, IPv6 und KI im modernen Netzdesign

FabricPath, TRILL und SPB – STP-Nachfolger mit Shortest Path Forwarding

Diese Technologien wurden speziell entwickelt, um die Limitierungen klassischer STP-Topologien zu umgehen. Gemeinsam ist ihnen das Ziel, alle redundanten Pfade aktiv zu nutzen – unter Beibehaltung der Einfachheit von Layer 2.

  • FabricPath (Cisco): basiert intern auf IS-IS-Routing, ersetzt STP durch eine kontrollierte, berechnete Topologie
  • SPB (Shortest Path Bridging, IEEE 802.1aq): unterstützt VLAN-Topologien mit voller Pfadnutzung und MAC-Adressenverteilung via IS-IS
  • TRILL (Transparent Interconnection of Lots of Links): IETF-Standard, nutzt ebenso IS-IS zur Pfadwahl

Heute werden diese Konzepte zwar zunehmend durch VXLAN / EVPN verdrängt, sind aber in vielen Enterprise-Installationen noch im Einsatz – insbesondere FabricPath in Cisco-Umgebungen.

Diese Technologien basieren häufig auf IS-IS oder ähnlichen Link-State-Protokollen, um Pfade zu berechnen. Wer sich mit diesen Routingkonzepten vertraut machen möchte, findet praxisnahe Erklärungen im Beitrag
Wenn Router Entscheidungen treffen – Routingprotokolle im Cisco Netzwerk verstehen

SD-Access, SD-LAN – Topologien kontrolliert durch Software

Software-defined Networking (SDN) geht noch einen Schritt weiter: Statt eine Topologie zu erkennen und abzusichern (wie STP), wird sie zentral geplant und durchgesetzt.

  • In Cisco-Umgebungen übernimmt z.B. das DNA (Digital Network Architecture) Center als SDN-Controller die Netzlogik
  • Segmentierung, Routing, Zugangskontrolle und Failover sind Policy-gesteuert
  • STP spielt nur noch auf Edge-Ports eine Rolle – innerhalb der Fabric wird es nicht mehr benötigt

Beispielanwendung: In einem SD-Access-Fabric verbinden sich alle Geräte über eine VXLAN-basiertes Overlay mit zentraler Steuerung. STP ist auf den Uplinks deaktiviert – auf Access-Ports nur als Backup aktiv.

Fazit:
STP hat seine Aufgabe erfüllt – heute übernehmen Overlays, Fabric-Technologien und Controller-basierte Modelle seine Rolle in einer deutlich flexibleren, sichereren und leistungsfähigeren Form.

Wie geht man heute mit STP in Fabrics um?

In modernen Fabric-Architekturen hat STP seinen zentralen Platz verloren – ersetzt durch Overlay-Kontrollprotokolle wie BGP-EVPN, durch Policy-Controller oder durch deterministische Shortest-Path-Algorithmen. Dennoch verschwindet STP nicht vollständig – es wird strategisch begrenzt, lokalisiert oder als Sicherung im Edge-Bereich beibehalten.

Typische STP-Strategien in modernen Umgebungen:

  • BPDU-Filter und Root Guard verwenden, um die STP-Ausbreitung bewusst zu kontrollieren.
  • MST (Multiple Spanning Tree) gezielt einsetzen in Übergangsphasen oder in Umgebungen, in denen VLAN-Instanzen gruppiert und zentral gesteuert werden.
  • STP deaktivieren auf Core- und Fabric-Switches, wenn alle Verbindungen Layer 3-basiert oder policy-gesteuert sind (z.B. in VXLAN-EVPN-Designs oder SD-Access).
  • STP passiv halten auf Edge-Ports – z.B. mit PortFast, Loop Guard und BPDU Guard, um unbeabsichtigte Loops an Endgeräten zu verhindern.

STP bleibt relevant – aber mit klarer Rolle:

  • An klassischen Access-Ports, an denen keine Fabric-Logik greift, ist STP weiterhin notwendig, um physikalische Fehler oder Fehlkonfigurationen abzufangen.
  • In hybriden Netzen, die aus klassischen Switchen und SDN-Komponenten bestehen, sorgt STP auf Alt-Segmenten für Kompatibilität und Schutz.
  • In Migrationsszenarien wird STP oft als Übergangstechnologie verwendet – z.B. bei der Ablösung von PVST+ durch MST oder bei der Integration klassischer VLAN-Segmente in eine Overlay-Fabric.

Best Practices im Fabric-Zeitalter:

Spanning Tree verschwindet nicht vollständig – aber es verliert seine zentrale Steuerungsfunktion. Stattdessen wird es gezielt nur noch dort aktiviert, wo es wirklich benötigt wird: an den Netzrändern, an Übergabepunkten oder in hybriden Umgebungen mit Altkomponenten.

Die folgende Übersicht zeigt, wo STP heute noch eine Rolle spielt – und wie es im Kontext moderner Netzarchitekturen eingesetzt werden sollte, um Stabilität und Sicherheit zu gewährleisten:

Bereich

Empfehlung

Access-Edge

PortFast, BPDU Guard, Loop Guard – aber kein STP-Flooding

Fabric-Kern

STP deaktivieren, Overlay kontrolliert per Controller

Hybrid-Topologien

MST als Bindeglied zwischen Legacy- und Fabric-Welt

Übergabepunkte

Root Guard und BPDU-Filter nutzen

Tipp für Fortgeschrittene
STP sollte heute nicht mehr als automatisches Loop-Präventionswerkzeug, sondern als gezielt eingesetztes Sicherungsnetz verstanden werden – lokal begrenzt, aber bewusst konfiguriert.

Hinweis zur Prüfungsrelevanz

Dieser Abschnitt behandelt Themen, die über das klassische CCNA-Niveau hinausgehen. Konzepte wie VXLAN / EVPN, FabricPath, SD-Access oder Overlay-Control-Planes mit BGP gehören zur Welt der CCNP-Enterprise-Technologien oder in das Umfeld moderner Rechenzentrumsdesigns.

Ziel dieser Erweiterung ist es, interessierten Leser:innen einen Blick über den Tellerrand zu ermöglichen – und zu zeigen, wie sich das STP-Konzept in modernen Netzwerkarchitekturen weiterentwickelt oder ersetzt wird.

Wer gezielt auf die CCNA-Zertifizierung hinarbeitet, sollte sich vor allem auf folgende Themen konzentrieren:

  • STP, RSTP, PVST+
  • Root Bridge, Timer, Konvergenz
  • Portrollen, Zustände und BPDU-Verhalten
  • Sicherheitsfunktionen wie BPDU Guard, Root Guard, Loop Guard
  • Grundprinzipien von EtherChannel und LACP

Die weiterführenden Technologien sind nicht prüfungsrelevant, bieten aber eine solide Orientierung für den nächsten fachlichen Schritt – sei es im Berufsalltag, in Projekten oder im Rahmen einer CCNP-Weiterbildung.

Fazit – Spanning Tree verstehen, nutzen, beherrschen

Das Spanning Tree Protocol (STP) ist mehr als ein Kapitel im CCNA-Curriculum – es ist ein zentraler Baustein historischer und moderner Netzwerke. Wer STP, RSTP, PVST+ und deren Sicherheitsmechanismen versteht, erkennt schnell:

Netzwerkstabilität beginnt mit Kontrolle über Pfade, Redundanz und Verhalten im Fehlerfall.

STP hat sich über Jahrzehnte bewährt, wurde stetig weiterentwickelt und ist in vielen Netzdesigns nach wie vor unverzichtbar – sei es als aktives Protokoll oder als Schutzschicht im Edge-Bereich. Gleichzeitig zeigen Technologien wie VXLAN / EVPN, SD-Access und FabricPath, dass Netzwerke heute anders gedacht werden – segmentiert, softwaregesteuert, loopfrei durch Design.

Zusammengefasst

  • STP (802.1D) legt das Fundament – aber RSTP (802.1w) ist heute Standard
  • Mit PVST+ und Rapid PVST+ nutzt Cisco pro VLAN separate STP-Instanzen – leistungsfähig, aber ressourcenintensiv
  • MST skaliert für große Netze – mit Instanz-Gruppen und VLAN-Mapping
  • EtherChannel verhindert Blocking – aber nur bei korrekter Konfiguration und Protokollabstimmung (LACP, PAgP)
  • Sicherheitsmechanismen wie PortFast, BPDU Guard, Root Guard und UDLD schützen gegen Konfigurationsfehler und Angriffe
  • In modernen Architekturen wird STP lokalisiert oder ersetzt – durch Overlay-Technologien und zentrale Steuerung
  • Wer STP versteht, kann Netzwerke nicht nur betreiben – sondern zukunftsfähig gestalten

Quellen und weiterführende Dokumentation

Für die Inhalte dieses Beitrags wurden neben eigener Praxiserfahrung und laborgestützten Szenarien auch folgende offizielle und technische Quellen herangezogen:

  • Cisco Systems:
    Spanning Tree Protocol – Übersicht und Dokumentation
  • Wendell Odom:
    CCNA 200-301 Official Cert Guide, Volume 1 (2nd Edition), 2024 – Kapitel zu STP, RSTP, EtherChannel und Sicherheitsfunktionen
  • IEEE Standards:
    • IEEE 802.1D – Spanning Tree Protocol
    • IEEE 802.1w – Rapid Spanning Tree Protocol
    • IEEE 802.1s – Multiple Spanning Tree
    • IEEE 802.3ad – Link Aggregation Control Protocol (LACP)

Eigene Beiträge mit thematischem Bezug: