LLTR Partie 0: Détection automatique de la topologie du réseau et commutateurs non gérés. Mission impossible?

Comment créer une topologie de réseau au niveau de la couche liaison de données si seuls des commutateurs non gérés sont utilisés dans le sous-réseau souhaité? Dans l'article, je vais essayer de répondre à cette question.

Je vais commencer par la cause de LLTR ( Link Layer Topology Reveal ).

J'ai eu un «vélo» - un synchroniseur de fichiers volumineux «à pleine vitesse réseau», capable de télécharger complètement un fichier de 120 Gio sur Fast Ethernet ( 100 Mbps ; 100BASE - TX; duplex) à 1, 10, 30 ou 3 heures > 200 pièces C'était un «vélo» très utile car la vitesse de synchronisation des fichiers était presque indépendante du nombre d'ordinateurs sur lesquels télécharger le fichier. Tout irait bien, mais cela nécessite une connaissance de la topologie du réseau pour son travail.

Vous pouvez continuer la chaîne plus loin, mais je vais rompre.

Les protocoles existants de découverte de la topologie de la couche liaison de données ( LLDP , LLTD , CDP , ...) nécessitent une prise en charge appropriée de tous les nœuds de réseau intermédiaires pour leur fonctionnement. Autrement dit, ils nécessitent au moins des commutateurs gérés qui prennent en charge le protocole approprié. Il y avait déjà un article sur Habré comment utiliser ces protocoles pour « déterminer la topologie du réseau aux 2/3 niveaux du modèle OSI ».

Mais que faire si les nœuds intermédiaires sont de simples commutateurs non gérés?

Si vous êtes intéressé par la façon dont cela peut être fait, alors bienvenue au chat. Je promets la disponibilité de nombreuses illustrations et exemples.

{taille de l'image: 924 Ko; Texte: 69 Ko; Émoticônes: 9 pièces. }

@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-html p > br:first-child, .post__text p+br { display:none !important; } .post__text p { margin-bottom: 0.9em; margin-top: 0.9em; } /* for test: https://habr.com/post/315186 :（ */ .post__text br { line-height:normal !important; } /* or 1 ; https://habr.com/company/pt/blog/337450 */ .post__text img { -o-object-fit:contain; object-fit:scale-down; } /* https://stackoverflow.com/questions/787839/resize-image-proportionally-with-css and don't use "height:auto; width:auto;" (example: <img src="img32x32_2x.png" width="16" height="16">)*/ .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; /*background-color:#F8F8F8 !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; }/*for copy-paste (for Opera Presto)*/ .voting-wjt_post>.voting-wjt__counter, .post-stats__item_views { display:none !important; } 

 // ==UserScript== // @version    1.0.0 // @namespace  https://habr.com/users/ZiroKyl/ // @homepageURL https://habr.com/post/414799/ // @name       Anti-quotes-hell for Habr // @include    https://habr.com/post/* // @include    https://habr.com/company/*/blog/* // ==/UserScript== // Enable opera:config#UserPrefs|UserJavaScriptonHTTPS if(self == top){   window.opera.addEventListener("BeforeEvent.DOMContentLoaded", function(){ "use strict";       var code = document.querySelectorAll(".post__text :not(pre) > code");       var unQuote = function(el){           var aN = null, a = "",              bN = null, b = "";           if((aN = el.previousSibling) && (bN = el.nextSibling) &&              aN.nodeType == 3        && bN.nodeType == 3    ){               a = aN.data; a = a.charCodeAt(a.length-1);               b = bN.data; b = b.charCodeAt(0);               // a != " " && ( a+1 == b && (a == "“" || a == "'" ) || (a == "«" && b == "»") || a == b && (a == "'" || a == "`" || a == '"') )               if(a != 32 && ( a+1 == b && (a == 8220 || a == 8216) || (a == 171 && b == 187) || a == b && (a == 39 || a == 96 || a == 34 ) )){                   aN.data = aN.data.slice(0,-1);                   bN.data = bN.data.slice(1);                   return true;               }           }           return false;       };       var aN = null, bN = null, pElTagName = "";       for(var i=code.length;i--;){           // “<code>...</code>” -> <code>...</code>           if(!unQuote(code[i])                                                                 &&               ( code[i].previousElementSibling == null && code[i].nextElementSibling == null &&                (pElTagName = code[i].parentElement.tagName)                                &&                (pElTagName == "A" || pElTagName == "STRONG")                                ) &&               ( (!(aN = code[i].previousSibling) || aN.data.trim().length == 0) &&                (!(bN = code[i].nextSibling)    || bN.data.trim().length == 0) )             ){               // “<a><code>...</code></a>”    -> <a><code>...</code></a>               // “<a> <code>...</code> </a>”  -> <a> <code>...</code> </a>               // “<a><code>...</code>...</a>” -X               unQuote(code[i].parentElement);           }       }   }, false); } 

À propos de LLTR, je vais écrire une série d'articles sur le thème général "comment créer un protocole". Cet article est nul.

# Une analogie du monde physique - le transport pneumatique

Imaginez que nous ayons 2 tuyaux d'air ...

Un tuyau pour les colis entrants (conteneurs rouges) et un pour les colis sortants (conteneurs bleus).

Nous avons plusieurs amis connectés au même système de transport pneumatique. Nous pouvons leur envoyer des conteneurs et ils peuvent nous envoyer des conteneurs. L'adresse de livraison du conteneur est marquée sur le conteneur lui-même (par exemple, en RFID ou code-barres).

À un moment donné, tout le monde a voulu savoir l'itinéraire emprunté par leurs colis chaque jour et savoir à quels commutateurs (centres de commutation) leurs tuyaux pneumatiques sont connectés, c'est-à-dire Découvrez la topologie du réseau pneumatique.

Tout ce que nous et nos amis pouvons faire, c'est envoyer et recevoir des conteneurs avec un certain contenu.

Je propose de réfléchir à la façon dont, dans ce cas, vous pouvez construire la topologie de ce réseau. Plusieurs options sont sous le spoiler:

# LLTR Basic

Pour en revenir aux réseaux Ethernet câblés, permettez-moi de vous rappeler le problème dû à la création du LLTR. Le problème est décrit en détail dans la section «PC connectés à différents commutateurs» de l'article RingSync - il s'agit d'un problème de réduction de vitesse si la chaîne de pairs n'est pas correctement construite dans un réseau avec plusieurs commutateurs. Pour créer correctement une chaîne d'homologues, vous avez besoin d'informations sur la topologie du réseau.

Un petit exemple (pas de problème):

Nous avons 2 commutateurs (connectés par un «fil»), 4 hôtes (homologues) , toutes les connexions sont en duplex et la vitesse de toutes les connexions est la même. Les flèches indiquent le chemin des données. Dans ce cas, il n'y a pas de problème - les données sont transmises à la vitesse maximale du réseau.

Un autre exemple (il y a un problème):

Dans cet exemple, la chaîne de pairs a été construite avec moins de succès (car nous ne connaissons pas la topologie du réseau), ce qui a conduit à la formation d'un «goulot d'étranglement» (deux flux de données unidirectionnels dans une connexion) et à une diminution du taux de transfert de données global.

Dans ce cas, la solution au problème (déterminer la topologie du réseau) réside dans la raison de la nécessité de le résoudre - dans la formation d'un «goulot d'étranglement». Toute la chaîne de problèmes est la suivante: vous devez vous débarrasser des «goulots d'étranglement» → vous devez créer la «bonne» chaîne → vous devez déterminer la topologie du réseau. Soit dit en passant, nous ne passerons pas par toutes les combinaisons possibles de la chaîne, à la recherche d'une chaîne sans «goulots d'étranglement» - c'est trop long, nous ferons plutôt plus intelligemment / plus délicat:

Remplissez le réseau de trafic - sélectionnez l'un des hôtes comme source du trafic de diffusion. Sur tous les autres hôtes, nous commencerons à collecter des statistiques sur le trafic de diffusion reçu. Ensuite, sélectionnez 2 hôtes non diffusés et commencez à envoyer du trafic unicast du premier hôte au deuxième hôte. Selon les statistiques du trafic de diffusion collectées sur les hôtes en ce moment, on verra que sur certains hôtes la vitesse de réception du trafic de diffusion a chuté - ces hôtes, dans ce cas, étaient connectés au bon commutateur. Et sur tous les hôtes connectés au commutateur gauche, la vitesse de réception du trafic de diffusion n'a pas changé.

La connexion entre les deux commutateurs est devenue un «goulot d'étranglement» et a permis de sélectionner tous les hôtes connectés au commutateur de droite dans un cluster séparé.

Remarque : Dans les cas ordinaires, il est courant de lutter contre la diffusion de toutes nos forces, en particulier celle qui «utilise toute la bande passante», mais nous avons affaire à un réseau de commutation non géré qui peut avoir souffert plus d'une fois d'une tempête / inondation de diffusion, et au moins une fois la vie veut qu'une telle émission en profite. Soit dit en passant, il est tout à fait possible de remplacer la diffusion par la monodiffusion, seule une telle analyse prendra plus de temps. Pour le transport pneumatique, vous devrez également utiliser la monodiffusion jusqu'à ce que vous libériez l'installation qui clone le problème et l'installiez dans chaque centre de commutation : won.

Pour construire la topologie de réseau correcte, il reste à répéter la même chose pour toutes les combinaisons possibles de paires orientées d'hôtes non diffusés. Que signifie «paires orientées»? Vous devez d'abord envoyer du trafic unicast du premier hôte vers le second, collecter des statistiques, puis changer de direction (trafic du second vers le premier), puis collecter des statistiques distinctes pour cette option.

Le nombre de combinaisons à vérifier peut être calculé à l'aide de la formule n × (n - 1) {chaque (n) doit "dire bonjour" à tous les autres (n - 1) , même s'ils l'ont déjà salué plus tôt}, où n est le nombre tous les hôtes moins un (hôte de diffusion).

En conséquence, toutes les statistiques collectées sont alimentées à l'entrée d'un algorithme spécial (plus à ce sujet dans l'un des articles suivants), qui construit la topologie du réseau (plus précisément, il en fait plus - il construit immédiatement la chaîne de pairs correcte pour RingSync).

Soit dit en passant, la configuration réseau minimale à analyser consiste en deux commutateurs, chacun ayant deux hôtes connectés. Quant à la vitesse de diffusion et de monodiffusion, le trafic de diffusion peut être maintenu dans la plage de 75% à 100% du « débit de données net » (débit binaire net; recherche sur «Ethernet 100Base-TX»), et de la monodiffusion dans la plage de 80% à 100% .

# LLTR Advanced

^{Un OVNI est} _entré et a ^laissé _cet ^espace _ici ? Rappelle l'une des photos du test de QI

Comme il a été écrit ci-dessus, lors de l'utilisation de LLTR Basic, nous devons scanner le réseau n × (n - 1) fois, ce qui nous conduit à O (n ² ). Pour un petit nombre d'hôtes, ce n'est pas un problème:

• 4 hôtes, n = 3 ⇒ 6 balayages;
• 30 hôtes, n = 29 ⇒ 812 scans.

Mais si nous avons 200 hôtes, n = 199 ⇒ 39 402 analyses. Pire encore ...

Voyons comment nous pouvons améliorer la situation. Groknom deux options simples pour la topologie de l'arbre:

• une étoile de commutateurs;
• connexion série de commutateurs.

# Topologie: «étoile des commutateurs»

Ci-dessous, l'action décrite dans cette image est expliquée étape par étape.

Nous avons 5 commutateurs et 12 hôtes. Les hôtes sont indiqués par des cercles [●] à l'intérieur du commutateur auquel ils sont connectés. Un commutateur complètement noir est le commutateur «racine».

Nous sélectionnons l'un des hôtes pour le rôle de la source du trafic de diffusion (représenté dans le diagramme par un cercle [○]).

Si vous utilisez LLTR Basic, alors pour 12 hôtes, n = 11 ⇒ vous avez besoin de 110 analyses (itérations).

Itération 1 . Choisissez l'un des hôtes (indiqué en bleu ) comme source (src) du trafic unicast et un hôte (indiqué en bleu ● ) comme destinataire du trafic (dst) unicast. Commençons, à une certaine période, à analyser et à collecter des statistiques.

Les statistiques recueillies ont montré une diminution de la vitesse du trafic de diffusion sur 9 hôtes. Pour plus de clarté, la baisse de vitesse sur tous les hôtes connectés au commutateur est désignée par .

En fonction de la baisse de vitesse détectée, vous pouvez répartir les hôtes dans deux clusters:

• jaune (initial) - hôtes sur lesquels la vitesse de diffusion est restée proche du maximum;
• vert - hôtes sur lesquels une baisse significative de la vitesse de diffusion a été enregistrée.

Itération 2 . Nous sélectionnerons d'autres hôtes src et dst unicast, et recommencerons l'analyse et la collecte de statistiques.

La baisse de vitesse est fixée sur 3 hôtes. Maintenant, ils sont dans le cluster vert , car lors de l'itération précédente, une baisse de vitesse a également été enregistrée sur ces hôtes. Déplacez ces 3 hôtes du cluster vert vers le nouveau cluster rouge .

Itération 3 . Encore une fois, sélectionnez les autres hôtes src et dst unicast, puis recommencez l'analyse et la collecte de statistiques.

La baisse de vitesse est enregistrée sur les 3 autres hôtes. Maintenant, ils sont dans le cluster vert . Déplacez ces 3 hôtes du cluster vert vers le nouveau cluster violet .

Conclusion : après trois itérations sur 110, tous les hôtes ont été divisés en grappes correspondant à leurs commutateurs. Dans les 107 itérations restantes, aucun nouveau cluster ne sera formé.

C'était un cas idéal - soit nous connaissions la topologie du réseau, soit nous avons eu beaucoup de chance.

# Je me demande quelles pourraient être les options pour la première itération?

Option 1: «unicast on broadcast sw» . Unicast src est situé sur le même commutateur que broadcast src (ainsi que dans l'exemple ci-dessus dans la figure de l'itération 1). Unicast dst est situé sur tout autre commutateur (pas de diffusion src).

Dans tous les cas, la réponse du réseau à l'analyse est la même - une baisse de la vitesse sur tous les commutateurs src non diffusés. Ceci est compréhensible - unicast src fusionne au même début du canal que broadcast src - d'où la baisse de vitesse sur tous les autres commutateurs, et peu importe celui sur lequel le dic unicast est activé.

Option 2: «monodiffusion générale» . Unicast src est situé sur n'importe quel commutateur «non broadcast src». Unicast dst est situé sur tout autre commutateur («not broadcast src» et «not unicast src»).

Dans tous les cas, une baisse de vitesse se produit sur celle des commutateurs sur lesquels se trouvait dst unicast. Le même comportement de réseau était à l'itération 2 et 3 (voir la figure) de l'exemple au début de la section.

Option 3: «unicast pour diffuser sw» . Unicast src est situé sur n'importe quel commutateur «non broadcast src» (ainsi que dans l'option 2). Unicast dst est situé sur le même commutateur que broadcast src.

Dans ces cas, il n'y a pas de réponse du réseau à l'analyse. Si dans les versions précédentes (1 et 2) un nouveau cluster a été créé, alors dans cette variante de nouveaux clusters ne sont pas créés. C'est en partie mauvais - nous n'obtenons pas de nouvelles informations sur la topologie du réseau (en fait, dans certains cas, et si cette itération n'est pas la première, vous pouvez obtenir des informations sur l'emplacement de dst de monodiffusion).

Option 4: «unicast in sw» . Unicast src et dst sont situés sur le même commutateur.

Ici aussi, le réseau ne répond pas du tout à l'analyse et il n'y a donc pas de nouveaux clusters.

Le résultat . Les options 1 et 2 sont bonnes, le réseau y répond et nous donne de nouvelles informations sur sa topologie. Et sur la base de ces informations, de nouveaux clusters sont créés.

Les options 3 et 4 ne peuvent que dire que dst unicast est soit sur le même commutateur avec src de diffusion, soit sur le même commutateur avec src unicast. De plus, ils ne peuvent pas donner des informations complètes en une seule itération sur l'emplacement exact de dst de monodiffusion - ils seront toujours à côté de src de diffusion ou de src de monodiffusion. L'emplacement exact ne peut être obtenu qu'en combinant les informations reçues avec des informations provenant d'autres itérations.

# Le choix de src et dst unicast dans l'exemple était-il aléatoire?

Peut-être que le choix n'était pas aléatoire et qu'il y a un motif caché dedans?

Ok, nous venons de voir comment le réseau répond aux différentes options de numérisation. Rappelez-vous l'exemple du début de la section, il est peut-être temps de le regarder sous un «nouvel angle» et de répondre à la question: ai-je accidentellement choisi unicast src et dst, ou triché?

Cette image est similaire à l'image du début de la section, la différence est que des choix alternatifs de src unicast ont été ajoutés à chaque itération, et quelque chose à droite ...

Ce «quelque chose» est le calcul de la probabilité de formation d'un nouveau cluster (le nombre d'options dans lesquelles un nouveau cluster sera créé divisé par le nombre d'options dans lesquelles un nouveau cluster sera créé + le nombre d'options qui ne conduisent pas à la création d'un nouveau cluster). Les options ont été calculées par rapport au src unicast fixe et au dst unicast libre. Unicast dst "free" - cela signifie que toutes les options possibles pour son emplacement ont été considérées.

Autrement dit, dans l'exemple, j'ai choisi spécifiquement les options qui avaient la plus grande probabilité de former un nouveau cluster. Malheureusement, en réalité, nous ne pouvons pas utiliser une telle estimation (des probabilités). Pas étonnant à la fin j'ai écrit:

C'était un cas idéal - soit nous connaissions la topologie du réseau, soit nous avons eu beaucoup de chance.

Cependant, la capacité d'évaluer la probabilité de formation d'un nouveau cluster nous est utile ci-dessous.

# Scannez à l'intérieur du cluster, ou utilisez le scan inter-cluster - c'est la question ...

Dans l'exemple ci-dessus, lors de la dernière (3e) itération, l'analyse entre les clusters a été utilisée. Est-ce si bon, car au début, ils utilisaient la numérisation à l'intérieur du cluster?

Remarque : Si unicast src et dst se trouvent dans le même cluster, il s'agit d'une analyse à l'intérieur du cluster . Si unicast src se trouve dans un cluster et unicast dst dans un autre, il s'agit de l' analyse intercluster .

Si vous regardez les probabilités dans la 3ème itération, l'analyse intercluster aura 0,60 contre 0,30 pour l'analyse à l'intérieur du cluster. La probabilité semble nous dire «utilisez le balayage intercluster, bro.», Mais cela vaut-il la peine de suivre aveuglément ses conseils?

Remarque : L'utilisation d'un seul type d'analyse (au sein d'un cluster ou d'un intercluster) réduira considérablement le nombre d'itérations.

Si dans l'exemple ci-dessus, à partir de la 4ème itération, nous commençons à scanner uniquement à l'intérieur du cluster , cela prendra 20 itérations (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) , au total 23 itérations seront obtenues au lieu de 110 (comme cela a été calculé au début de la section). Si, à partir de la même 4ème itération, seul le scan intercluster est démarré , alors il faudra 87 itérations (3 × (3 + 2 + 3) + 3 × (3 + 2 + 3) + 2 × (3 + 3 + 3) + 3 × (3 + 3 + 2) - 3) , au total 90 itérations se révéleront.

Le balayage intercluster perd sensiblement, de plus, il ne peut pas être utilisé à la 1ère itération (pour le moment il n'y a qu'un seul cluster). Si nous prêtons attention à la 2e itération de l'exemple ci-dessus, nous pouvons voir que la dernière option de scan alternative a une probabilité de former un nouveau cluster de 0,00. Je crois que la réponse à la question: «Quel type de numérisation cette alternative avait-elle?» Est déjà claire.

# Les plaisirs du balayage parallèle

Si, en utilisant l' analyse à l'intérieur d'un cluster , il est possible d'exécuter simultanément une analyse dans tous les clusters, les 20 itérations supplémentaires (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) seront réduites à 6 itérations (3 × 2). Le scan intercluster peut également bénéficier d'un scan parallèle.

La question est de savoir si une analyse affectera les résultats d'une autre analyse, exécutée en parallèle.

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

, …

, , :

• 2 / , – ;
• / , , ( ‑ ).

xkcd, , （：

# / To be continued…

1. OMNeT++ INET [ tutorial ]
3. OMNeT++
5. OMNeT++ 2
7. (‑: “ ”)

: GitHub Pages ;

PS （； URI )

PPS , ；）

PPPS , , – . ( ) , / , – ：）

PPPPS , .