11.8 Netzwerkschleifen in der Praxis: Einfaches STP-Fallbeispiel

Netzwerkschleifen gehören zu den kritischsten Problemen in geswitchten Ethernet-Netzen. In der Theorie ist schnell erklärt, dass redundante Layer-2-Verbindungen ohne Schutzmechanismus gefährlich sind. In der Praxis wird das Thema aber oft erst dann wirklich verständlich, wenn man ein konkretes Beispiel betrachtet. Genau hier hilft ein einfaches STP-Fallbeispiel. Es zeigt anschaulich, warum Schleifen entstehen, welche Symptome im Netzwerk auftreten und wie das Spanning Tree Protocol, kurz STP, diese Situation kontrolliert. Wer einmal nachvollzogen hat, wie ein kleines Switch-Netz ohne STP außer Kontrolle gerät und wie STP dieselbe Topologie stabilisiert, versteht einen großen Teil der praktischen Bedeutung dieses Protokolls.

Warum ein Praxisbeispiel für STP so hilfreich ist

Begriffe wie Root Bridge, Root Port, Designated Port oder Blocking wirken auf Einsteiger oft abstrakt. Das liegt nicht daran, dass die Konzepte besonders kompliziert wären, sondern daran, dass sie sich erst im Zusammenhang mit einer realen Topologie wirklich erschließen. Ein einfaches Fallbeispiel macht sichtbar, was STP im Alltag tatsächlich leistet.

In der Praxis geht es dabei nicht nur um Theorie, sondern um sehr konkrete Probleme:

• redundante Verbindungen zwischen Switches
• unerwartete Broadcast-Stürme
• MAC-Adress-Instabilität
• Ausfälle durch falsch gepatchte Leitungen
• Portblockierungen durch STP, die zunächst „komisch“ wirken, aber technisch sinnvoll sind

Ein gutes STP-Fallbeispiel zeigt also nicht nur, was STP ist, sondern warum das Protokoll in echten Netzwerken unverzichtbar ist.

Das Ausgangsszenario: Ein kleines redundantes Switch-Netz

Für das Beispiel betrachten wir drei Switches in einem kleinen Unternehmensnetz:

• SW1
• SW2
• SW3

Diese drei Switches sind über Uplinks miteinander verbunden. Das Design ist bewusst redundant aufgebaut, damit beim Ausfall eines Links die Verbindung nicht komplett unterbrochen wird.

Physische Verkabelung im Beispiel

• SW1 ist mit SW2 verbunden
• SW2 ist mit SW3 verbunden
• SW1 ist zusätzlich direkt mit SW3 verbunden

Physisch entsteht dadurch eine Dreiecksstruktur. Genau solche Topologien sind in realen Netzen nicht ungewöhnlich. Sie bieten Redundanz, aber auch das Risiko einer Layer-2-Schleife.

Das VLAN im Beispiel

Alle drei Switches transportieren VLAN 10 für Benutzergeräte. Damit befinden sich die relevanten Ports derselben Layer-2-Domäne. Broadcasts und Unknown-Unicast-Traffic in VLAN 10 können also grundsätzlich über alle drei Switches laufen.

Was ohne STP passieren würde

Wenn in dieser Dreiecks-Topologie alle drei Links gleichzeitig aktiv wären und kein Spanning Tree Protocol arbeiten würde, entstünde eine Netzwerkschleife. Das klingt zunächst harmlos, ist aber in Ethernet-Netzen äußerst problematisch.

Der erste kritische Moment: Ein Broadcast

Ein Host in VLAN 10 sendet beispielsweise eine ARP-Anfrage als Broadcast. Der Broadcast erreicht SW1. Weil Broadcasts an alle relevanten Ports im VLAN weitergegeben werden, sendet SW1 diesen Frame sowohl zu SW2 als auch zu SW3.

Nun passiert Folgendes:

• SW2 empfängt den Broadcast und floodet ihn weiter
• SW3 empfängt ebenfalls den Broadcast und floodet ihn weiter
• Beide Switches senden den Frame auch wieder zurück in Richtung der anderen Verbindungen
• SW1 erhält neue Kopien desselben Broadcasts
• Der Kreislauf beginnt von vorne

Da Ethernet-Frames auf Layer 2 keinen TTL-Wert besitzen, werden sie nicht einfach nach einigen Runden verworfen. Der Broadcast vervielfältigt sich immer weiter. Es entsteht ein Broadcast-Sturm.

Weitere Folgen ohne STP

Die Schleife erzeugt nicht nur Broadcast-Traffic. Es treten meist mehrere Probleme gleichzeitig auf:

• extrem hohe Last auf Uplink-Ports
• Switches lernen MAC-Adressen ständig an anderen Ports
• Unicast-Weiterleitung wird instabil
• Endgeräte erhalten mehrfach identische Frames
• das Netzwerk wird langsam oder fällt vollständig aus

Genau dieses Risiko macht STP so wichtig.

Wie STP dasselbe Netzwerk stabilisiert

Jetzt betrachten wir dieselbe Topologie, aber mit aktivem Spanning Tree Protocol. STP erkennt, dass die physische Verkabelung redundante Pfade enthält, und berechnet daraus eine logisch schleifenfreie Struktur.

Dafür führt STP mehrere Schritte aus:

• Es wählt eine Root Bridge.
• Jeder Nicht-Root-Switch bestimmt seinen Root Port.
• Pro Segment wird ein Designated Port festgelegt.
• Ein redundanter Port wird blockiert, damit kein Kreis entsteht.

Physisch bleibt die Dreiecksverkabelung erhalten. Logisch wird aber einer der drei Wege deaktiviert. Das Netz bleibt redundant, aber schleifenfrei.

Schritt 1: STP wählt die Root Bridge

Angenommen, SW1 gewinnt die Root-Bridge-Wahl. Das kann passieren, weil SW1 die niedrigste Bridge ID besitzt, also die günstigste Kombination aus Priority und MAC-Adresse.

Damit ist SW1 der logische Mittelpunkt der STP-Topologie. Alle anderen Switches orientieren sich von jetzt an an SW1.

Was das konkret bedeutet

• SW1 ist Root Bridge für VLAN 10
• SW2 und SW3 suchen jeweils den besten Pfad zu SW1
• Auf SW1 sind die relevanten aktiven Ports Designated Ports

Die Wahl der Root Bridge ist der erste entscheidende Schritt, weil sich daraus die weiteren Portrollen ergeben.

Schritt 2: SW2 und SW3 bestimmen ihre Root Ports

Da SW1 Root Bridge ist, benötigen SW2 und SW3 jeweils einen besten Weg zu SW1. Der Port, der diesen Weg bereitstellt, wird Root Port genannt.

Im Beispiel

• Auf SW2 wird der direkte Uplink zu SW1 Root Port
• Auf SW3 wird der direkte Uplink zu SW1 ebenfalls Root Port

Diese beiden Ports sind damit die bevorzugten Wege der beiden Switches in Richtung Root Bridge.

Warum nicht der Pfad über den dritten Switch?

STP vergleicht Pfadkosten. In unserem einfachen Beispiel ist der direkte Weg zu SW1 günstiger als der Weg über einen Umweg durch einen anderen Switch. Deshalb gewinnen die direkten Links.

Schritt 3: Die Verbindung zwischen SW2 und SW3 wird bewertet

Jetzt bleibt noch der dritte Link im Dreieck: die direkte Verbindung zwischen SW2 und SW3. Dieser Link ist aus Sicht der Schleifenvermeidung redundant, denn beide Switches haben bereits je einen aktiven Weg zur Root Bridge über SW1.

STP muss deshalb entscheiden, welcher Port auf diesem Segment aktiv bleiben darf und welcher blockiert werden muss.

Designated Port und blockierter Port

Für das Segment zwischen SW2 und SW3 wird einer der beiden Ports als Designated Port bestimmt. Der andere Port wird blockiert.

Angenommen:

• SW2 gewinnt auf diesem Segment den Designated-Port-Vergleich
• Der zugehörige Port auf SW3 wird blockiert

Damit entsteht eine logische Baumstruktur:

• SW1 zu SW2 aktiv
• SW1 zu SW3 aktiv
• SW2 zu SW3 nur auf einer Seite aktiv, auf der anderen blockiert

Die Schleife ist damit beseitigt.

Wie das Netzwerk jetzt mit STP-Verhalten arbeitet

Mit der aktiven STP-Topologie kann derselbe Broadcast aus unserem Beispiel sicher verarbeitet werden. Der Host sendet wieder eine ARP-Anfrage in VLAN 10. Der Frame erreicht SW1 und wird an die aktiven Pfade weitergegeben. Weil der redundante Port zwischen SW2 und SW3 blockiert ist, kann der Broadcast nicht im Kreis laufen.

Das Verhalten ist nun kontrolliert:

• Broadcasts werden nur entlang der aktiven Baumstruktur verteilt
• Es gibt keinen geschlossenen Kreis mehr
• MAC-Adressen werden stabil gelernt
• Das Netz bleibt performant und erreichbar

Genau das ist der Kernnutzen von STP.

Was passiert bei einem Link-Ausfall im Beispiel?

Der eigentliche Vorteil der Redundanz zeigt sich erst im Fehlerfall. Angenommen, der direkte Link zwischen SW1 und SW3 fällt aus. Ohne Redundanz wäre SW3 nun vom Root getrennt. Mit STP kann jedoch der zuvor blockierte Reservepfad aktiviert werden.

Die Umschaltung

• STP erkennt, dass der bisherige Root Path von SW3 ausgefallen ist
• Der zuvor blockierte Port auf der Verbindung zu SW2 wird neu bewertet
• Dieser Port kann nun in einen aktiven Zustand wechseln
• SW3 erreicht die Root Bridge jetzt über SW2

Damit bleibt die Verbindung bestehen, obwohl ein Link ausgefallen ist. Genau das zeigt, dass STP Redundanz nicht abschafft, sondern kontrolliert nutzbar macht.

Welche Portrollen im Beispiel auftreten

Das Fallbeispiel macht die wichtigsten STP-Portrollen sehr anschaulich. Für VLAN 10 ergeben sich in unserem Szenario typischerweise folgende Rollen:

Auf SW1 als Root Bridge

• Ports zu SW2 und SW3: Designated Ports

Auf SW2

• Port zu SW1: Root Port
• Port zu SW3: Designated Port oder blockiert, je nach Vergleich

Auf SW3

• Port zu SW1: Root Port
• Port zu SW2: blockierter Port oder Alternate Port bei RSTP

Diese Portrollen sind nicht zufällig, sondern ergeben sich logisch aus Root Bridge, Pfadkosten und Segmententscheidungen.

Welche Portzustände man im Beispiel erwarten würde

Neben den Portrollen sind auch die Portzustände wichtig. In klassischem STP wären die aktiven Ports typischerweise im Zustand Forwarding. Der redundante, nicht genutzte Port befindet sich im Blocking-Zustand. Bei RSTP würde man häufig von Discarding sprechen.

Praktisch relevant im Beispiel

• aktive Uplinks: Forwarding
• redundanter Reservepfad: Blocking oder Discarding

Gerade für Einsteiger ist wichtig: Ein blockierter Port ist in diesem Szenario kein Fehler, sondern genau die Schutzfunktion, die das Netz stabil hält.

Was man im Betrieb beobachten würde

Wenn man dieses Beispiel auf Cisco-Switches umsetzt, lassen sich die STP-Entscheidungen sehr gut in der CLI prüfen. Das macht das Fallbeispiel auch praktisch für Labor und Fehlersuche nützlich.

Wichtige Cisco-Befehle

show spanning-tree

Dieser Befehl zeigt die Root Bridge, Portrollen und Portzustände.

show spanning-tree vlan 10

In VLAN-basierten Umgebungen wie PVST oder Rapid-PVST ist diese Ausgabe besonders wichtig.

show interfaces status

Damit lässt sich kontrollieren, ob die Ports physisch connected sind. Ein Port kann physisch aktiv sein und dennoch logisch durch STP blockiert werden.

show mac address-table

Mit diesem Befehl kann man nachvollziehen, dass MAC-Adressen stabil gelernt werden, solange STP korrekt arbeitet.

Wie dasselbe Fallbeispiel ohne STP im Troubleshooting wirken würde

Gerade in der Praxis ist es wichtig, die Symptome einer Schleife zu erkennen. Nehmen wir an, im gleichen Netzwerk wäre STP deaktiviert oder funktionslos. Dann würden sich typische Anzeichen zeigen:

• extrem hohe Auslastung auf den Uplink-Ports
• Netzwerk langsam oder instabil
• Clients verlieren DHCP oder ARP-Auflösung
• MAC-Adressen erscheinen ständig auf wechselnden Ports
• Broadcast-Traffic nimmt massiv zu

Das Fallbeispiel zeigt also nicht nur, wie STP funktioniert, sondern auch, woran man das Fehlen von STP oder eine Schleifenstörung im Alltag erkennen kann.

Welche typischen Fehler im Praxisbeispiel auftreten könnten

Auch in einem kleinen STP-Szenario kann es zu Konfigurationsfehlern kommen, die das Verhalten verändern oder unerwartete Ergebnisse erzeugen.

Root Bridge wurde nicht bewusst geplant

Wenn die Prioritäten nicht gesetzt werden, kann ein ungeeigneter Switch Root Bridge werden. Das verändert die aktive Topologie und kann unlogische Pfade erzeugen.

PortFast auf dem falschen Port

Wenn ein Uplink-Port fälschlich wie ein Endgeräteport behandelt wird, kann das das sichere STP-Verhalten beeinträchtigen.

BPDU Guard am falschen Ort

Würde BPDU Guard auf einem echten Switch-Uplink aktiviert, könnte dieser Port bei normalen BPDUs in err-disabled gehen.

Ungeplante zusätzliche Verbindung

Wird im Beispiel ein vierter Link ergänzt, ohne das Design und STP-Verhalten zu berücksichtigen, kann sich die Topologie unerwartet ändern.

Warum dieses Beispiel so typisch für echte Netzwerke ist

Das Dreiecksbeispiel wirkt zunächst wie ein Laborszenario, ist aber in der Realität sehr nah an typischen Unternehmensnetzen. Redundante Verbindungen zwischen Access-, Distribution- oder kleinen Standort-Switches sind völlig normal. Genau deshalb gehören STP und seine Portentscheidungen zum Alltag eines Network Engineers.

• Redundanz ist in echten Netzen gewünscht
• Schleifen müssen trotzdem verhindert werden
• STP ist die klassische Lösung dafür
• Root Bridge, Root Port und blockierte Ports sind normale Bestandteile des Betriebs

Wer dieses einfache Fallbeispiel versteht, hat bereits ein sehr gutes Fundament für komplexere STP-Designs.

Typische Anfängerfehler beim Verständnis dieses STP-Falls

„Ein blockierter Port ist kaputt“

Nein. Im Beispiel ist der blockierte Port gerade der Beweis dafür, dass STP korrekt arbeitet und die Schleife verhindert.

„Mehr aktive Links wären besser“

Ohne Schleifenschutz wäre das gefährlich. Redundanz ist nur sinnvoll, wenn sie logisch kontrolliert wird.

„Wenn alle Kabel richtig stecken, kann keine Schleife entstehen“

Gerade korrekt gesteckte redundante Kabel erzeugen auf Layer 2 das Schleifenrisiko, wenn STP fehlt oder falsch arbeitet.

„STP ist nur Theorie für Prüfungen“

Das Fallbeispiel zeigt das Gegenteil: STP ist ein praktischer Schutzmechanismus, ohne den redundante Switch-Netze schnell instabil würden.

Warum dieses Thema für CCNA und Praxis so wichtig ist

Ein einfaches STP-Fallbeispiel verbindet mehrere Kernkonzepte der Netzwerktechnik auf sehr anschauliche Weise: Redundanz, Schleifenvermeidung, Root Bridge, Root Port, Designated Port, blockierte Ports und Topologieänderungen im Fehlerfall.

• Es macht die Logik von STP greifbar.
• Es zeigt den praktischen Nutzen redundanter Pfade.
• Es erklärt, warum blockierte Ports normal und sinnvoll sind.
• Es hilft bei der Fehlersuche in realen Layer-2-Netzen.
• Es bildet eine starke Grundlage für weiterführende Themen wie RSTP, Root-Bridge-Planung und STP-Schutzfunktionen.

Wer dieses Praxisbeispiel sauber nachvollziehen kann, versteht nicht nur einzelne STP-Begriffe, sondern das grundlegende Zusammenspiel von Redundanz und Schleifenschutz in modernen Switch-Netzen. Genau dieses Verständnis ist entscheidend für CCNA, CCNP und den täglichen Betrieb professioneller Ethernet-Infrastrukturen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.