Wie erstelle ich eine Netzwerktopologie auf der Datenverbindungsschicht, wenn im gewünschten Subnetz nur nicht verwaltete Switches verwendet werden? In dem Artikel werde ich versuchen, diese Frage zu beantworten.
Ich beginne mit der Ursache von LLTR ( Link Layer Topology Reveal ).
Ich hatte ein "Fahrrad" - einen großen Dateisynchronisierer "mit voller Netzwerkgeschwindigkeit", der eine 120-GiB- Datei über Fast Ethernet ( 100 Mbit / s ; 100BASE - TX; Duplex) vollständig auf 1, 10, 30 oder 3 Stunden hochladen kann > 200 Stk . Es war ein sehr nützliches "Fahrrad", weil Die Geschwindigkeit der Dateisynchronisierung war nahezu unabhängig von der Anzahl der PCs, auf die die Datei hochgeladen werden sollte. Alles wäre in Ordnung, aber es erfordert Kenntnisse der Netzwerktopologie für seine Arbeit.
Mehr im Artikel über ihn: Okay, warum mussten Sie eine 120-GiB-Datei über das Netzwerk auf eine solche PC-Menge „fahren“?
Diese Datei war VHD mit dem Betriebssystem, Programmen usw. Die Datei wurde auf dem Mastersystem erstellt und dann auf alle anderen PCs verteilt. VHD war nicht nur eine Möglichkeit, das System an die Ziel-PCs zu liefern, sondern ermöglichte auch die Wiederherstellung des Ausgangszustands des Systems beim Neustart des PCs. Weitere Details im Artikel: „ System Freezing: Die Geschichte des Übergangs vom EWF zum dVHD “.
Sie können die Kette weiter fortsetzen, aber darauf werde ich brechen.
Bestehende Protokolle zur Erkennung der Topologie der Datenverbindungsschicht ( LLDP , LLTD , CDP , ...) erfordern für ihren Betrieb eine ordnungsgemäße Unterstützung aller zwischengeschalteten Netzwerkknoten. Das heißt, sie benötigen mindestens verwaltete Switches, die das entsprechende Protokoll unterstützen. Es gab bereits einen Artikel über Habré, wie diese Protokolle verwendet werden können, um „ die Netzwerktopologie auf den 2/3 Ebenen des OSI-Modells zu bestimmen “.
Was aber, wenn die Zwischenknoten einfache, nicht verwaltete Switches sind?
Wenn Sie daran interessiert sind, wie dies getan werden kann, dann begrüßen Sie bei cat. Ich verspreche die Verfügbarkeit vieler Abbildungen und Beispiele.
{Bildgröße: 924 KiB; Text: 69 KiB; Emoticons: 9 Stück }}
Ein bisschen UserCSS vor dem Lesen
Hinweis : Dieser Spoiler wurde ursprünglich vor dem Kat platziert.
Sicherlich hatte es jeder getan, der die Stile für sich selbst anpassen wollte. Hier ist jedoch ein Teil meines UserCSS. Wichtige Änderungen:
- Das Ende des geöffneten Spoilers ist sichtbar (nützlich, wenn der Spoiler groß ist und Sie den Unterschied im Einzug zwischen dem Haupttext und dem Text im Spoiler nicht sofort bemerken), genauer gesagt, hat der vorherige Frame und Hintergrund des Spoilers zurückgegeben.
- Der Zitatblock kehrte zu seiner vorherigen Form zurück (ich zeigte mehreren Personen, die die russische Sprache nicht verstanden und die neuen „gelben Zitate“ von Habré nicht gelesen hatten, und sie sagten, dies seien kontextbezogene Werbebeilagen ...).
- Die Hauptschriftart, ihre Größe und der Zeilenabstand gingen ebenfalls zurück (IMHO, mit ihnen ist Langtext leichter zu lesen);
- Die Veröffentlichungsbewertung und die Anzahl der Aufrufe wurden entfernt, die Anzahl der hinzugefügten Lesezeichen wurde jedoch beibehalten.
Im Allgemeinen habe ich (mit geringfügigen Änderungen) das vertraute Aussehen der Hauptelemente des Artikels zurückgegeben. Mit diesem Design wurde bereits eine große Anzahl guter Artikel gelesen (angenehme Erinnerungen tauchen auf).
@charset "utf-8"; body { font-family: Verdana,sans-serif !important; } .nav-links__item-link { font-family: Helvetica,Arial,sans-serif !important; } .comment__message, .comment-form__preview { font-family:Arial !important; } .post__text { font-size:13px !important; line-height:1.60 !important; } .post__title-text, .post__title_link { font-family: Tahoma,sans-serif !important; line-height:118% !important; } .post__title-text { font-size:30px !important; } .post__title_link { font-size:26px !important; } .post__text br { line-height:normal !important; } .post__text img { -o-object-fit:contain; object-fit:scale-down; } .post__text h1, .post__text h2, .post__text h3 { font-family: Helvetica,Arial,sans-serif !important; } .post__text h2 { font-size:1.5em !important; } .post__text h3 { font-size:1.375em !important; } .post__text h4, .post__text h5, .post__text h6 { font-family: Verdana,sans-serif !important; font-size:1.125em !important; font-weight:bold !important; } .post__text h5 { color:#3D3D3D !important; } .post__text h6 { color:#5C5C5C !important; } .post__text ul li, .post__text ul ul li, .post__text ul ol li, .post__text ol li, .post__text ol ul li, .post__text ol ol li { line-height:inherit !important; padding:0 !important; } .post__text ul, .post__text ul ul, .post__text ul ol, .post__text ol, .post__text ol ul, .post__text ol ol { margin-left:35px !important; } .post__text ul ul, .post__text ul ol, .post__text ol ul, .post__text ol ol { margin-bottom:9px !important; } .post__text .spoiler .spoiler_title { color:#6DA3BD !important; font-size:inherit !important; font-weight:400 !important; } .post__text .spoiler::before { margin-top:2px !important; } .post__text .spoiler .spoiler_text { color:#666 !important; background:#F9F9F9 !important; border:1px solid #EEE !important; } .post__text .spoiler .spoiler_text hr:first-child, .post__text .spoiler .spoiler_text hr:last-child { display:none !important; } .post__text code { font-size:13px !important; border:1px solid #F2F2F2 !important; border-radius:3px !important; padding:0 0.25em !important; white-space:pre-wrap !important; } .post__text strong > code { font-weight: normal !important; background-color: #F8F8F8 !important; } .post__text pre code { line-height:1.5 !important; background-color:#F8F8F8 !important; border-color:#DDD !important; padding:0.5em 1em !important; white-space:pre !important; overflow-x:auto !important; } .hljs-comment, .hljs-quote { color:#808080 !important; font-style:inherit !important; } .hljs-doctag,.hljs-keyword,.hljs-formula, .hljs-section,.hljs-name,.hljs-selector-tag,.hljs-deletion,.hljs-subst { color:#4d7386 !important; } .hljs-literal{ color:#7296a3 !important; } .hljs-string,.hljs-regexp,.hljs-addition,.hljs-meta-string{ color:#390 !important; } .hljs-built_in,.hljs-class .hljs-title{ color:#968e5b !important; } .hljs-attr,.hljs-attribute,.hljs-variable,.hljs-template-variable,.hljs-type,.hljs-selector-class,.hljs-selector-attr,.hljs-selector-pseudo,.hljs-number{ color:#2f98ff !important; } .hljs-symbol,.hljs-bullet,.hljs-link,.hljs-meta,.hljs-selector-id,.hljs-title{ color:#968e5b !important; } .post__text kbd { display:inline-block !important; padding:0.2em 0.5em 0.3em !important; vertical-align:middle !important; background-color:#FCFCFB !important; border:1px solid #D9D9D9 !important; border-radius:3px !important; border-bottom-color:#C6CBD1 !important; box-shadow:inset 0px -1px 0px #C6CBD1 !important; font:11px/10px Tahoma, sans-serif !important; color:#575757 !important; text-shadow:0px 1px 0px #FFF !important; } .post__text blockquote, .comment__message blockquote, .comment-form__preview blockquote { background:inherit !important; border-left:0.25em solid #DFE2E5 !important; color:#70767D !important; padding:0 1em !important; } .post__text .user_link { display:inline-block !important; padding-left:14px !important; color:#666 !important; font:92.4%/1.5em Arial !important; background:url("https://hsto.org/storage/habrastock/i/bg-user2.gif") 0px 60% no-repeat !important; } .post__text .user_link::before { content:'@' !important; color:transparent !important; position:absolute !important; left:0 !important; } .voting-wjt_post>.voting-wjt__counter, .post-stats__item_views { display:none !important; }
UPDATE : UserJS - Anti-Quotes-Hell und <code> (siehe Details in diesem Kommentar ):
Die Hauptstile wurden aus früheren Versionen der Habr Matrix übernommen :
- 2012-06 (UserCSS) - die Hauptschrift Verdana 13px, Zeilenabstand 160%
- 2012-06 - das erste Auftreten eines Spoilers + Blocks mit einem Code
- 2012-04 - Tabelle + Überschriften
- 2012-05 - mehr Schlagzeilen
- 2012-05 - nur ein guter Artikel
- 2011-05 - Zeilenabstand 1.54em (in einer schmalen Spalte mit leerem Leerzeichen links und rechts wird der Text schlechter gelesen als mit einem Intervall von 160%), Blöcke mit dem Code haben die Hintergrundfarbe geändert und den Strich verloren (was sonst: Der „Header“ des Hubs hat sich geändert [ein Artikel kann in vielen Hubs sein] wurde zu Blogs [ein Artikel kann nur in einem Blog sein])
- 2011-01 - Der Inhalt wird auf die gesamte Bildschirmbreite ausgedehnt (in diesem Format sieht Text mit reduziertem Zeilenabstand optimal aus, IMHO). IMHO: Die breite rechte Spalte (mit einer Bildschirmbreite von 1600 Pixel) vermittelt ein Gefühl von Komfort und ist auch hier besser als in anderen Versionen Kommentar sieht aus (gute Einrückungsgrößen ausgewählt)
- 2010-08 , 2009-12 , 2009-05 , 2009-03 - Änderungen am Beispiel desselben Artikels
- 2010-02 , 2009-06 - Artikel mit dichterem Text (längere Absätze)
- 2010-03 , 2010-02 , 2009-06 , 2008-12 - positive Erinnerungen an Opera
- 2007-12 - Clearing ：） und die Tag Cloud in der rechten Spalte
- 2007-04 - Der Zeilenabstand ist noch kleiner
Über LLTR werde ich eine Reihe von Artikeln mit dem allgemeinen Thema "Erstellen eines Protokolls" schreiben. Dieser Artikel ist Null.
# Eine Analogie aus der physischen Welt - pneumatischer Transport
Stellen Sie sich vor, wir haben 2 Luftleitungen ...
Eine Leitung für eingehende Pakete (rote Container) und eine für ausgehende Pakete (blaue Container).
Wir haben mehrere Freunde, die an dasselbe pneumatische Transportsystem angeschlossen sind. Wir können ihnen Container schicken, und sie können uns Container schicken. Die Container-Lieferadresse ist auf dem Container selbst angegeben (z. B. in RFID oder Barcode).
Irgendwann wollte jeder herausfinden, auf welcher Route seine Pakete jeden Tag verkehren, und herausfinden, an welche Schalter (Schaltzentren) seine Pneumatikrohre angeschlossen sind, d. H. Finden Sie die Topologie des pneumatischen Netzwerks heraus.
Wir und unsere Freunde können nur Container mit bestimmten Inhalten senden und empfangen.
Ich möchte darüber nachdenken, wie Sie in diesem Fall die Topologie dieses Netzwerks erstellen können. Unter dem Spoiler stehen mehrere Optionen:
Spoiler
1. Wenn die Rohre transparent sind, wie beim pneumatischen Transport in Futurama ( KDPV ), können Sie einfach eine Videokamera senden, die den gesamten Bewegungspfad des Containers erfasst.
2. Sie können die Sensoren (Gyroskop, Kompass, Beschleunigungsmesser, ...) in den Container legen und anhand der gesammelten Daten eine Verschiebungskarte erstellen.
3. Sie können auf Sensoren verzichten und auf besondere Weise mit Luft gefüllte Behälter versenden. Diese Option wird unten betrachtet, da Dies gilt für reguläre kabelgebundene Ethernet-Netzwerke.
# LLTR Basic
Wenn Sie zu kabelgebundenen Ethernet-Netzwerken zurückkehren, möchte ich Sie an das Problem erinnern, aufgrund dessen LLTR erstellt wurde. Das Problem wird im Abschnitt „An verschiedene Switches angeschlossene PCs“ des RingSync-Artikels ausführlich beschrieben. Dies ist ein Problem der Geschwindigkeitsreduzierung, wenn die Peer-Kette in einem Netzwerk mit mehreren Switches nicht korrekt aufgebaut ist. Um eine Peer-Kette ordnungsgemäß aufzubauen, benötigen Sie Informationen zur Netzwerktopologie.
Ein kleines Beispiel (kein Problem):
Wir haben 2 Switches (verbunden durch eine „Leitung“), 4 Hosts (Peers) , alle Verbindungen sind Duplex-Verbindungen und die Geschwindigkeit aller Verbindungen ist gleich. Die Pfeile zeigen den Datenpfad. In diesem Fall gibt es kein Problem - Daten werden mit maximaler Netzwerkgeschwindigkeit übertragen.
Ein weiteres Beispiel (es gibt ein Problem):
In diesem Beispiel wurde die Peer-Kette weniger erfolgreich erstellt (da wir die Netzwerktopologie nicht kennen), was zur Bildung eines „Engpasses“ (zwei unidirektionale Datenströme in einer Verbindung) und zu einer Verringerung der gesamten Datenübertragungsrate führte.
In diesem Fall liegt die Lösung des Problems (Bestimmung der Netzwerktopologie) im Grund für die Notwendigkeit, es zu lösen - in der Bildung eines „Engpasses“. Die gesamte Problemkette sieht wie folgt aus: Sie müssen die „Engpässe“ beseitigen → Sie müssen die „richtige“ Kette erstellen → Sie müssen die Netzwerktopologie bestimmen. Übrigens werden wir nicht alle möglichen Kombinationen der Kette auf der Suche nach einer Kette ohne „Engpässe“ durchgehen - es ist zu lang, stattdessen werden wir klüger / kniffliger vorgehen:
Füllen Sie das Netzwerk mit Datenverkehr - wählen Sie einen der Hosts als Quelle für den Broadcast-Datenverkehr aus. Auf allen anderen Hosts werden Statistiken zum empfangenen Broadcast-Verkehr erfasst. Wählen Sie als Nächstes zwei beliebige Nicht-Broadcast-Hosts aus und senden Sie Unicast-Datenverkehr vom ersten Host zum zweiten Host. Aus den Statistiken des zu diesem Zeitpunkt auf Hosts gesammelten Broadcast-Verkehrs geht hervor, dass auf einigen Hosts die Geschwindigkeit des Empfangs von Broadcast-Verkehr gesunken ist - diese Hosts waren in diesem Fall mit dem richtigen Switch verbunden. Auf allen mit dem linken Switch verbundenen Hosts hat sich die Geschwindigkeit des Empfangs von Broadcast-Verkehr nicht geändert.
Die Verbindung zwischen den beiden Switches wurde zu einem „Engpass“ und ermöglichte die Auswahl aller mit dem rechten Switch verbundenen Hosts in einem separaten Cluster.
Hinweis : In gewöhnlichen Fällen ist es üblich, die Übertragung mit aller Kraft zu bekämpfen, insbesondere mit einer, die „die gesamte Bandbreite nutzt“. Es handelt sich jedoch um ein nicht verwaltetes Switch-Netzwerk, das möglicherweise mehr als einmal und mindestens einmal unter einem Übertragungssturm / einer Überschwemmung gelitten hat Das Leben möchte, dass eine solche Sendung davon profitiert. Übrigens ist es durchaus möglich, Broadcast durch Unicast zu ersetzen, nur ein solcher Scan dauert länger. Für den pneumatischen Transport müssen Sie auch Unicast verwenden, bis Sie die Installation freigeben, die die Angelegenheit klont, und sie in jeder Vermittlungsstelle installieren : Won.
Um die richtige Netzwerktopologie zu erstellen, muss diese für alle möglichen Kombinationen orientierter Paare von Nicht-Broadcast-Hosts wiederholt werden. Was bedeutet "orientierte Paare"? Zuerst müssen Sie Unicast-Verkehr vom ersten Host zum zweiten Host senden, Statistiken sammeln und dann die Richtung ändern (Verkehr vom zweiten zum ersten) und separate Statistiken für diese Option sammeln.
Die Anzahl der zu überprüfenden Kombinationen kann mit der Formel n × (n - 1) berechnet werden {jedes (n) muss allen anderen (n - 1) „Hallo sagen“, auch wenn sie ihn bereits früher begrüßt haben}, wobei n die Zahl ist alle Hosts minus eins (Broadcast-Host).
Infolgedessen werden alle gesammelten Statistiken der Eingabe eines speziellen Algorithmus zugeführt (mehr dazu in einem der folgenden Artikel), der die Netzwerktopologie erstellt (genauer gesagt, es wird mehr getan - es wird sofort die richtige Peer-Kette für RingSync erstellt).
Die minimale Netzwerkkonfiguration, die gescannt werden sollte, besteht übrigens aus zwei Switches, an die jeweils zwei Hosts angeschlossen sind. In Bezug auf Broadcast- und Unicast-Geschwindigkeit kann der Broadcast-Verkehr im Bereich von 75% bis 100% der „Nettodatenrate“ (Nettobitrate; Suche auf „Ethernet 100Base-TX“) und Unicast im Bereich von 80% bis 100% gehalten werden .
Und was passiert, wenn Sie einen der Hosts entfernen?
Dies führt zu einem Netzwerk, in dem ein Switch mit 3 Hosts verbunden ist und ein anderer Switch im Kontext zwischen einem der Hosts und dem Switch verbunden ist. Das heißt, es gibt nur einen Switch im Netzwerk (der in den Abschnitt eingefügte hat sich in einen "Jumper" verwandelt - wir zählen ihn nicht), und dies ist ein idealer Fall für RingSync, von dem der "Engpass" nirgendwo herkommt. Da es kein Problem gibt, gibt es nichts zu beheben : Cong
# LLTR Advanced
UFO ist eingeflogen und hat diese Lücke hier gelassen ? Erinnert an eines der Bilder des IQ-Tests
Wie oben geschrieben, müssen wir bei Verwendung von LLTR Basic das Netzwerk n × (n - 1) Mal scannen, was uns zu O (n 2 ) führt. Für eine kleine Anzahl von Hosts ist dies kein Problem:
- 4 Hosts, n = 3 ⇒ 6 Scans;
- 30 Hosts, n = 29 ⇒ 812 Scans.
Aber wenn wir 200 Hosts haben, ist n = 199 ⇒ 39.402 Scans. Noch schlimmer ...
Mal sehen, wie wir die Situation verbessern können. Groknom zwei einfache Optionen für die Topologie des Baums:
- ein Stern von Schaltern;
- serielle Verbindung von Schaltern.
# Topologie: "Stern von Schaltern"
Im Folgenden wird die in diesem Bild dargestellte Aktion Schritt für Schritt erläutert.
Wir haben 5 Switches und 12 Hosts. Hosts werden durch Kreise [●] innerhalb des Switches angezeigt, mit dem sie verbunden sind. Ein vollständig schwarzer Schalter ist der "Root" -Schalter.
Wir wählen einen der Hosts für die Rolle der Quelle des Broadcast-Verkehrs aus (im Diagramm als Kreis dargestellt [○]).
Wenn Sie LLTR Basic verwenden, benötigen Sie für 12 Hosts n = 11 ⇒ 110 Scans (Iterationen).
Iteration 1 . Wählen Sie einen der Hosts (blau markiert) 
) als Quelle (src) des Unicast-Verkehrs und ein Host (blau gekennzeichnet) als Empfänger des (dst) Unicast-Verkehrs. Beginnen wir zu einem bestimmten Zeitpunkt mit dem Scannen und Sammeln von Statistiken.
Die gesammelten Statistiken zeigten eine Abnahme der Geschwindigkeit des Broadcast-Verkehrs auf 9 Hosts. Aus Gründen der Übersichtlichkeit wird der Geschwindigkeitsabfall auf allen an den Switch angeschlossenen Hosts als bezeichnet 
.
Basierend auf dem festgestellten Geschwindigkeitsabfall können Sie Hosts in zwei Clustern verteilen:
- gelb (initial) - Hosts, auf denen die Sendegeschwindigkeit nahe am Maximum blieb;
- Grün - Hosts, auf denen ein signifikanter Rückgang der Sendegeschwindigkeit verzeichnet wurde.
Iteration 2 . Wir werden andere Unicast-src- und dst-Hosts auswählen und erneut mit dem Scannen und Sammeln von Statistiken beginnen.
Der Geschwindigkeitsabfall ist auf 3 Hosts festgelegt. Jetzt sind sie im grünen Cluster, weil In der vorherigen Iteration wurde auch auf diesen Hosts ein Geschwindigkeitsabfall aufgezeichnet. Verschieben Sie diese 3 Hosts vom grünen Cluster in den neuen roten Cluster.
Iteration 3 . Wählen Sie erneut die anderen Unicast-Hosts src und dst aus und beginnen Sie erneut mit dem Scannen und Sammeln von Statistiken.
Der Geschwindigkeitsabfall wird auf den anderen 3 Hosts aufgezeichnet. Jetzt sind sie im grünen Cluster. Verschieben Sie diese 3 Hosts vom grünen Cluster in den neuen lila Cluster.
Fazit : Nach drei von 110 Iterationen wurden alle Hosts entsprechend ihren Switches in Cluster unterteilt. In den verbleibenden 107 Iterationen werden keine neuen Cluster gebildet.
Es war ein idealer Fall - wir kannten entweder die Netzwerktopologie oder hatten großes Glück.
# Ich frage mich, welche Optionen für die erste Iteration verfügbar sein könnten.
Option 1: "Unicast on Broadcast SW" . Unicast src befindet sich auf demselben Switch wie Broadcast src (sowie im obigen Beispiel in der Abbildung in Iteration 1). Unicast dst befindet sich auf einem anderen Switch (kein Broadcast-SRC).
In allen Fällen ist die Netzwerkreaktion auf das Scannen gleich - ein Geschwindigkeitsabfall bei allen nicht gesendeten src-Switches. Dies ist verständlich - Unicast-src wird am selben Anfang des Kanals wie Broadcast-src zusammengeführt - daher der Geschwindigkeitsabfall bei allen anderen Switches, und es spielt keine Rolle, auf welchem Unicast-dst sich befindet.
Option 2: "Unicast General" . Unicast src befindet sich auf einem beliebigen "Nicht-Broadcast-src" -Schalter. Unicast dst befindet sich auf einem anderen Switch ("nicht Broadcast src" und "nicht Unicast src").
In allen Fällen tritt ein Geschwindigkeitsabfall bei den Switches auf, auf denen sich Unicast dst befand. Das gleiche Netzwerkverhalten war bei Iteration 2 und 3 (siehe Abbildung) aus dem Beispiel am Anfang des Abschnitts.
Option 3: "Unicast zum Senden von SW" . Unicast src befindet sich auf einem beliebigen "Nicht-Broadcast-src" -Schalter (sowie in Option 2). Unicast dst befindet sich auf demselben Switch wie Broadcast src.
In diesen Fällen erfolgt keine Netzwerkantwort auf den Scan. Wenn in den vorherigen Versionen (1 und 2) ein neuer Cluster erstellt wurde, werden in dieser Variante keine neuen Cluster erstellt. Dies ist teilweise schlecht - wir erhalten keine neuen Informationen über die Netzwerktopologie (in einigen Fällen sogar, und wenn diese Iteration nicht die erste ist, können Sie einige Informationen über den Speicherort von Unicast dst erhalten).
Option 4: "Unicast in SW" . Unicast src und dst befinden sich auf demselben Switch.
Auch hier reagiert das Netzwerk überhaupt nicht auf das Scannen, und dementsprechend gibt es keine neuen Cluster.
Das Ergebnis . Die Optionen 1 und 2 sind gut, das Netzwerk reagiert darauf und gibt uns neue Informationen zu seiner Topologie. Basierend auf diesen Informationen werden neue Cluster erstellt.
Die Optionen 3 und 4 können nur sagen, dass sich Unicast dst entweder auf demselben Switch mit Broadcast-src oder auf demselben Switch mit Unicast-src befindet. Darüber hinaus können sie nicht in einer Iteration vollständige Informationen über den genauen Speicherort von Unicast dst geben - sie befinden sich immer neben Broadcast-src oder Unicast-src. Der genaue Ort kann nur erhalten werden, indem die empfangenen Informationen mit Informationen aus anderen Iterationen kombiniert werden.
# War die Auswahl von Unicast src und dst im Beispiel zufällig?
Vielleicht war die Auswahl nicht zufällig und es gibt ein verstecktes Muster darin?
Ok, wir haben uns nur angesehen, wie das Netzwerk auf verschiedene Scanoptionen reagiert. Erinnern Sie sich an das Beispiel vom Anfang des Abschnitts, vielleicht ist es an der Zeit, es aus einem „neuen Blickwinkel“ zu betrachten und die Frage zu beantworten: Habe ich versehentlich Unicast src und dst gewählt oder betrogen?
Dieses Bild ähnelt dem Bild vom Anfang des Abschnitts. Der Unterschied besteht darin, dass jeder Iteration alternative Auswahlmöglichkeiten für Unicast-src hinzugefügt wurden und etwas auf der rechten Seite ...
Dieses „Etwas“ ist die Berechnung der Wahrscheinlichkeit der Bildung eines neuen Clusters (die Anzahl der Optionen, in denen ein neuer Cluster erstellt wird, geteilt durch die Anzahl der Optionen, in denen ein neuer Cluster erstellt wird + die Anzahl der Optionen, die nicht zur Erstellung eines neuen Clusters führen). Die Optionen wurden relativ zum festen Unicast src und zum freien Unicast dst berechnet. Unicast dst "kostenlos" - dies bedeutet, dass alle möglichen Optionen für seinen Standort berücksichtigt wurden.
Das heißt, im Beispiel habe ich speziell diejenigen Optionen ausgewählt, die die größte Wahrscheinlichkeit hatten, einen neuen Cluster zu bilden. Leider können wir in der Realität keine solche Schätzung (der Wahrscheinlichkeiten) verwenden. Kein Wunder, dass ich am Ende geschrieben habe:
Es war ein idealer Fall - wir kannten entweder die Netzwerktopologie oder hatten großes Glück.
Die Möglichkeit, die Wahrscheinlichkeit der Bildung eines neuen Clusters zu bewerten, ist für uns im Folgenden jedoch nützlich.
# Im Cluster scannen oder clusterübergreifend scannen - das ist die Frage ...
Im obigen Beispiel wurde in der letzten (3.) Iteration das Scannen zwischen Clustern verwendet. Ist es so gut, weil sie zuerst innerhalb des Clusters gescannt haben?
Hinweis : Wenn sich Unicast src und dst im selben Cluster befinden, handelt es sich um einen Scan innerhalb des Clusters . Wenn sich Unicast src in einem Cluster und Unicast dst in einem anderen befindet, ist dies das Scannen zwischen Clustern .
Wenn Sie sich die Wahrscheinlichkeiten in der 3. Iteration ansehen, hat der Intercluster-Scan 0,60 gegenüber 0,30 für den Scan innerhalb des Clusters. Die Wahrscheinlichkeit scheint uns zu sagen, dass wir "Intercluster-Scannen verwenden, Bruder". Aber lohnt es sich, blind ihrem Rat zu folgen?
Hinweis : Wenn Sie nur einen Scan-Typ (entweder innerhalb eines Clusters oder eines Interclusters) verwenden, wird die Anzahl der Iterationen erheblich reduziert.
Wenn im obigen Beispiel ab der 4. Iteration nur innerhalb des Clusters gescannt wird , dauert dies 20 Iterationen (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) , insgesamt werden 23 Iterationen anstelle von 110 (wie sie waren) erhalten berechnet am Anfang des Abschnitts). Wenn ab derselben 4. Iteration nur das Scannen zwischen Clustern gestartet wird, werden 87 Iterationen (3 × (3 + 2 + 3) + 3 × (3 + 2 + 3) + 2 × (3 + 3 + 3) benötigt. + 3 × (3 + 3 + 2) - 3) ergeben sich insgesamt 90 Iterationen .
Das Scannen zwischen Clustern verliert merklich, außerdem kann es bei der ersten Iteration nicht verwendet werden (derzeit gibt es nur 1 Cluster). Wenn wir die 2. Iteration aus dem obigen Beispiel beachten, können wir sehen, dass die letzte alternative Scanoption eine Wahrscheinlichkeit hat, einen neuen Cluster von 0,00 zu bilden. Ich glaube, dass die Antwort auf die Frage: „Welche Art von Scannen hatte diese Alternative?“ Ist bereits klar.
# Die Freuden des parallelen Scannens
Wenn beim Scannen innerhalb eines Clusters ein Scan gleichzeitig in allen Clustern gleichzeitig ausgeführt werden kann, werden die zusätzlichen 20 Iterationen (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) auf 6 Iterationen (3 × 2) reduziert. Intercluster-Scannen kann auch vom parallelen Scannen profitieren.
Die Frage ist, ob sich ein Scan auf die Ergebnisse eines anderen Scans auswirkt, der parallel ausgeführt wird.
Note : ( ), – , ?
: – ; , 2‑ — .
– 6‑ . , unicast src dst , 2 . , 2‑ : “ 0.00”.
“ ”, . , ‑ …
, , . 2‑ (“ unicast on broadcast sw ”: unicast src , broadcast src) (“unicast in sw”: unicast src dst ).
“ unicast on broadcast sw ” , “unicast in sw”, . , “unicast in sw” , unicast src ( – ), 2 .
. , ( , ), . “” , broadcast src. , , broadcast src , ! .
Note : , unicast src , , ( ), .
: .
IQ …
# : “ ”
.
unicast ( ) broadcast ( ) , broadcast ( ). 5‑ , “” , – . , , , (↼), ( ) – (⇁), .. (⇋).
.
5 15 . LLTR Basic, 15 , n=14 ⇒ 182 .
. 1‑ , , unicast src , broadcast src, unicast dst broadcast src . Unicast ( ) broadcast broadcast src . ( ). 2‑ , , unicast dst broadcast src .
. ( ).
3 . broadcast unicast – .
4 . broadcast unicast – .
5 . Unicast src dst broadcast src – , unicast dst ( ). , 2‑ , , “ ”.
, , (2 ):
, . 4‑ ( , , ), 1‑ .
30 ((4) + (3×2 + 3×2 + 3×2 + 2×1 + 3×2)) , 182 LLTR Basic.
?
, ‑ . 3‑ , unicast (↼), broadcast , unicast src . , unicast src ( ), , . unicast src , . , , “ ” .
, , , ? “ ” …
( ), :
(2 ), ( ).
, – , 1 . – / .
, 1 , ( , ), , 1 , ? ?
: ( ), () . , , 4 (1 + 3 ):
:
: “ , ?” – , .
? . … ；）
# TL;DR
, …
, , :
xkcd, , （：
# / To be continued…
- OMNeT++ INET [ tutorial ]
- OMNeT++
- OMNeT++ 2
- (‑: “ ”)
: GitHub Pages ;
…
, / .
, , / .
, / .
PS :
( “ ” “” (~~), ‑ ( ), ( : “ ”))
PS 
（； URI )
PPS , ；）
PPPS , , – . ( ) , / , – ：）
PPPPS , .