STP Erklärung?
Wie funktioniert STP und was genau macht es?
3 Antworten
Es dient dazu einen Spannbaum zu berechnen.
Ich höre schon die Frage, was ist ein Spannbaum?
Ein Spannbaum eines Graphens G, ist ein Baum, der jeden Knoten des Graphen umfasst, aber zugleich zyklenfrei ist.
Eine minimaler Spannbaum wäre jener, mit minimalem Kantengewicht.
-----
Wozu ist das wichtig? Nehmen wir an innerhalb eines physischen Netzes, linke ich mehrere Switches an ein Core Switch, zeitgleich verbinde ich sie untereinander. Nun gibt es mehrere Wege die Pakete zu senden, es gibt Zyklen. (Das erhöht grundlegend die Robustheit ggü Ausfällen).
Wird ein BC gesendet, dann wird dieser an alle Stationen weitergeleitet, indem jeder Switch ihn auf allen Ports raussendet (außer Eingangsport). In einem Zyklus sieht also auch jeder Siwtch das Paket immer wieder, weil es kreist - Es kommt zu einem anschwellen der Paketlast, da bei jedem sehen wieder eine Replikation auf alle Ports stattfindet. Das ist ein Broadcast-Storm.
Was ich also möchte:
Aus der Topologie des Netzes einen Spannbaum machen, der dafür sorgt, daß die Topologie zyklenfrei ist. Das macht STP.
https://de.wikipedia.org/wiki/Spanning_Tree_Protocol
beschreibt die Prozesur ausführlich. Vom Überfliegen her würde ich sagen, das klassische STP scheint ein Kruskalalgorithmus zu sein.
STP = Spanning Tree Protocol
Im Ethernet gibt es keine maximale Lebensdauer eines Frames. So etwas wie die TTL im IP-Paket gibt es nicht. Baut man eine redundante Struktur auf, entstehen unweigerlich Schleifen. Die Folge ist, dass die Frames unendlich kreisen, die Leitungen verstopfen und die MAC-Adress-Tabelle ständig umgeschrieben wird.
Die Lösung ist der Spanning Tree. Damit wird eine Baumstruktur im Netz errechnet, die zwangsläufig schleifenfrei ist. Dazu wird ein Wurzel ermittelt (Root Bridge) und Links, die zu einer Schleife führen, blockiert. Fällt ein Link aus, wird der Baum neu errechnet.
Sofern du mit STP das Spanning Tree Protocol meinst dann würde ich dich hier zunächst auf den Wikipedia Artikel dazu weiterleiten.
Kurz gesagt verhindert es aber Broadcast Storms in einem Netzwerk indem es dynamisch einen Baum aufbaut welcher die Nachrichten entlang des optimalen Pfades (kleinste Pfadkosten) entlang des Netzwerkes schickt. Das senkt zum einen die Latenz und zum anderen verhindert es Broadcaststorms weil die Router verhindern dass sie Broadcasts entlang eines redundanten Pfades in Richtung Sender zurückleiten.
Ich glaube das STL die Route mit der geringsten Anzahl von Hops wählt, was natürlich nicht die günstigste Route bezogen auf die Latenz ist.
Die günstigste Route bezogen auf die Latenz muss aber natürlich auch nicht die günstigste Route bezogen auf den Durchsatz sein.
Also die Frage nach der günstigsten Route ist zugleich immer auch eine Frage der Metrik die man zu minimieren versucht.
Ich bin auf dem Gebiet kein Experte, aber in meinem Kopf ist das Funktionsprinzip nach Kosten. Also ein Interface mit 100MBit/ hat einen Preis von 19, ein GBit/s von 4 und ein 10Gbit/s von 2. Und man nimmt dann die günstigste Route. Also würde eine Route z.B. mit 4 GBit/s-Links hintereinander über die eine direkte Route mit 100MBit/s bevorzugt werden.
Bei den Preisen bin ich mir nicht sicher.
Es kann durchaus sein, dass STL hier auch auf Kosten basiert. Bei symmetrischen Netzwerken reduziert es sich natürlich dann auf die Hops.
Nur muss wie gesagt die Route mit den kleinstens Kosten nicht immer die günstigste in jedem Hinblick sein. Die Interfacekosten verwenden eben den Durchsatz als Metrik.
Natürlich kanns sein dass STL gar keine Metrik über die Hops erstellen kann, so genau kenne ich es nicht, aber Ethernet Frames haben ja an sich keinen Hop Zähler.
Der Baum wird anhand minimaler Kosten aufgebaut.
Die Pfadkosten ist die Summe der Linkkosten. Neben IEEE-Vorgaben können abweichende Kosten vergeben werden, um z.B. bei gleichwertigen Pfaden einen zu priorisieren.
Oder um z.B. erhöhten Kosten bei verschiedenen WAN-Links Rechnung zu tragen.
Gibt es dann auch eine Kostenfunktion welche auf der Latenz und nicht auf dem Durchsatz basiert?
Die Linkkosten basieren ja meines wissens rein am Durchsatz der Verbindung.
AFAIK beim klassischen STP nicht. Wenn ich mir die Vorgabewerte anschaue, sehe ich z.B. nichtmal, daß ein Trunk niedrigere Kosten erzeugt, obwohl er nen höheren Durchsatz hat.
Auch SPB (802.11aq) scheint das nicht geändert zu haben, auf den ersten Blick. Für Latenzen wirst Du also im ZWeifelsfall manuell eingreifen müssen.
Andererseits bedenke, die Medienlatenz ist mit 3us bei Kupfer eh sehr überschaubar, interessant wären hier höchstens die zwischenliegenden Bridges. Aber eine weitere Bridge bedeutet ja gerade zusätzliche Linkpfadkosten.
Wenn ich jetzt mal Long-Haul Glas ausschließe, gibt es kaum Szenarien, bei denen die Letenz auf L2 ausschlaggebend sein könnte (ggü. dem Durchsatz).
Und dann wird man wohl im Zweifelsfall manuell eingreifen müssen.
Mir würden hier auch nur dynamische Latenzen auf Pfaden einfallen die eben durch das Buffering bei sehr vielen kleinen Paketen entstehen. Dazu müsste aber STP wohl auch dynamisch die vorraussichtliche Latenz in einem Pfad erkennen können.
Vor allem müßte es auch schnell genug auf die Veränderung reagieren können. Was nutzt es unterm Strich, wenn die Buffer in einigen ms geleert sind, aber Topologieaktualisierungen Sekunden benötigen.
Ich habe gerade nochmal aus Interesse geschaut, für nen 64 Byte-Paket mußt Du als Bridgelatenz rechnen:
Bei 100m 12-13us, 1G ~4us, 10 ~2us.
Ein 100m link wird mit 19 bewertet ein 1g mit 4 (bei STP).
Wenn also der 100m Links einem 5-Segment GBit-Pfad vorgezogen würde, müßte ich vielleicht intervenieren, falls ich wirklich so ne Konstruktion habe.
------
Wo siehst Du bei kleineren Paketen in Zusammenhang mit dem Buffer denn Latenzprobleme, wenn ich fragen darf?
Naja das Senden von kleinen Paketen stellt aufgrund der Busarbitrierung und des größeren Overheads des Ethernetheaders größere Kosten dar als ein einzelnes großes Paket.
Wenn ich also 100*10 Byte übertragen muss und diese Pakete im Buffer stehen und mein Paket an 101 Stelle im Buffer ist dauert das länger diese 100 Pakete zu senden als wenn eben nur 2 Pakete im Buffer sind und die 1kB groß sind.
Dem kann man natürlich mit QOS entgegen wirken aber das ist jetzt mehr eine theoretische Betrachtung.
Humm, ich weiß ehrlich gesagt gar nicht mehr, was ich das letzte mal ein Switch-Design mit BUS gesehen habe.
Normal ist heute eigentlich ne volle Crossbar.
In dem Fall bleibt immer noch der Overhead vom Header. Mit Preamble und Interframe Delay.
Macht ja nichts, die Zeit die sie beim Empfang belegen und beim Senden sind identisch, bzw. stehen im Verhältnis der Datenraten der Ports zueinander.
Wenn ich irgendwo einen Link habe, der mehr Bits transportieren soll, als er kann, dann kommts natürlich auch zu Latenzen, aber das auch unabhängig von den IFGs.
Wenn ich also z.B. 10 x 100m Ports nehme, mit verschiedenen Paketgrößen, dann ist die Menge aller Bits, die ich in einer Zeitscheibe empfangen kann genauso groß wie die Zahl der Bits, die ich auf nem Gbit Link senden kann, inklusive aller Präambeln und IFGs.
--- Verdammich! ---
Sagmal, meinst Du mit dynamischer Latenz etwa den Jitter?
Dann bin ich bei Dir, denn das ist ein Nebeneffekt von Buffering und Intermixing unterschiedlicher Paketgrößen. (Und wird vom Buffer Bloat noch verstärkt)
Ja ich spreche vom Jitter.
Die Latenz eines Pakets hängt eben davon ab wie viele Nachrichten vor diesem Paket im Buffer stehen. Bzw wie viele Bits vor meiner Nachricht zu übertragen sind.
Es ist die günstigste Route oder nicht?