Lernen Sie Radia Perlman kennen und erfahren Sie, wie das Spanning Tree Protocol Ethernet‑Schleifen verhindert, Redundanz ermöglicht und große Netzwerke stabil und zuverlässig machte.
Ethernet begann als einfache Methode, Computer im selben Gebäude zu verbinden. Als es in Büros, auf Campusgelände und in Rechenzentren Einzug hielt, änderten sich die Erwartungen: lokale Netzwerke waren nicht mehr nur „nett zu haben“ — sie wurden zur Infrastruktur für E‑Mail, Dateiablage, Drucker, Telefone und schließlich ganze Geschäftsprozesse. Wenn diese „Rohrleitungen" ausfielen, fiel alles daran angeschlossene mit aus.
Netzwerker lernten außerdem eine harte Zuverlässigkeitslektion: Wenn ein Netz nur einen Pfad zwischen Geräten hat, kann ein einziges defektes Kabel oder ein ausgefallener Switch einen ganzen Bereich lahmlegen. Die offensichtliche Lösung ist Redundanz — zusätzliche Verbindungen und zusätzliche Switches.
Auf Ethernet‑Schicht 2 hat Redundanz allerdings eine gefährliche Nebenwirkung: Schleifen.
Radia Perlman entwarf das Spanning Tree Protocol (STP), den Mechanismus, der Ethernet‑Netzwerke Redundanz erlaubt, ohne dass sie durch Schleifen zusammenbrechen. Ihre Leistung war kein „größerer Durchsatz“ — sondern eine praktische, verteilte Methode, mit der Switches miteinander koordinieren, sich auf eine sichere Weiterleitungsstruktur einigen und sich automatisch an Topologieänderungen anpassen.
STP ist ein System, das man nur bemerkt, wenn es fehlt oder falsch konfiguriert ist. Wenn es funktioniert, sieht nichts besonders aus: Traffic fließt, Links bleiben oben und das Netzwerk toleriert Ausfälle. Es blockiert gerade genug Pfade, um Schleifen zu verhindern, und hält Alternativen bereit, falls ein aktiver Pfad ausfällt.
Wir machen das Problem greifbar, indem wir zeigen, wie eine Ethernet‑Schleife aussieht und warum sie Stürme und Ausfälle verursacht. Dann erklären wir die Kernidee hinter STP — wie es Redundanz erhält, aber Schleifen eliminiert — und beschreiben, auf einfache Weise, wie Switches entscheiden, welche Links weiterleiten und welche in Reserve bleiben. Am Ende haben Sie ein intuitives Modell dafür, warum STP zur Grundlage der Schicht‑2‑Vermittlung wurde und warum Perlmans Entwurf noch zählt, obwohl Ethernet weit über seine frühen Büroumgebungen hinausgewachsen ist.
Frühe Ethernet‑Netzwerke waren oft klein und übersichtlich: ein paar Maschinen auf einem gemeinsamen Segment oder später einige Switches (früher „Bridges“ genannt), die Segmente verbanden. Wenn ein Kabel gezogen wurde, fiel zwar etwas aus — aber der Fehler war leicht zu verstehen.
Als Organisationen mehr Räume, Etagen und Gebäude hinzufügten, wuchs das Netzwerk selten nach einem sauberen Plan. Es wuchs wie ein lebender Organismus: ein neuer Switch hier, ein „Notfallkabel“ da, eine temporäre Lösung, die stillschweigend dauerhaft wurde.
Wenn Netzwerke so wachsen, werden zusätzliche Verbindungen aus praktischen Gründen ergänzt:
Einzeln mag jede Änderung harmlos wirken. Gemeinsam können sie mehrere Pfade zwischen denselben Switches schaffen.
Redundanz ist wünschenswert, weil sie die Verfügbarkeit erhöht. Fällt ein Link aus, kann der Traffic einen anderen Weg nehmen und die Nutzer bleiben produktiv.
Auf Schicht 2 (Switching) war Ethernet jedoch nicht dafür ausgelegt, automatisch „einen“ Pfad zu wählen und die anderen zu ignorieren. Switches leiten Frames basierend auf erlernten Adressen; ohne ein koordinierendes Steuerverfahren können mehrere Pfade eine Schleife bilden.
Das ist die Kernspannung: Mehr Kabel können unbeabsichtigt das Netzwerk zerstören. Ausgerechnet die Verbindungen, die das System sicherer machen sollen, können Bedingungen schaffen, in denen der Traffic endlos zirkuliert, Links und Geräte überlastet und das Netzwerk zusammenbricht. Spanning Tree wurde geschaffen, um die Vorteile von Redundanz zu sichern und gleichzeitig diese selbstverschuldeten, netzweiten Ausfälle zu verhindern.
Eine Ethernet‑Switching‑Schleife entsteht, wenn zwei oder mehr aktive Layer‑2‑Pfade zwischen denselben Switches existieren — oft weil jemand ein Backup‑Kabel hinzufügte, beide Uplinks in dasselbe Netzwerk steckte oder Switches in einem Ring verband, ohne Mechanismus zur Kontrolle. Auf Schicht 2 haben Frames kein Hop‑Limit, daher können sie unendlich lange zirkulieren.
Einige Pakete sollen geflutet werden: Broadcasts (wie ARP‑Anfragen) und „unbekannte Ziel‑Frames“ (wenn ein Switch die MAC‑Adresse noch nicht kennt). In einer Schleife wird so ein gefluteter Frame kopiert und um die Schleife gesendet — dann erneut kopiert, und noch einmal.
Ein einfaches Beispiel: Ein PC fragt per ARP „Wer hat 10.0.0.5?" (Broadcast). Mit einer Schleife wiederholt jeder Switch die Broadcasts über mehrere Ports, und die mehrfachen Kopien treffen wieder bei anderen Switches ein. Sehr schnell verbringen Links und Switch‑CPUs die meiste Zeit damit, Duplikate zu verarbeiten, sodass kaum Platz für echten Traffic bleibt.
Switches lernen Gerätepositionen, indem sie beobachten, über welchen Port eine Quell‑MAC eintrifft. In einer Schleife kann derselbe Host‑Traffic milliseconds Abstand über verschiedene Ports ankommen. Der Switch „ändert ständig seine Meinung“ und überschreibt seine Tabelle immer wieder. Das Ergebnis: Traffic wird an den falschen Port weitergeleitet, dann geflutet und anschließend erneut falsch gelernt.
Diese Effekte führen zu Symptomen, die Administratoren kennen: plötzliche netzwerkweite Verlangsamungen, intermittierende Verbindungsabbrüche, abgebrochene Anrufe, WLAN, das „funktioniert, aber unbenutzbar ist“, und manchmal ein kompletter Ausfall, wenn Switches auslasten und nicht mehr reagieren. Ein einziges versehentliches Patchkabel kann weitaus mehr lahmlegen als nur die zwei damit verbundenen Geräte.
Ethernet gewinnt Resilienz durch mehr als einen möglichen Pfad zwischen Switches. Fällt ein Kabel, kann der Traffic einen anderen Weg nehmen. Der Haken: Zusätzliche Pfade können unbeabsichtigt einen Kreis bilden — und Ethernet‑Frames haben kein „Time to Live“, um sie zu stoppen.
Das Spanning Tree Protocol löst das mit einem einfachen Abkommen: Behalte die redundanten Links physisch verbunden, deaktiviere aber logisch einige von ihnen, sodass das aktive Netz einen schleifenfreien Baum bildet.
Stellen Sie sich eine Stadt vor, die extra Straßen baut, damit Rettungswagen auch bei Sperrungen alle Viertel erreichen. Öffnet die Stadt jede Straße ohne Regeln, entstehen verwirrende Kreisverkehre, in denen Fahrzeuge immer wieder dieselben Blocks umrunden.
STP wirkt wie Verkehrsregelung:
Ein zentraler Teil von Radia Perlmans Entwurf ist, dass STP nicht von einem Controller abhängt, der allen Switches sagt, was zu tun ist. Jeder Switch beteiligt sich, tauscht kleine Nachrichten aus und kommt eigenständig zur gleichen Schlussfolgerung, welche Links weiterleiten und welche in Reserve bleiben.
Das macht STP in der Praxis nützlich: Man kann Switches hinzufügen, Links entfernen oder Ausfälle haben, und das Netzwerk konvergiert zu einem sicheren Weiterleitungsbild.
Richtig eingesetzt liefert STP zwei sonst widersprüchliche Ergebnisse:
STP hat eine Aufgabe: Redundanz erhalten, ohne Traffic endlos zirkulieren zu lassen. Es erreicht das, indem alle Switches sich auf eine einzige „beste“ Menge von Links einigen — den sogenannten Spanning Tree — und die übrigen Links in einen Standby‑Zustand versetzen.
Zuerst wählt STP eine Root‑Bridge, den Switch, der als Referenzpunkt des gesamten Netzes dient. Denken Sie an ihn als „Zentrum der Karte“. Die Root‑Bridge wird durch eine Priorität (konfiguriert oder Standard) und eine eindeutige Switch‑ID bestimmt; die niedrigste Kombination gewinnt.
Jeder Switch fragt nun: „Was ist mein bester Weg zur Root?“ STP vergibt für jeden Link eine Path‑Cost (schnellere Links haben in der Regel geringere Kosten). Jeder Switch summiert die Kosten entlang möglicher Routen und wählt den niedrigsten Gesamtwert als bevorzugten Pfad zur Root.
Der Port, den ein Nicht‑Root‑Switch auf diesem besten Pfad zur Root verwendet, wird sein Root‑Port.
Auf jeder Segmentverbindung zwischen Switches braucht STP genau einen Switch, der den Traffic in Richtung Root weiterleitet. Dieser Weiterleitungsport ist der Designated Port für das Segment. Der Switch, der den niedrigsten Kostenpfad zur Root für dieses Segment ankündigt, erhält die Designated‑Rolle.
Ports, die weder Root‑Port noch Designated Port sind, werden in den Blocking‑Zustand (oder in neueren Varianten einen ähnlichen Nicht‑Forwarding‑Zustand) versetzt. Blocking entfernt nicht das Kabel und vernichtet nicht die Redundanz — es verhindert lediglich, dass dieser Port regulären Ethernet‑Traffic weiterleitet, damit keine Schleife entsteht. Fällt ein aktiver Link aus, kann STP einen Backup‑Pfad wieder freigeben und die Verbindung erhalten.
Betrachten wir ein kleines Netz mit vier Switches:
STP wählt zuerst einen Referenzpunkt: die Root‑Bridge. Jeder Switch sendet eine Kennung (Bridge‑ID) aus, und die niedrigste ID gewinnt.
Angenommen S1 hat die niedrigste Bridge‑ID. Dann ist S1 die Root und alle Switches orientieren sich daran.
Jeder Nicht‑Root‑Switch wählt genau einen Port als Root‑Port: den Port, der den besten Pfad zurück zu S1 bietet.
Für jedes Segment wählt STP eine Seite als Designated Port (die Seite, die für dieses Segment weiterleiten soll). Jeder Port, der weder Root‑Port noch Designated Port ist, wird blocking.
Im Beispiel wird die Verbindung S3–S4 die Schleife durchtrennen. Da S3 den Root bereits über S2 erreicht, kann STP S3s Port zu S4 (oder je nach Tiebreaker S4s Port zu S3) in blocking setzen.
Ergebnis: Alle Kabel sind angeschlossen, aber zwischen beliebigen Punkten gibt es nur noch einen aktiven Pfad — keine Schleife.
Wenn der aktive Pfad (z. B. S2–S3) ausfällt, bewertet STP die Topologie neu. Der zuvor blockierte Link S3–S4 kann in Forwarding wechseln und die Konnektivität via S3 → S4 → S1 wiederherstellen.
Dieser Wechsel ist nicht sofort; STP braucht Zeit zur Konvergenz, um den Forwarding‑Zustand sicher zu aktualisieren, ohne erneut Schleifen einzuführen.
Spanning Tree funktioniert nur, wenn alle Switches im Netz dieselben Regeln akzeptieren. Deshalb sind Standards wichtig: In echten Netzwerken kommen oft Geräte verschiedener Hersteller zum Einsatz, gekauft über viele Jahre hinweg. Ohne ein gemeinsames Protokoll würde eine Marke die „Loop‑Prevention“ einer anderen nicht verstehen, und Redundanz könnte zum Ausfall werden.
Das traditionelle Spanning Tree Protocol ist in IEEE 802.1D definiert. Man muss die Norm nicht im Detail lesen, um davon zu profitieren — der Punkt ist, dass 802.1D den Herstellern eine gemeinsame Sprache gibt, wie Root‑Bridge gewählt, Path‑Costs berechnet und Ports zum Forwarden oder Blockieren bestimmt werden.
Auch wenn man später auf neuere Varianten (wie RSTP oder MSTP) umsteigt, ist der Grund derselbe: Das Verhalten ist standardisiert genug, dass Geräte miteinander koordinieren können, statt zu raten.
Switches koordinieren sich über kleine Kontrollrahmen, sogenannte BPDUs (Bridge Protocol Data Units). Man kann BPDUs als STP‑„Hallo‑Nachrichten“ ansehen: Sie tragen die Informationen, die Switches benötigen, um sich ein gemeinsames Bild der Topologie zu bauen — wer die Root‑Bridge sieht, wie weit sie entfernt ist (Cost) und Timing‑Informationen.
Da BPDUs kontinuierlich ausgetauscht werden, kann STP reagieren, wenn sich etwas ändert. Fällt ein Link aus, ändert sich die BPDU‑Konversation, und die Switches können rekonvergieren und vorher blockierte Pfade eröffnen.
Ein praktisches Problem: Hersteller verwenden oft unterschiedliche Namen für dieselben Einstellungen. Ein Parameter wie „port cost“, „edge/PortFast“ oder „bpdu guard“ kann in verschiedenen Menüs anders bezeichnet sein. Die zugrunde liegenden STP‑Konzepte sind konsistent, aber die Oberflächen‑Vokabeln sind es nicht — deshalb hilft es, Features zurückzuübersetzen in das, was 802.1D erreichen will.
Klassisches STP (IEEE 802.1D) löste Schleifen, konnte aber sehr langsam sein, um nach einem Link‑ oder Switch‑Ausfall wieder zu heilen. Der Grund ist einfach: STP war vorsichtig. Ports gingen nicht sofort ins Forwarding — sie durchliefen zeitgesteuerte Zustände (blocking → listening → learning → forwarding). Mit Standardtimern konnte die Rekonvergenz Dutzende Sekunden dauern (~30–50 s), lange genug, dass Sprachverbindungen abbrechen, Anwendungen timeouts erleben oder Nutzer annehmen, das Netzwerk sei down.
Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) behält das Ziel bei — schleifenfreies Forwarding mit Redundanz — ändert aber, wie Switches sich einigen.
Anstatt lange, feste Timer abzuwarten, nutzt RSTP einen schnelleren Austausch zwischen Switches, um zu bestätigen, welche Ports sicher forwarden können.
Kurz: RSTP blockiert weiterhin die richtigen Links, um Schleifen zu vermeiden — es behandelt Änderungen nur nicht mehr als immer‑worst‑case.
Mit wachsendem Netzwerk wurde ein einziger Baum für alles unpraktisch — besonders bei vielen VLANs und komplexen Topologien. Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) erlaubt mehrere Spanning‑Tree‑Instanzen und die Zuordnung von VLAN‑Gruppen zu diesen Instanzen.
Das ermöglicht:
Die Kernaussage von STP → RSTP → MSTP bleibt: Behalte Redundanz, verhindere Schleifen und stelle Forwarding schneller und vorhersagbarer wieder her.
Der vielleicht unterschätzteste Nutzen von Spanning Tree ist, dass es „zusätzliche Kabel und Switches“ in vorhersehbare Zuverlässigkeit verwandelt. In Unternehmensnetzen — viele Serverschränke, viele Access‑Switches, ständige Umzüge und Änderungen — kann Layer‑2‑Redundanz ein Geschenk oder eine Falle sein. STP macht es wahrscheinlicher, dass es ein Geschenk bleibt.
Große Netzwerke fallen selten wegen eines einzelnen Link‑Ausfalls aus; sie scheitern, weil die Wiederherstellung chaotisch ist. STP hilft, indem es eine kontrollierte Reaktion auf Änderungen ermöglicht:
Viele Organisationen lassen STP aktiviert, auch wenn sie glauben, ihre Topologie sei schleifenfrei. Der pragmatische Grund: Menschen machen Fehler, Dokumentation driftet, und unerwartete Layer‑2‑Pfade entstehen. Mit STP ist ein versehentliches zusätzliches Patchkabel eher ein blockierter Port als ein ausfallendes Gebäude.
Moderne Rechenzentren bevorzugen oft geroutete Leaf–Spine‑Fabrics (Layer 3) oder bestimmte Layer‑2‑Multipath‑Technologien, um Active/Active‑Bandbreite zu erreichen, ohne auf klassische STP‑Konvergenz angewiesen zu sein. Dennoch wird STP (bzw. RSTP/MSTP) weiterhin in Campus‑Netzen, Edge‑Segmenten und als Kompatibilitätsebene dort eingesetzt, wo reines Layer 3 unpraktisch ist.
Auf großer Skala ist STPs Leistung so sehr operativ wie technisch: Es macht Redundanz für gewöhnliche Teams handhabbar, nicht nur für Spezialisten.
STP ist im Konzept simpel — Schleifen verhindern und Backup‑Pfade behalten — aber einige hartnäckige Mythen veranlassen Menschen, STP zu deaktivieren, falsch zu konfigurieren oder „zu optimieren" und so Ausfälle zu provozieren.
Es stimmt, dass moderne Netze häufig auf Layer‑3‑Routing, MLAG und Overlay‑Designs setzen, die den Bedarf an klassischem IEEE 802.1D reduzieren. Trotzdem bietet STP (und seine neueren Varianten) immer noch ein Sicherheitsnetz überall dort, wo Ethernet unbeabsichtigt Schleifen bilden kann: Access‑Switches, temporäre Event‑Netze, Labore, kleine Niederlassungen und überall dort, wo jemand zwei Ports zusammenpatchen könnte, „nur zum Test".
STP zu deaktivieren kann einen harmlosen Verkabelungsfehler in einen Broadcast‑Sturm verwandeln, der ein ganzes VLAN lahmlegt.
Ein blockierter Port ist nicht „tot“. Er ist ein vorvalidierter Standby‑Pfad. STP tauscht etwas aktive Kapazität gegen Stabilität: Fällt der Forwarding‑Link aus, kann der geblockte Link ohne Kabelarbeit die neue Route übernehmen. Teams versuchen manchmal, alle Links zu forcieren, indem sie STP abschalten oder unmanaged Switches hinzufügen. Das mag effizient aussehen — bis die erste Schleife das Netzwerk schmilzt.
Redundanz hilft nur, wenn sie geplant ist. Zusätzliche Querverbinder zwischen Switches ohne Planung erhöhen die Anzahl möglicher Schleifenszenarien und machen STP‑Verhalten schwerer vorhersagbar. Das Ergebnis können unerwartete Verkehrswege, blockierte Uplinks oder längere Rekonvergenzzeiten sein.
Auch mit aktiviertem STP können falsche Einstellungen Schaden anrichten:
Die Quintessenz: STP ist kein bloßes Häkchen — es ist eine Steuerungsebene. Behandeln Sie sie entsprechend: dokumentieren Sie die Absicht und validieren Sie Änderungen, bevor Sie sie breit ausrollen.
STP‑Probleme treten oft als „das Netzwerk ist langsam" auf, bevor jemand erkennt, dass es ein Layer‑2‑Problem ist. Ein paar gezielte Checks können Stunden an Fehlersuche sparen.
Bei einer Ethernet‑Schleife oder STP‑Instabilität sehen Sie häufig:
Beginnen Sie mit den Grundlagen:
Gutes STP‑Hygiene ist vor allem Prozess:
Wenn Sie eine umfassendere Checkliste zur Fehlerisolierung jenseits von STP wünschen, siehe /blog/network-troubleshooting-basics.
STP ist ein gutes Beispiel für „stille Infrastruktur", die auf sehr menschliche Weise versagt: unklare Absichten, undokumentierte Verkabelung, inkonsistente Konfigurationen und improvisierte Fehlerbehebungen. Eine praktische Methode, dieses Risiko zu senken, ist der Aufbau leichter interner Tools und Runbooks rund um Ihre STP‑Betriebsabläufe.
Mit Koder.ai können Teams schnell kleine Web‑Dashboards oder Utilities aus einfachen Chat‑Anfragen erstellen — etwa ein Tool, das Switch‑Ausgaben einliest, die aktuelle Root‑Bridge hervorhebt, unerwartete blockierte Ports markiert oder Topologie‑Änderungsereignisse über die Zeit verfolgt. Da Koder.ai das Exportieren von Quellcode und das Deployen/Hosten von Apps (mit Rollback und Snapshots) unterstützt, lässt sich „tribales Wissen" in einen gepflegten internen Service verwandeln statt in ein einmaliges Skript auf dem Laptop einer Person.
Radia Perlmans Arbeit am Spanning Tree erinnert daran, dass einige der wichtigsten Infrastrukturen nicht spektakulär aussehen — sie verhindern schlichtweg Chaos. Indem sie Ethernet eine praktische Möglichkeit gab, redundante Links zu nutzen, ohne Schleifen zu erzeugen, machte STP „lege einen Backup‑Pfad an" zur sicheren Default‑Option statt zum riskanten Experiment. Das ermöglichte größere, resilientere Layer‑2‑Netze in Unternehmen, auf Campusgeländen und in Rechenzentren.
STP geht davon aus, dass etwas schiefgehen wird: ein Kabel wird falsch gesteckt, ein Switch startet neu, ein Link flackert. Statt darauf zu hoffen, dass Betreiber keine Fehler machen, baut es ein System, das Fehler absorbiert und zu einem sicheren Zustand konvergiert. Die Lehre gilt über Netzwerke hinaus: Behandle Fehlerszenarien als gleichberechtigte Anforderungen.
Spanning Tree blockiert bewusst einige Links, damit das Gesamtnetz stabil bleibt. Diese „verschwendete Kapazität" ist ein Trade‑off zugunsten vorhersagbarem Verhalten. Gute Systeme halten oft Puffer — zusätzliche Zeit, zusätzliche Checks, zusätzliche Schutzschichten — weil das Vermeiden katastrophaler Ausfälle mehr wert ist als das Herauskitzeln des letzten Prozentsatzes an Auslastung.
STP funktioniert, weil jeder Switch denselben verteilten Regeln folgt und kleine Kontrollnachrichten austauscht, um sich auf eine schleifenfreie Topologie zu einigen. Man braucht nicht für jede Änderung einen Operator, der manuell Ports abschaltet. Die Erkenntnis: Wenn viele Komponenten zusammenarbeiten müssen, investieren Sie in Protokolle und Defaults, die das sichere Verhalten zur einfachsten Option machen.
Wenn Sie nur ein paar Dinge behalten, dann diese: Baue Redundanz, erwarte menschliche Fehler und automatisiere die „sichere Wahl". Dieses Mindset — mehr als jede einzelne Technik — erklärt, warum Spanning Tree zum stillen Fundament wurde.
Wenn Sie grundlegende, leicht zugängliche Artikel zu Netzwerkthemen möchten, stöbern Sie in /blog.
Eine Layer‑2‑Schleife entsteht, wenn Switches zwei oder mehr aktive Pfade zwischen denselben Segmenten haben, sodass sich ein Kreis bildet. Da Ethernet‑Frames auf Schicht 2 keine Hop‑Limit besitzen, können geflutete Pakete (Broadcasts und unbekannte Unicasts) endlos zirkulieren und sich vervielfältigen, wodurch Links und Switch‑CPUs überlastet werden.
Redundanz fügt alternative Pfade hinzu, aber ohne Koordination leiten Switches möglicherweise über alle Pfade gleichzeitig. Das erzeugt eine Schleife, in der geflutete Frames wiederholt repliziert werden — Broadcast‑Stürme und instabiles MAC‑Learning sind die Folge. Oft reicht ein zusätzliches Patchkabel, um ein VLAN oder ein ganzes Netzwerk lahmzulegen.
STP lässt redundante Verbindungen physisch bestehen, deaktiviert aber logisch bestimmte Ports, sodass die aktive Topologie ein schleifenfreier Baum wird. Fällt ein aktiver Pfad aus, kann STP einen zuvor blockierten Port in Forwarding schalten, um die Konnektivität wiederherzustellen.
STP wählt eine Root‑Bridge als Referenzpunkt für die gesamte Layer‑2‑Domäne. Die Switches mit der niedrigsten Bridge‑ID (Priorität + eindeutige Kennung) gewinnt. Die Wahl der richtigen Root‑Bridge (typischerweise ein Core-/Distribution‑Switch) sorgt für vorhersehbare und effiziente Pfade.
Jeder Nicht‑Root‑Switch bestimmt einen Root‑Port: den Port mit den geringsten kumulierten Path‑Costs zurück zur Root‑Bridge. Path‑Cost basiert auf der Link‑Geschwindigkeit (schnellere Links haben meist geringere Kosten). Bei Gleichstand werden IDs als Tiebreaker verwendet.
Für jedes Segment zwischen Switches wählt STP genau eine Seite als Designated Port, der für dieses Segment weiterleitet (die Seite mit dem besten Pfad zur Root). Jeder Port, der weder Root‑Port noch Designated Port ist, wird blocking/discarding und damit nicht zum normalen Weiterleiten von Nutzdaten verwendet — so wird die Schleife unterbrochen.
Ein blockierter Port leitet normale Nutzdaten nicht weiter, sodass er nicht Teil einer Layer‑2‑Schleife wird. Das Kabel bleibt physisch angeschlossen und kann weiterhin STP‑Kontrollverkehr (BPDUs) übertragen; bei einer Topologieänderung kann dieser Port jedoch in Forwarding befördert werden.
BPDUs (Bridge Protocol Data Units) sind STP‑Kontrollframes, mit denen Switches Topologieinformationen austauschen: welche Root‑Bridge sie sehen, ihre Path‑Cost zur Root und zeitliche Angaben. Durch kontinuierlichen BPDU‑Austausch erkennen Switches Änderungen und können wieder auf eine sichere, schleifenfreie Topologie konvergieren.
Klassisches STP (IEEE 802.1D) gilt als „langsam“, weil es konservative Timer und Portzustände verwendet — die Rekonvergenz kann Dutzende Sekunden dauern. RSTP (802.1w) beschleunigt das Verfahren mit schnelleren Handshakes und sofortigen Übergängen für bestimmte Ports (z. B. Edge/PortFast), wodurch Ausfallzeiten nach Fehlern deutlich kürzer werden.
Kurzcheck zur Fehlersuche:
Für weitergehende Diagnosen siehe /blog/network-troubleshooting-basics.
