¿Cómo construir una topología de red en la capa de enlace de datos si solo se usan conmutadores no administrados en la subred deseada? En el artículo intentaré responder esta pregunta.
Comenzaré con la causa de LLTR ( Link Layer Topology Reveal ).
Tenía una "bicicleta": un gran sincronizador de archivos "a toda velocidad de red", capaz de cargar completamente un archivo de 120 GiB a través de Fast Ethernet ( 100 Mbps ; 100BASE - TX; dúplex) a 1, 10, 30 o 3 horas > 200 piezas Fue una "bicicleta" muy útil porque la velocidad de sincronización de archivos era casi independiente de la cantidad de PC en las que cargar el archivo. Todo estaría bien, pero requiere el conocimiento de la topología de la red para su trabajo.
Más en el artículo sobre él: Bien, ¿por qué necesitabas "conducir" un archivo de 120 GiB a través de la red a una cantidad de PC tan grande?
Este archivo era VHD con el sistema operativo, programas, etc. El archivo se creó en el sistema maestro y luego se distribuyó a todas las demás PC. VHD no solo era una forma de entregar el sistema a las PC de destino, sino que también permitía restaurar el estado inicial del sistema cuando la PC se reiniciaba. Más detalles en el artículo: " Congelación del sistema: la historia de la transición de EWF a dVHD ".
Puedes continuar la cadena aún más, pero con esto me romperé.
Los protocolos de descubrimiento de topología de capa de enlace de datos existentes ( LLDP , LLTD , CDP , ...) requieren el soporte adecuado de todos los nodos de red intermedios para su funcionamiento. Es decir, requieren al menos conmutadores administrados que admitan el protocolo apropiado. Ya había un artículo sobre Habré sobre cómo usar estos protocolos para " determinar la topología de la red en los niveles de 2/3 del modelo OSI ".
Pero, ¿qué pasa si los nodos intermedios son simples conmutadores no administrados?
Si está interesado en cómo se puede hacer esto, bienvenido a cat. Prometo la disponibilidad de muchas ilustraciones y ejemplos.
{tamaño de imagen: 924 KiB; Texto: 69 KiB; Emoticones: 9 piezas }
Un poco de UserCSS antes de leer
Nota : este spoiler se colocó originalmente antes del kat.
Seguramente todos los que querían personalizar los estilos para sí mismos ya lo habían hecho. Sin embargo, aquí es parte de mi UserCSS. Cambios mayores:
- el final del spoiler abierto es visible (útil cuando el spoiler es grande y no se nota inmediatamente la diferencia en la sangría entre el texto principal y el texto en el spoiler), más precisamente, devolvió el marco y el fondo anteriores del spoiler;
- el bloque de citas volvió a su forma anterior (mostré a varias personas que no entendían el idioma ruso y no leyeron las nuevas "citas amarillas" de Habré, y dijeron que se trataba de inserciones publicitarias contextuales ...);
- la fuente principal, su tamaño y el interlineado, también volvieron (en mi humilde opinión, con ellos el texto largo es más fácil de leer);
- Se eliminó la calificación de publicación y el número de vistas, pero se dejó el número de marcadores agregados.
En general, devolví (con modificaciones menores) el aspecto familiar de los elementos principales del artículo. Con este diseño, ya se han leído una gran cantidad de buenos artículos (surgen recuerdos agradables).
@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; }
ACTUALIZACIÓN : UserJS - Anti-quotes-hell y <code> (ver detalles en este comentario ):
Los principales estilos fueron tomados de versiones anteriores de Habr Matrix :
- 2012-06 (UserCSS) - la fuente principal Verdana 13px, interlineado 160%
- 2012-06 - la primera aparición de un spoiler + bloque con un código
- 2012-04 - tabla + encabezados
- 2012-05 - más titulares
- 2012-05 - solo un buen artículo
- 2011-05 - interlineado 1.54em (en una columna angosta, con un espacio vacío a la izquierda y a la derecha, el texto se lee peor que con un intervalo de 160%), los bloques con el código cambiaron el color de fondo y perdieron el trazo (qué más: el encabezado del centro cambió [un artículo puede estar en muchos centros] se convirtió en blogs [un artículo puede estar en un solo blog])
- 2011-01 : el contenido se extiende a todo el ancho de la pantalla (en este formato, el texto con un espaciado de línea reducido se ve óptimo, en mi humilde opinión), en mi humilde opinión: la columna derecha ancha (con un ancho de pantalla de 1600 px) crea una sensación de comodidad, y también es mejor aquí que en otras versiones aspecto del comentario (buen tamaño de sangría seleccionado)
- 2010-08 , 2009-12 , 2009-05 , 2009-03 - cambios en el ejemplo del mismo artículo
- 2010-02 , 2009-06 - artículos con texto más denso (párrafos más largos)
- 2010-03 , 2010-02 , 2009-06 , 2008-12 - recuerdos positivos sobre Opera
- 2007-12 - Compensación ：） y la nube de etiquetas en la columna derecha
- 2007-04 - El espacio entre líneas es aún más pequeño
Sobre LLTR, voy a escribir una serie de artículos con un tema general "cómo crear un protocolo". Este artículo es cero.
# Una analogía del mundo físico: transporte neumático
Imagina que tenemos 2 tubos de aire ...
Una tubería para paquetes entrantes (contenedores rojos) y otra para paquetes salientes (contenedores azules).
Tenemos varios amigos que están conectados al mismo sistema de transporte neumático. Podemos enviarles contenedores, y ellos pueden enviarnos contenedores. La dirección de entrega del contenedor está marcada en el contenedor (por ejemplo, en RFID o código de barras).
En algún momento, todos querían averiguar la ruta a lo largo de la cual van sus paquetes todos los días, y averiguar a qué interruptores (centros de conmutación) están conectados sus tubos neumáticos, es decir. Descubra la topología de la red neumática.
Todo lo que nosotros y nuestros amigos podemos hacer es enviar y recibir contenedores con cierto contenido.
Propongo pensar cómo, en este caso, puede construir la topología de esta red. Hay varias opciones debajo del spoiler:
spoiler
1. Si las tuberías son transparentes, como en el transporte neumático en Futurama ( KDPV ), simplemente puede enviar una cámara de video que capturará toda la ruta de movimiento del contenedor.
2. Puede colocar los sensores (giroscopio, brújula, acelerómetro, ...) en el contenedor y construir un mapa de desplazamiento basado en los datos que recopilaron.
3. Puede prescindir de sensores, enviando contenedores llenos de aire de una manera especial. Esta opción se considera a continuación, ya que Es aplicable a las redes Ethernet cableadas normales.
# LLTR Basic
Volviendo a las redes Ethernet cableadas, permítanme recordarles el problema debido al cual se creó LLTR. El problema se describe en detalle en la sección "PC conectadas a diferentes conmutadores" del artículo de RingSync : este es un problema de reducción de velocidad si la cadena de pares no está correctamente construida en una red con varios conmutadores. Para construir correctamente una cadena de pares, necesita información sobre la topología de la red.
Un pequeño ejemplo (no hay problema):
Tenemos 2 interruptores (conectados por un "cable"), 4 hosts (pares) , todas las conexiones son dúplex y la velocidad de todas las conexiones es la misma. Las flechas muestran la ruta de datos. En este caso, no hay problema: los datos se transmiten a la velocidad máxima de la red.
Otro ejemplo (hay un problema):
En este ejemplo, la cadena de pares se construyó con menos éxito (porque no conocemos la topología de la red), lo que condujo a la formación de un "cuello de botella" (dos flujos de datos unidireccionales en una conexión) y una disminución en la tasa general de transferencia de datos.
En este caso, la solución al problema (determinar la topología de la red) radica en la razón de la necesidad de resolverlo, en la formación de un "cuello de botella". La cadena completa de problemas es la siguiente: necesita deshacerse de los "cuellos de botella" → necesita construir la cadena "correcta" → necesita determinar la topología de la red. Por cierto, no pasaremos por todas las combinaciones posibles de la cadena, en busca de una cadena sin "cuellos de botella"; es demasiado larga, en su lugar, haremos algo más inteligente / complicado:
Llene la red con tráfico: seleccione uno de los hosts como fuente del tráfico de difusión. En todos los demás hosts, comenzaremos a recopilar estadísticas sobre el tráfico de transmisión recibido. A continuación, seleccione 2 hosts que no sean de difusión y comience a enviar tráfico de unidifusión desde el primer host al segundo host. De acuerdo con las estadísticas del tráfico de transmisión recopilado en los hosts en este momento, se verá que en algunos hosts la velocidad de recepción del tráfico de transmisión ha disminuido; estos hosts, en este caso, estaban conectados al conmutador derecho. Y en todos los hosts conectados al conmutador izquierdo, la velocidad de recepción del tráfico de transmisión no ha cambiado.
La conexión entre los dos conmutadores se convirtió en un "cuello de botella" y permitió seleccionar todos los hosts conectados al conmutador derecho en un clúster separado.
Nota : En casos comunes, es una práctica común luchar contra la transmisión con todas nuestras fuerzas, especialmente una que "utiliza todo el ancho de banda", pero estamos lidiando con una red de conmutación no administrada que puede haber sufrido más de una vez por una tormenta / inundación de transmisión, y al menos una vez la vida quiere que tal transmisión se beneficie. Por cierto, es bastante posible reemplazar la transmisión con unidifusión, solo un análisis de este tipo llevará más tiempo. Para el transporte neumático, también tendrá que usar unidifusión hasta que libere la instalación que clona el asunto e instálela en cada centro de conmutación : ganado.
Para construir la topología de red correcta, queda por repetir lo mismo para todas las combinaciones posibles de pares orientados de hosts no broadcast. ¿Qué significa "pares orientados"? Primero debe enviar tráfico de unidifusión desde el primer host al segundo, y recopilar estadísticas, y luego cambiar la dirección (tráfico del segundo al primero), y recopilar estadísticas separadas para esta opción.
El número de combinaciones que deben verificarse puede calcularse usando la fórmula n × (n - 1) {cada (n) necesita "saludar" a todos los demás (n - 1) , incluso si ya lo saludaron antes}, donde n es el número todos los hosts menos uno (host de transmisión).
Como resultado, todas las estadísticas recopiladas se alimentan a la entrada de un algoritmo especial (más sobre esto en uno de los siguientes artículos), que construye la topología de la red (más precisamente, hace más: construye inmediatamente la cadena de pares correcta para RingSync).
Por cierto, la configuración de red mínima que debe analizarse consta de dos conmutadores, cada uno de los cuales tiene dos hosts conectados. En cuanto a la velocidad de transmisión y unidifusión, el tráfico de transmisión se puede mantener en el rango de 75% - 100% de la " tasa de datos neta " (tasa de bits neta; buscar en "Ethernet 100Base-TX"), y unidifusión en el rango de 80% - 100% .
¿Y qué sucede si eliminas uno de los hosts?
Esto dará como resultado una red en la que un conmutador al que están conectados 3 hosts , y otro conmutador está conectado en el contexto entre uno de los hosts y el conmutador. Es decir, solo hay un conmutador en la red (insertado en la sección se ha convertido en un "puente", no lo contamos), y este es un caso ideal para que el "cuello de botella" de RingSync no tenga de dónde venir. Como no hay problema, no hay nada que arreglar ： Cong
# LLTR avanzado
¿Ovni voló y dejó esta brecha aquí ? Recuerda una de las imágenes de la prueba de coeficiente intelectual
Como se escribió anteriormente, cuando se usa LLTR Basic, necesitamos escanear la red n × (n - 1) veces, lo que nos lleva a O (n 2 ). Para un pequeño número de hosts, esto no es un problema:
- 4 hosts, n = 3 ⇒ 6 escaneos;
- 30 hosts, n = 29 ⇒ 812 exploraciones.
Pero si tenemos 200 hosts, n = 199 ⇒ 39,402 escaneos. Peor aún más ...
Veamos cómo podemos mejorar la situación. Groknom dos opciones simples para la topología del árbol:
- una estrella de interruptores;
- Conexión en serie de interruptores.
# Topología: "estrella de interruptores"
A continuación, la acción representada en esta imagen se explica paso a paso.
Tenemos 5 interruptores y 12 hosts. Los hosts se indican mediante círculos [●] dentro del conmutador al que están conectados. Un interruptor completamente negro es el interruptor "raíz".
Seleccionamos uno de los hosts para el papel de la fuente del tráfico de difusión (que se muestra en el diagrama como un círculo [○]).
Si usa LLTR Basic, entonces para 12 hosts, n = 11 ⇒ necesita 110 escaneos (iteraciones).
Iteración 1 . Elija uno de los hosts (indicado por azul 
) como la fuente (src) del tráfico de unidifusión, y un host (indicado por ● ● azul) como el destinatario del tráfico de unidifusión (dst). Comencemos, en un cierto período de tiempo, escaneando y recolectando estadísticas.
Las estadísticas recopiladas mostraron una disminución en la velocidad del tráfico de transmisión en 9 hosts. Para mayor claridad, la caída de velocidad en todos los hosts conectados al conmutador se denota como 
.
Según la caída de velocidad detectada, puede distribuir hosts en dos grupos:
- amarillo (inicial): hosts en los que la velocidad de transmisión se mantuvo cerca del máximo;
- verde : hosts en los que se registró una caída significativa en la velocidad de transmisión.
Iteración 2 . Seleccionaremos otros hosts unicast src y dst, y nuevamente comenzaremos a escanear y recopilar estadísticas.
La caída de velocidad se repara en 3 hosts. Ahora están en el grupo verde , porque en la iteración anterior, también se registró una caída en la velocidad en estos hosts. Mueva estos 3 hosts del clúster verde al nuevo clúster rojo .
Iteración 3 . Nuevamente, seleccione los otros hosts src y dst de unidifusión, y nuevamente comience a escanear y recopilar estadísticas.
La caída de velocidad se registra en los otros 3 hosts. Ahora están en el grupo verde . Mueva estos 3 hosts del grupo verde al nuevo grupo púrpura .
En pocas palabras : después de tres iteraciones de 110, todos los hosts se dividieron en grupos correspondientes a sus conmutadores. En las 107 iteraciones restantes, no se formarán nuevos grupos.
Fue un caso ideal: o conocíamos la topología de la red o tuvimos mucha suerte.
# Me pregunto cuáles podrían ser las opciones para la primera iteración.
Opción 1: “unidifusión en transmisión sw” . Unicast src se encuentra en el mismo conmutador que broadcast src (así como en el ejemplo anterior en la figura en la iteración 1). Unicast dst se encuentra en cualquier otro conmutador (no broadcast src).
En todos los casos, la respuesta de la red al escaneo es la misma: una disminución de la velocidad en todos los conmutadores src sin transmisión. Esto es comprensible: el src de unidifusión se fusiona en el mismo comienzo del canal que el src de difusión, de ahí la caída de la velocidad en todos los demás conmutadores, y no importa en cuál esté activado el dst de unidifusión.
Opción 2: "unicast general" . Unicast src se encuentra en cualquier conmutador "no broadcast src". Unicast dst se encuentra en cualquier otro interruptor ("no broadcast src" y "not unicast src").
En todos los casos, se produce una caída de la velocidad en la de los interruptores en los que se encuentra el dst de unidifusión. El mismo comportamiento de red se produjo en las iteraciones 2 y 3 (ver la figura) del ejemplo al comienzo de la sección.
Opción 3: "unidifusión para transmitir sw" . Unicast src se encuentra en cualquier conmutador "no broadcast src" (así como en la opción 2). Unicast dst se encuentra en el mismo conmutador que broadcast src.
En estos casos, no hay respuesta de red al escaneo. Si en las versiones anteriores (1 y 2) se creó un nuevo clúster, entonces en esta variante no se crean nuevos clústeres. Esto es en parte malo: no obtenemos nueva información sobre la topología de la red (de hecho, en algunos casos, y si esta iteración no es la primera, puede obtener información sobre la ubicación de unidifusión).
Opción 4: "unicast en sw" . Unicast src y dst se encuentran en el mismo conmutador.
Aquí, también, la red no responde en absoluto al escaneo y, en consecuencia, no hay nuevos clústeres.
El resultado Las opciones 1 y 2 son buenas, la red responde a ellas y nos brinda nueva información sobre su topología. Y en base a esta información, se crean nuevos grupos.
Las opciones 3 y 4 solo pueden decir que dst de unidifusión está en el mismo conmutador con src de difusión o en el mismo conmutador con src de unidifusión. Además, no pueden proporcionar información completa en una iteración sobre la ubicación exacta de unidifusión - siempre estarán al lado de la transmisión src o unidifusión src. La ubicación exacta solo se puede obtener combinando la información recibida con la información de otras iteraciones.
# ¿La elección de unidifusión src y dst en el ejemplo fue aleatoria?
¿Quizás la elección no fue aleatoria y hay un patrón oculto en ella?
Ok, acabamos de ver cómo la red responde a varias opciones de escaneo. Recuerde el ejemplo desde el comienzo de la sección, tal vez es hora de mirarlo desde un "nuevo ángulo" y responder la pregunta: ¿elegí accidentalmente unicast src y dst, o hice trampa?
Esta imagen es similar a la imagen del principio de la sección, la diferencia es que se agregaron opciones alternativas de src de unidifusión a cada iteración, y algo a la derecha ...
Este "algo" es el cálculo de la probabilidad de la formación de un nuevo grupo (el número de opciones en las que se creará un nuevo grupo dividido por el número de opciones en las que se creará un nuevo grupo + el número de opciones que no conducen a la creación de un nuevo grupo). Las opciones se calcularon en relación con el src de unidifusión fijo y el dst de unidifusión libre. Unicast dst “gratis”: esto significa que se consideraron todas las opciones posibles para su ubicación.
Es decir, en el ejemplo, elegí específicamente aquellas opciones que tenían la mayor probabilidad de formar un nuevo grupo. Desafortunadamente, en realidad no podemos usar tal estimación (de probabilidades). No es de extrañar que al final escribí:
Fue un caso ideal: o conocíamos la topología de la red o tuvimos mucha suerte.
Sin embargo, la capacidad de evaluar la probabilidad de la formación de un nuevo grupo es útil para nosotros a continuación.
# Escanee dentro del clúster o utilice el escaneo entre clústeres: esa es la pregunta ...
En el ejemplo anterior, en la última (3ra) iteración, se usó el escaneo entre grupos. ¿Es tan bueno, porque al principio usaron escaneo dentro del clúster?
Nota : Si unicast src y dst están en el mismo clúster, este es un escaneo dentro del clúster . Si src de unidifusión está en un clúster y dst de unidifusión en otro, este es el escaneo entre clústeres.
Si observa las probabilidades en la tercera iteración, el escaneo entre clústeres tendrá 0.60 versus 0.30 para el escaneo dentro del grupo. La probabilidad parece decirnos "use el escaneo entre clústeres, hermano". ¿Pero vale la pena seguir ciegamente su consejo?
Nota : El uso de un solo tipo de exploración (ya sea dentro de un clúster o entre clústeres) reducirá significativamente el número de iteraciones.
Si en el ejemplo anterior, comenzando desde la cuarta iteración, comenzamos a escanear solo dentro del clúster , entonces esto tomará 20 iteraciones (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) , en total se obtendrán 23 iteraciones en lugar de 110 (como fue calculado al comienzo de la sección). Si, a partir de la misma cuarta iteración, solo se inicia el escaneo entre clústeres , se necesitarán 87 iteraciones (3 × (3 + 2 + 3) + 3 × (3 + 2 + 3) + 2 × (3 + 3 + 3) + 3 × (3 + 3 + 2) - 3) , en total resultarán 90 iteraciones .
El escaneo entre clústeres pierde notablemente, además, no se puede usar en la primera iteración (en este momento solo hay 1 clúster). Si prestamos atención a la segunda iteración del ejemplo anterior, podemos ver que la última opción de exploración alternativa tiene una probabilidad de formar un nuevo grupo de 0.00. Creo que la respuesta a la pregunta: "¿Qué tipo de escaneo tenía esta alternativa?" Ya está clara.
# Las delicias del escaneo paralelo
Si, usando el escaneo dentro de un grupo , es posible ejecutar un escaneo simultáneamente en todos los grupos a la vez, entonces las 20 iteraciones adicionales (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) se reducirán a 6 iteraciones (3 × 2). El escaneo entre grupos también puede beneficiarse del escaneo paralelo.
La pregunta es si una exploración afectará los resultados de otra exploración, que se ejecuta en paralelo.
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 , .