Como criar uma topologia de rede na camada de enlace de dados, se apenas switches não gerenciados forem usados na sub-rede desejada? No artigo, tentarei responder a essa pergunta.
Começarei com a causa do LLTR ( Link Layer Topology Reveal ).
Eu tinha uma “bicicleta” - um grande sincronizador de arquivos “na velocidade máxima da rede”, capaz de carregar completamente um arquivo de 120 GiB pela Fast Ethernet ( 100 Mbps ; 100BASE - TX; duplex) para 1, 10, 30 ou 3 horas > 200 unid . Era uma "bicicleta" muito útil porque a velocidade da sincronização de arquivos era quase independente do número de computadores nos quais o arquivo era carregado. Tudo ficaria bem, mas requer conhecimento da topologia de rede para seu trabalho.
Mais no artigo sobre ele: Ok, por que você precisava “dirigir” um arquivo de 120 GiB pela rede para uma quantidade tão grande de PC?
Este arquivo era VHD com o sistema operacional, programas etc. O arquivo foi criado no sistema mestre e distribuído para todos os outros PCs. O VHD não era apenas uma maneira de entregar o sistema aos PCs de destino, mas também possibilitava restaurar o estado inicial do sistema quando o PC era reiniciado. Mais detalhes no artigo: “ Congelamento do sistema: o histórico da transição do EWF para o dVHD ”.
Você pode continuar a cadeia ainda mais, mas com isso vou quebrar.
Os protocolos existentes de descoberta de topologia da camada de enlace de dados ( LLDP , LLTD , CDP , ...) requerem suporte adequado de todos os nós da rede intermediária para sua operação. Ou seja, eles exigem pelo menos comutadores gerenciados que suportem o protocolo apropriado. Já havia um artigo sobre Habré como usar esses protocolos para " determinar a topologia de rede nos níveis 2/3 do modelo OSI ".
Mas e se os nós intermediários forem simples switches não gerenciados?
Se você estiver interessado em como isso pode ser feito, seja bem-vindo ao gato. Prometo a disponibilidade de muitas ilustrações e exemplos.
{tamanho da imagem: 924 KiB; Texto: 69 KiB; Emoticons: 9 unid. }
Um pouco de UserCSS antes de ler
Nota : este spoiler foi originalmente colocado antes do kat.
Certamente todos que queriam personalizar os estilos para si já o fizeram. No entanto, aqui faz parte do meu UserCSS. Principais mudanças:
- o final do spoiler aberto é visível (útil quando o spoiler é grande e você não percebe imediatamente a diferença no recuo entre o texto principal e o texto no spoiler), mais precisamente, retornou o quadro e o plano de fundo anteriores do spoiler;
- o bloco de citações retornou à sua forma anterior (mostrei a várias pessoas que não entendiam o idioma russo e não leram as novas “citações amarelas” do Habré e disseram que eram inserções publicitárias contextuais ...);
- a fonte principal, seu tamanho e espaçamento entre linhas também retornaram (IMHO, com eles texto longo é mais fácil de ler);
- A classificação da publicação e o número de visualizações foram removidos, mas o número de marcadores foi adicionado.
Em geral, retornei (com pequenas modificações) a aparência familiar dos principais elementos do artigo. Com esse design, um grande número de bons artigos já foi lido (lembranças agradáveis aparecem).
@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-aspas-inferno e <code> (veja detalhes neste comentário ):
Os principais estilos foram retirados das versões anteriores da Matriz Habr:
- 2012-06 (UserCSS) - a fonte principal Verdana 13px, espaçamento de linha 160%
- 2012-06 - a primeira aparição de um spoiler + bloco com um código
- 2012-04 - tabela + cabeçalhos
- 2012-05 - mais manchetes
- 2012-05 - apenas um bom artigo
- 2011-05 - espaçamento entre linhas 1.54em (em uma coluna estreita, com espaço vazio à esquerda e à direita, o texto é lido pior que com um intervalo de 160%), os blocos com o código mudaram a cor do plano de fundo e perderam o traço (o que mais: o “cabeçalho” do hub mudou [um artigo pode estar em muitos hubs] tornou-se blogs [um artigo pode estar em apenas um blog])
- 2011-01 - o conteúdo é estendido para toda a largura da tela (neste formato, o texto com espaçamento reduzido parece ótimo, IMHO), IMHO: a ampla coluna da direita (com uma largura de tela de 1600px) cria uma sensação de conforto e também é melhor aqui do que em outras versões aparência do comentário (bons tamanhos de recuo selecionados)
- 2010-08 , 2009-12 , 2009-05 , 2009-03 - alterações no exemplo do mesmo artigo
- 2010-02 , 2009-06 - artigos com texto mais denso (parágrafos mais longos)
- 2010-03 , 2010-02 , 2009-06 , 2008-12 - lembranças positivas sobre o Opera
- 2007-12 - Compensação: e a nuvem de tags na coluna da direita
- 2007-04 - O espaçamento entre linhas é ainda menor
Sobre o LLTR, vou escrever uma série de artigos com o tema geral "como criar um protocolo". Este artigo é zero.
# Uma analogia do mundo físico - transporte pneumático
Imagine que temos 2 tubos de ar ...
Um tubo para encomendas recebidas (contêineres vermelhos) e outro para encomendas enviadas (contêineres azuis).
Temos vários amigos que estão conectados ao mesmo sistema de transporte pneumático. Podemos enviar contêineres, e eles podem enviar contêineres para nós. O endereço de entrega do contêiner está marcado no próprio contêiner (por exemplo, em RFID ou código de barras).
Em algum momento, todos queriam descobrir a rota pela qual seus pacotes passam todos os dias e descobrir a quais comutadores (centros de comutação) seus tubos pneumáticos estão conectados, ou seja, Descubra a topologia da rede pneumática.
Tudo o que nós e nossos amigos podemos fazer é enviar e receber contêineres com determinado conteúdo.
Proponho pensar em como, nesse caso, você pode construir a topologia dessa rede. Várias opções estão sob o spoiler:
spoiler
1. Se os tubos forem transparentes, como no transporte pneumático em Futurama ( KDPV ), você poderá simplesmente enviar uma câmera de vídeo que capturará todo o caminho de movimento do contêiner.
2. Você pode colocar os sensores (giroscópio, bússola, acelerômetro, ...) no contêiner e criar um mapa de deslocamento com base nos dados coletados.
3. Você pode ficar sem sensores, enviando recipientes cheios de ar de uma maneira especial. Esta opção é considerada abaixo, pois É aplicável a redes Ethernet com fio regulares.
# LLTR Básico
Voltando às redes Ethernet com fio, deixe-me lembrá-lo do problema devido ao qual o LLTR foi criado. O problema é descrito em detalhes na seção “PCs conectados a diferentes comutadores” do artigo RingSync - esse é um problema de redução de velocidade se a cadeia de pares não for construída corretamente em uma rede com vários comutadores. Para criar corretamente uma cadeia de pares, você precisa de informações sobre a topologia de rede.
Um pequeno exemplo (sem problemas):
Temos 2 comutadores (conectados por um "fio"), 4 hosts (pares) , todas as conexões são duplex e a velocidade de todas as conexões é a mesma. As setas mostram o caminho dos dados. Nesse caso, não há problema - os dados são transmitidos na velocidade máxima da rede.
Outro exemplo (há um problema):
Neste exemplo, a cadeia de pares foi construída com menos sucesso (porque não conhecemos a topologia da rede), o que levou à formação de um "gargalo" (dois fluxos de dados unidirecionais em uma conexão) e a uma redução na taxa geral de transferência de dados.
Nesse caso, a solução para o problema (determinando a topologia da rede) está na razão da necessidade de resolvê-lo - na formação de um "gargalo". Toda a cadeia de problemas é a seguinte: você precisa se livrar dos “gargalos” → você precisa criar a cadeia “correta” → você precisa determinar a topologia da rede. A propósito, não passaremos por todas as combinações possíveis da cadeia, em busca de uma cadeia sem “gargalos” - é muito longo, em vez disso, seremos mais inteligentes / mais complicados:
Encha a rede com tráfego - selecione um dos hosts como a fonte do tráfego de transmissão. Em todos os outros hosts, começaremos a coletar estatísticas sobre o tráfego de transmissão recebido. Em seguida, selecione dois hosts de não difusão e comece a enviar tráfego unicast do primeiro host para o segundo host. De acordo com as estatísticas do tráfego de broadcast coletadas nos hosts neste momento, veremos que em alguns hosts a velocidade de recebimento do tráfego de broadcast caiu - esses hosts, nesse caso, estavam conectados ao switch certo. E em todos os hosts conectados ao comutador esquerdo, a velocidade de recebimento do tráfego de transmissão não mudou.
A conexão entre os dois comutadores tornou-se um "gargalo" e permitiu selecionar todos os hosts conectados ao comutador correto em um cluster separado.
Nota : Em casos comuns, é habitual combater a transmissão com todas as nossas forças, especialmente uma que “utilize toda a largura de banda”, mas estamos lidando com uma rede de comutadores não gerenciada que pode ter sofrido mais de uma vez com uma tempestade / inundação de transmissão e pelo menos uma vez a vida quer que essa transmissão se beneficie. A propósito, é bem possível substituir a transmissão pelo unicast, apenas essa verificação levará mais tempo. Para o transporte pneumático, você também precisará usar o unicast até liberar a instalação que clona o problema e instalá-lo em cada central de comutação : ganhou.
Para criar a topologia de rede correta, resta repetir o mesmo para todas as combinações possíveis de pares orientados de hosts sem difusão. O que significa “pares orientados”? Primeiro, você precisa enviar o tráfego unicast do primeiro host para o segundo, coletar estatísticas e depois mudar de direção (tráfego do segundo para o primeiro) e coletar estatísticas separadas para esta opção.
O número de combinações que precisam ser verificadas pode ser calculado usando a fórmula n × (n - 1) {cada (n) precisa “dizer olá” a todos os outros (n - 1) , mesmo que já o tenham recebido}, onde n é o número todos os hosts menos um (host de transmissão).
Como resultado, todas as estatísticas coletadas são alimentadas com a entrada de um algoritmo especial (mais sobre isso em um dos seguintes artigos), que cria a topologia de rede (mais precisamente, faz mais - cria imediatamente a cadeia de pares correta para o RingSync).
A propósito, a configuração mínima de rede que deve ser varrida consiste em dois comutadores, cada um com dois hosts conectados. Quanto à velocidade de transmissão e unicast, o tráfego de transmissão pode ser mantido na faixa de 75% a 100% da " taxa de dados líquida " (taxa de bits líquida; pesquisa em "Ethernet 100Base-TX") e unicast na faixa de 80% a 100% .
E o que acontece se você remover um dos hosts?
Isso resultará em uma rede na qual um switch ao qual 3 hosts estão conectados e outro switch está conectado no contexto entre um dos hosts e o switch. Ou seja, existe apenas um comutador na rede (inserido na seção que se transformou em um "jumper" - não contamos), e esse é o caso ideal para o "gargalo" do RingSync de onde não há nenhum lugar. Como não há problema, não há nada para corrigir : Cong
# LLTR avançado
OVNI voou e deixou essa lacuna aqui ? Lembra uma das fotos do teste de QI
Como foi escrito acima, ao usar o LLTR Basic, precisamos varrer a rede n × (n - 1) vezes, o que nos leva a O (n 2 ). Para um pequeno número de hosts, isso não é um problema:
- 4 hosts, n = 3 ⇒ 6 varreduras;
- 30 hosts, n = 29 ⇒ 812 varreduras.
Mas se tivermos 200 hosts, n = 199 ⇒ 39.402 varreduras. Ainda pior ...
Vamos ver como podemos melhorar a situação. Groknom duas opções simples para a topologia da árvore:
- uma estrela dos interruptores;
- conexão serial de switches.
# Topologia: "estrela dos comutadores"
Abaixo, a ação representada nesta figura é explicada passo a passo.
Temos 5 switches e 12 hosts. Os hosts são indicados por círculos [●] dentro do comutador ao qual estão conectados. Uma opção completamente preta é a opção "raiz".
Selecionamos um dos hosts para o papel da fonte de tráfego de broadcast (mostrado no diagrama como um círculo [○]).
Se você usa o LLTR Basic, para 12 hosts, n = 11 ⇒ você precisa de 110 varreduras (iterações).
Iteração 1 . Escolha um dos hosts (indicado por azul 
) como a origem (src) do tráfego unicast e um host (indicado por ● azul) como destinatário do tráfego unicast (dst). Vamos começar, em um determinado período, a varredura e a coleta de estatísticas.
As estatísticas coletadas mostraram uma diminuição na velocidade do tráfego de transmissão em 9 hosts. Para maior clareza, a queda na velocidade em todos os hosts conectados ao switch é indicada como 
.
Com base na queda detectada na velocidade, você pode distribuir hosts em dois clusters:
- amarelo (inicial) - hosts nos quais a velocidade de transmissão permaneceu próxima do máximo;
- verde - hosts nos quais foi registrada uma queda significativa na velocidade de transmissão.
Iteração 2 . Selecionaremos outros hosts unicast src e dst e começaremos novamente a varredura e coleta de estatísticas.
A queda de velocidade é fixada em 3 hosts. Agora eles estão no cluster verde , porque na iteração anterior, uma queda na velocidade também foi registrada nesses hosts. Mova esses 3 hosts do cluster verde para o novo cluster vermelho .
Iteração 3 . Novamente, selecione os outros hosts unicast src e dst e inicie novamente a varredura e a coleta de estatísticas.
A queda de velocidade é registrada nos outros 3 hosts. Agora eles estão no cluster verde . Mova esses 3 hosts do cluster verde para o novo cluster roxo .
Conclusão : após três iterações em 110, todos os hosts foram divididos em clusters correspondentes aos seus comutadores. Nas 107 iterações restantes, nenhum novo cluster será formado.
Era um caso ideal - ou conhecíamos a topologia de rede ou tivemos muita sorte.
# Gostaria de saber quais poderiam ser as opções para a primeira iteração?
Opção 1: "unicast na transmissão sw" . O unicast src está localizado no mesmo switch que o broadcast src (assim como no exemplo acima na figura na iteração 1). O Unicast dst está localizado em qualquer outro comutador (não broadcast src).
Em todos os casos, a resposta da rede à verificação é a mesma - uma queda na velocidade de todos os switches src que não são transmitidos. Isso é compreensível - o unicast src se funde no mesmo começo do canal que o broadcast src - daí a queda na velocidade de todos os outros comutadores, e não importa em qual deles o unicast dst está.
Opção 2: "unicast geral" . O unicast src está localizado em qualquer opção "non broadcast src". O Unicast dst está localizado em qualquer outro comutador (“not broadcast src” e “not unicast src”).
Em todos os casos, ocorre uma queda na velocidade dos comutadores nos quais o unicast dst estava localizado. O mesmo comportamento de rede estava na iteração 2 e 3 (veja a figura) do exemplo no início da seção.
Opção 3: "unicast para transmitir sw" . O Unicast src está localizado em qualquer switch "non broadcast src" (assim como na opção 2). O dst Unicast está localizado no mesmo switch que o broadcast src.
Nesses casos, não há resposta de rede para a verificação. Se nas versões anteriores (1 e 2) um novo cluster foi criado, nessa variante, novos clusters não são criados. Isso é parcialmente ruim - não obtemos novas informações sobre a topologia de rede (de fato, em alguns casos, e se essa iteração não for a primeira, você poderá obter algumas informações sobre a localização do unicast dst).
Opção 4: "unicast em sw" . Unicast src e dst estão localizados no mesmo comutador.
Também aqui a rede não responde à varredura e, portanto, não há novos clusters.
O resultado . As opções 1 e 2 são boas, a rede responde a elas e fornece novas informações sobre sua topologia. E com base nessas informações, novos clusters são criados.
As opções 3 e 4 podem apenas dizer que o unicast dst está no mesmo comutador com broadcast src ou no mesmo comutador com unicast src. Além disso, eles não podem fornecer informações completas em uma iteração sobre a localização exata do unicast dst - sempre estarão ao lado de broadcast src ou unicast src. A localização exata só pode ser obtida combinando as informações recebidas com as de outras iterações.
# A escolha do unicast src e dst no exemplo foi aleatória?
Talvez a escolha não tenha sido aleatória, e há um padrão oculto nela?
Ok, vimos como a rede responde a várias opções de digitalização. Lembre-se do exemplo do início da seção, talvez seja a hora de analisá-lo de um "novo ângulo" e responder à pergunta: acidentalmente escolhi o unicast src e o dst, ou trapacei?
Esta imagem é semelhante à imagem do início da seção, a diferença é que opções alternativas de unicast src foram adicionadas a cada iteração e algo à direita ...
Esse "algo" é o cálculo da probabilidade de formação de um novo cluster (o número de opções em que um novo cluster será criado dividido pelo número de opções em que um novo cluster será criado + o número de opções que não levam à criação de um novo cluster). As opções foram calculadas em relação ao unicast fixo src e ao unicast livre dst. Unicast dst “free” - significa que todas as opções possíveis para sua localização foram consideradas.
Ou seja, no exemplo, eu escolhi especificamente as opções que tinham maior probabilidade de formar um novo cluster. Infelizmente, na realidade, não podemos usar essa estimativa (de probabilidades). Não é de admirar que no final eu escrevi:
Era um caso ideal - ou conhecíamos a topologia de rede ou tivemos muita sorte.
No entanto, a capacidade de avaliar a probabilidade de formação de um novo cluster é útil para nós abaixo.
# Faça a varredura dentro do cluster ou use a varredura entre cluster - eis a questão ...
No exemplo acima, na última (terceira) iteração, a varredura entre os clusters foi usada. É tão bom, porque no início eles usaram a digitalização dentro do cluster?
Nota : Se o unicast src e o dst estiverem no mesmo cluster, será uma varredura dentro do cluster . Se o unicast src estiver em um cluster e o unicast dst em outro - essa é a varredura entre clusters.
Se você observar as probabilidades da 3ª iteração, a varredura entre clusters terá 0,60 versus 0,30 para a varredura dentro do cluster. A probabilidade parece nos dizer: “use a varredura entre clusters, mano”. Mas vale a pena seguir cegamente o conselho dela?
Nota : O uso de apenas um tipo de varredura (dentro de um cluster ou intercluster) reduzirá significativamente o número de iterações.
Se no exemplo acima, a partir da 4ª iteração, começarmos a varrer apenas dentro do cluster , serão necessárias 20 iterações (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) , no total, 23 iterações serão obtidas em vez de 110 (como foi calculado no início da seção). Se, iniciando na mesma 4ª iteração, apenas a varredura entre clusters for iniciada , serão necessárias 87 iterações (3 × (3 + 2 + 3) + 3 × (3 + 2 + 3) + 2 × (3 + 3 + 3) + 3 × (3 + 3 + 2) - 3) , no total, 90 iterações serão exibidas.
A varredura de interclusters perde visivelmente, além disso, não pode ser usada na 1ª iteração (neste momento, há apenas 1 cluster). Se prestarmos atenção à segunda iteração do exemplo acima, podemos ver que a última opção de varredura alternativa tem uma probabilidade de formar um novo cluster de 0,00. Acredito que a resposta para a pergunta: “Que tipo de digitalização essa alternativa teve?” Já está clara.
# As delícias da digitalização paralela
Se, usando a varredura dentro de um cluster , for possível executar uma varredura simultaneamente em todos os clusters de uma só vez, as 20 iterações adicionais (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) serão reduzidas para 6 iterações (3 × 2). A varredura entre clusters também pode se beneficiar da varredura paralela.
A questão é se uma verificação afetará os resultados de outra verificação, sendo executada em 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 , .