Diskussion:Spanning Tree Protocol

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 3 Jahren von Poc in Abschnitt Nicht unerhebliche Netzlast
Zur Navigation springen Zur Suche springen

Hallo, es ist einfach falsch, dass IEEE 802.1D durch IEEE 802.1w ersetzt wurde, siehe: http://en.wikipedia.org/wiki/IEEE_802.1D

Ausserdem auch eine chronolgische Herleitung von IEEE 802.1D-2004 mit den verschiedenen Zwischenschritten STP->RSTP -> proprietäre RSTP-Varianten-> RSTP 802.1D-2004 -> eRSTP in dem Papier 'Performance of the Rapid Spanning Tree Protocol in Ring Network Topology' aus der Quelle http://www.ruggedcom.com/support/whitepapers/ .

Gruß, Boynk (16:10, 1. Jun. 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)


Was ich erstmal nicht erwähnt habe ist, dass Radia Perlman dann doch zu sehr Frau ist und gleich nach dem Spanning Tree-Algorithmus erstmal ein Gedicht dazu geschrieben hat. Man findet es z.B. hier:

http://home.lbl.gov:8080/~psb/Humor/Algorhyme.html


Ich würde im Artikel zumindest einen Link auf das Gedicht setzen. Ich finds sehr spassig und es sollte nicht untergehen.


Hallo

Eine Frage zum STP. Für die verschiedenen Verbindungen werden ja Kosten berechnet. So ist eine 10Mb/s teurer als eine 100Mb/s und fällt also weg. Wenn nun aber die 100Mb/s Verbindung soweit ausgelastet wird das grad noch 5Mb/s zur verfügung stehen wäre die 10Mb/s Verbindung sinnvoller. Das ist ja irgendwie doof eine 5Mb/s Verbindung zu nutzen wenn man doppelt so viel zur Verfügung hätte. Jedoch würden beim aktivieren der Verbindung Redundante Daten entstehen. Gibts da irgendeine Lösung oder bleibt dies ein ungelöstes Problem?

mfg Roman

Soweit ich weiß ein ungelöstes Problem! Es geht beim Spanning Tree nur um das Verhindern von Schleifen. Außlastung wird in keinster weise berücksichtigt.

Es macht auch überhaupt keinen Sinn, bei 95 Mbps auf die 10 Mbps-Leitung umzuschalten, denn dann hätten wir 85 Mbps zu wenig. Sinnvoll wäre eventuell, sie zu bündeln, aber das ist nicht Aufgabe des STP.

Aber eine Frage macht es nicht sinn den Artikel in irgend einer weise mit "Spanning Tree" und/oder "Spanning Tree Protokoll" zu verknüpfen. Ist schwer den so zu finden da in der Litaratur meist nur "Spanning Tree" angegeben ist.

Gruß Dnik

---

Kosten ermitteln[Quelltext bearbeiten]

Einen schönen guten Abend,

es ist ja die Rede davon, dass die Kosten berechnet werden und anhand deren der Baum aufgebaut wird. Aber wie werden diese Kosten berechnet? --TeeVau 22:26, 17. Okt. 2007 (CEST)Beantworten

Die "Kosten" kommen nicht durch irgendeine Form von Kostenrechnung zustande, sondern sind ein rein aus der Luft gegeriffener Wert, um die zur Verfügung stehenden Pfade zu priorisieren. Wenn man nichts weiter einstellt haben wie im Artikel angedeutet Strecken mit geringerer Bandbreite höhere Kosten als die dicken Leitungen. Es gibt aber nichts, was einen Admin daran hindern würde, die "Kosten" einer 10-MBit-Strecke geringer einzustellen als die einer alternativen Gigabit-Leitung. --Echoray 21:03, 18. Okt. 2007 (CEST)Beantworten

Optimalität[Quelltext bearbeiten]

Hallo zusammen,

beim Lesen des Artikels ist für mich die Frage offen geblieben, inwiefern die Optimierung der Übertragungskosten berücksichtigt wird. Am Beispiel: Wie würde das Netz aussehen, wenn im verlinkten Bild die Verbindung von ID-3 zu ID-4 nur Kosten von 3 hätte? Dann wäre das die günstigste Verbindung zwischen ID-3 und ID-4, bliebe aber ungenutzt, oder?

Vielleicht hat ja jemand, der sich damit auskennt, die Zeit, einen Absatz über solche Probleme (und evtl mögliche Lösungen?) hinzufügen? Es könnten auch die Kosten für die Verbindung im Bild angepasst werden, damit dieser Fall auch abgedeckt ist.

-- Epaminaidos 09:48, 13. Okt. 2009 (CEST)Beantworten

Ich füge hinzu...

Was ich auch nicht ganz verstehe ist:

Die Kommunikation zwischen ID4 und ID5 ist doch jetzt suboptimal, da der optimale Weg geblockt ist. Der optimale Weg wäre hier der direkte, ID4 muss aber über ID1 gehen, was "teurer" ist. Also was jetzt...?

Kann das jemand beantworten?

Ich versuche das mal zu erklären:
Die Pfadkosten aller Teilverbindugnen von einem Port bis zur Root Bridge werden addiert. Derjenige Port mit den kleinsten totalen Pfadkosten in Richtung Root Bridge wird zum Root Port, alle anderen Ports werden zu Blocked Ports. Im Diagramm gibt es zwei mögliche Wege von ID-3 zu ID-1 (Root Bridge):
ID-3 -> ID-2 -> ID-1: Pfadkosten 3 + 1 = 4
ID-3 -> ID-4 -> ID-2 -> ID-1: Pfadkosten 5 + 1 + 1 = 7
Im Diagramm würde der akutelle Root Port demnach auch dann der Root Port bleiben wenn die Pfadkosten auf der Verbindung zwischen ID-3 und ID-4 auf 3 gesenkt würden.
Spanning Tree kann auf lokal optimale Wege (sprich zwischen zwei Bridges) keine Rücksicht nehmen. Solche lokalen Optimierungen führen zu Schleifen im Netzwerk. Und genau diese sollen mit STP verhindert werden.
Bruflu (Diskussion) 13:34, 30. Okt. 2017 (CET)Beantworten

Verlinkungen im Artikel[Quelltext bearbeiten]

Warum enthält der Artikel eigentlich kaum Verlinkungen? --Jim4711 (Diskussion) 14:51, 26. Dez. 2012 (CET)Beantworten

Zeit der Konvergenz[Quelltext bearbeiten]

Im Artikel steht, die Default-Einstellungen würden bedeuten, dass eine Neuberechnung des Spanning Trees 50 Sekunden geht. Unten im Artikel steht jedoch, dass es höchstens 30 Sekunden geht. Was stimmt nun? Die Timer des Forward-Delay gehen zusammen nur 30 Sekunden. (nicht signierter Beitrag von Eluchsinger (Diskussion | Beiträge) 14:02, 3. Jan. 2016 (CET))Beantworten

Nicht unerhebliche Netzlast[Quelltext bearbeiten]

Selbst in großen Netzen mit mehreren Dutzend Switches sind ein Frame pro Switch alle zwei Sekunden vernachlässigbar, selbst in alten Installationen mit nur 100 Mbit/s. Wenn man sich mal einen typischen Paketdump von einem Switchport anschaut, ist der Löwenanteil dessen was an Traffic zu sehen ist, ARP. Ich konnte bei einer raschen Recherche im Netz keine (englischsprachige) Quelle finden, die BPDUs als Netzlast erwähnt: Die Schwierigkeit etwas nicht existentes zu Beweisen vs. WP-Regeln.
Falls keine Einwände bestehen, würde ich den Satz am kommenden Wochenende löschen. --Poc (Diskussion) 14:51, 28. Sep. 2020 (CEST)Beantworten