如果在所需的子网中仅使用非管理型交换机，如何在数据链路层上构建网络拓扑？ 在本文中，我将尝试回答这个问题。
我将从LLTR （ 链路层拓扑显示 ）的原因开始。
我有一个“自行车” –一个“全网速”的大文件同步器，能够通过快速以太网（ 100 Mbps ; 100BASE-TX;双工）完全上传120 GiB文件到1、10、30或3个小时 > 200个 这是一个非常有用的“自行车”，因为 文件同步的速度几乎与上传文件的PC数量无关。 一切都会好起来的，但是它需要了解网络拓扑才能工作。
好的，为什么您需要通过网络将120 GiB文件“驱动”到如此数量的PC？
该文件是带有操作系统，程序等的VHD 。 该文件是在主系统上创建的，然后分发到所有其他PC。 VHD不仅是将系统交付给目标PC的一种方式，而且还使PC重启后可以恢复系统的初始状态。 文章中有更多详细信息：“ 系统冻结：从EWF过渡到dVHD的历史 ”。
您可以继续进行连锁，但是在此我将中断。
现有的数据链路层拓扑发现协议（ LLDP ， LLTD ， CDP等）需要所有中间网络节点的适当支持才能进行操作。 也就是说，它们至少需要支持适当协议的受管交换机。 关于Habré的文章已经存在，如何使用这些协议“ 确定OSI模型的2/3级别的网络拓扑 ”。
但是，如果中间节点是简单的非托管交换机，该怎么办？
如果您对如何完成此操作感兴趣，欢迎光临。 我保证会提供许多插图和示例。
{图像尺寸：924 KiB； 文字：69 KiB; 表情符号：9个。 }
阅读之前有一点UserCSS
注意 ：该扰流板最初放置在船at之前。
当然，每个想要为自己定制样式的人都已经做到了。 但是，这是我的UserCSS的一部分 。 主要变化：
- 可见打开的扰流板的末端（当扰流板很大时有用，您不会立即注意到主体文本和扰流板中文本之间的缩进差异），更准确地说，返回了扰流板的前一帧和背景;
- 报价块恢复了以前的格式（我向几个不懂俄语，也没有阅读Habré新“黄色报价”的人展示，他们说这些是上下文广告的插入内容……）；
- 主要字体，其大小和行距也返回了（恕我直言，较长的文本更易于阅读）；
- 删除了出版物等级和视图数，但保留了添加的书签数。
总的来说，我返回（略有修改）本文主要内容的熟悉外观。 通过这种设计，已经阅读了大量好文章（弹出了令人愉快的回忆）。
@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; }
更新 ：UserJS-反引号和<code> （请参阅此注释中的详细信息）：
主要样式取自以前版本的 Habr Matrix ：
关于LLTR，我将撰写一系列主题为“如何创建协议”的文章。 这篇文章是零。
＃来自物理世界的类比-气动运输
想象一下，我们有2条空气管 ...
一根管道用于输入包裹（红色容器），而另一根管道用于输出包裹（蓝色容器）。
我们有几个朋友连接到同一个气动传输系统。 我们可以向他们发送容器，他们可以向我们发送容器。 容器交货地址标记在容器本身上（例如，在RFID或条形码中）。
在某个时候，每个人都想找出他们的包裹每天走的路线，并找出他们的气动管道连接到哪些开关（交换中心），即 找出气动网络的拓扑。
我们和我们的朋友所能做的就是发送和接收具有某些内容的容器。
我建议考虑在这种情况下如何构建此网络的拓扑。 破坏者有以下几种选择：
扰流板
1.如果管道是透明的，例如在Futurama（ KDPV ）的气动运输中，则只需发送摄像机即可捕获容器的整个运动路径。
2.您可以将传感器（陀螺仪，指南针，加速度计等）放置在容器中，并根据收集到的数据构建位移图。
3.您可以不使用传感器而以特殊方式发送充满空气的容器。 下面考虑此选项，因为 它适用于常规有线以太网。
＃LLTR基本
回到有线以太网，让我提醒您创建LLTR所引起的问题。 该问题在RingSync文章的“连接到不同交换机的PC”部分中进行了详细描述 -如果在具有多个交换机的网络中未正确建立对等链，则这是速度降低的问题。 为了正确建立对等链，您需要有关网络拓扑的信息。
一个小例子（没问题）：
我们有2台交换机 （通过一根“电线”连接）， 4台主机（对等） ，所有连接均为双工，并且所有连接的速度相同。 箭头显示数据路径。 在这种情况下，没有问题-数据以最大网络速度传输。
另一个例子（有问题）：
在此示例中，对等链的建立不太成功（因为我们不知道网络拓扑），这导致了“瓶颈”（一个连接中有两个单向数据流）的形成，并降低了整体数据传输速率。
在这种情况下，解决问题的方法（确定网络拓扑）在于需要解决的原因-形成“瓶颈”。 整个问题链如下：您需要摆脱“瓶颈”→您需要构建“正确”链→您需要确定网络拓扑。 顺便说一下，我们不会遍历该链的所有可能组合，以寻找没有“瓶颈”的链-它太长了，相反，我们会做得更聪明/更棘手：
用通信量填充网络-选择主机之一作为广播通信量的来源。 在所有其他主机上，我们将开始收集有关收到的广播流量的统计信息。 接下来，选择任意2个非广播主机，然后开始从第一个主机向第二个主机发送单播流量。 根据此时主机上收集到的广播流量的统计信息，可以看出，在某些主机上，接收广播流量的速度有所下降-在这种情况下，这些主机已连接到正确的交换机。 在连接到左交换机的所有主机上，接收广播流量的速度没有改变。
两个交换机之间的连接成为一个“瓶颈”，并允许在单独的群集中选择连接到正确的交换机的所有主机。
注意 ：在通常情况下，通常的方法是尽我们最大的努力抗击广播，尤其是“利用所有带宽”的广播，但是我们正在处理一个不受管理的交换网络，该网络可能遭受了一次以上的广播风暴/洪灾，并且至少遭受一次生活希望这样的广播受益。 顺便说一下，很有可能用单播代替广播，只有这样的扫描才会花更长的时间。 对于气动运输，您还必须使用单播，直到您释放克隆该问题的安装并将其安装在每个交换中心 ：韩元上。
为了构建正确的网络拓扑，必须对定向的非广播主机对的所有可能组合重复相同的操作。 “定向对”是什么意思呢？首先，您需要将单播流量从第一个主机发送到第二个主机，并收集统计信息，然后更改方向（从第二个主机到第一个主机的流量），并为此选项收集单独的统计信息。
可以使用以下公式计算需要检查的组合数量： n×（n − 1） {每个（n）都必须向所有其他人（n − 1） “打个招呼”，即使他们已经向他打招呼了}，其中n是数字所有主机减一（广播主机）。
结果，所有收集到的统计信息都被馈送到一种特殊算法的输入中（在以下文章之一中有更多关于它的信息），该算法构建了网络拓扑（更确切地说，它做了更多的工作-它立即为RingSync构建正确的对等链）。
顺便说一句，应该扫描的最小网络配置包括两个交换机，每个交换机都连接了两个主机。 至于广播和单播的速度，广播流量可以保持在“ 净数据速率 ”（净比特率；在“ Ethernet 100Base-TX”上搜索）的75％-100％范围内，而单播则在80％-100％的范围内。
如果您删除其中一台主机，会发生什么？
这将导致一个网络，其中一台交换机连接了3台主机 ，另一台交换机在上下文中连接在其中一台主机和该交换机之间。 也就是说，网络中只有一个交换机（插入到该部分中已变成“跳线”-我们不计算在内），这对于RingSync的“瓶颈”无处可寻。 既然没有问题，没有什么要解决的 ：丛
＃LLTR高级
不明飞行物 飞进去，并留在这里的 差距 ？ 提醒智商测试的图片之一
如上文所述，使用LLTR Basic时，我们需要扫描网络n×（n − 1）次，这导致我们到达O（n 2 ）。 对于少量主机，这不是问题：
- 4个主机，n = 3⇒6次扫描；
- 30个主机，n = 29⇒812次扫描。
但是，如果我们有200个主机，则n = 199⇒39,402次扫描。 更糟的是...
让我们看看如何改善这种情况。 Groknom为树的拓扑提供了两个简单的选项：
＃拓扑：“来自交换机的星星”
下面，逐步说明此图片中描述的动作。
我们有5台交换机和12台主机。 主机由所连接的交换机内的圆圈[●]表示。 全黑开关是“根”开关。
我们选择一台主机作为广播流量源的角色（在图中以圆圈[○]显示）。
如果使用LLTR Basic，则对于12台主机，n = 11⇒您需要进行110次扫描（迭代）。
迭代1 。 选择其中一台主机（蓝色表示 
）作为单播流量的源（src），一台主机（由蓝色●指示）作为（dst）单播流量的接收者。 让我们在特定时间段开始扫描和收集统计信息。
收集的统计数据显示9台主机上广播流量的速度有所降低。 为了清楚起见，连接到交换机的所有主机上的速度下降表示为 
。
根据检测到的速度下降，可以将主机分布在两个群集中：
- 黄色 （初始）-广播速度保持接近最大值的主机；
- 绿色 -记录了广播速度显着下降的主机。
迭代2 。 我们将选择其他单播src和dst主机，然后再次开始扫描和收集统计信息。
速度下降固定在3台主机上。 现在它们在绿色集群中，因为 在先前的迭代中，这些主机的速度也有所下降。 将这3台主机从绿色群集移动到新的红色群集。
迭代3 。 再次，选择其他单播src和dst主机，然后再次开始扫描和收集统计信息。
速度下降记录在其他3台主机上。 现在它们在绿色集群中。 将这3台主机从绿色群集移至新的紫色群集。
底线 ：在110次中进行了3次迭代之后，所有主机都被划分为对应于其交换机的集群。 在其余的107次迭代中，将不会形成新的集群。
这是一个理想的情况-我们要么知道网络拓扑，要么很幸运。
＃我想知道第一次迭代的选项是什么？
选项1：“在广播sw上单播” 。 单播src与广播src位于同一交换机上（以及在迭代1中上图中的示例中）。 单播dst位于任何其他（非广播src）交换机上。
在所有情况下，网络对扫描的响应都是相同的-所有非广播src交换机的速度都会下降。 这是可以理解的-单播src与广播src合并在同一频道的开头-因此所有其他交换机上的速度下降，并且单播dst启用哪个都不重要。
选项2：“通用单播” 。 单播src位于任何“非广播src”开关上。 单播dst位于任何其他开关（“非广播src”和“非单播src”）上。
在所有情况下，单播dst所在的交换机的速度都会下降。 在本节开始的示例中，在迭代2和迭代3（请参见图）时，网络行为相同。
选项3：“单播广播sw” 。 单播src位于任何“非广播src”开关上（以及选项2中）。 单播dst与广播src位于同一交换机上。
在这些情况下，网络对扫描没有响应。 如果在以前的版本（1和2）中创建了新集群，则在此变体中不会创建新集群。 这在某种程度上是不好的-我们没有获得有关网络拓扑的新信息（实际上，在某些情况下，并且如果不是第一次迭代，则可以获得有关单播dst位置的一些信息）。
选项4：“在SW中单播” 。 单播src和dst位于同一交换机上。
在这里，网络也完全不响应扫描，因此没有新的群集。
结果 。 选项1和2很好，网络对此做出了响应，并为我们提供了有关其拓扑的新信息。 然后根据此信息创建新的群集。
选项3和4只能说单播dst位于具有广播src的同一交换机上，或者位于具有单播src的同一交换机上。 此外，他们无法一次完整地提供有关单播dst确切位置的完整信息-他们将始终位于广播src或单播src旁边。 只能通过将接收到的信息与来自其他迭代的信息进行组合来获得确切的位置。
＃示例中的src和dst单播选择是否随机？
也许选择不是随机的，并且其中有隐藏的模式？
好的，我们只是研究了网络如何响应各种扫描选项。 记住本节开头的示例，也许是时候从一个“新角度”来看它并回答问题：我是否偶然选择了单播src和dst，或者被欺骗了？
此图片与本节开头的图片相似，不同之处在于，每次迭代都添加了单播src的替代选择，并且在右边有一些...
这种“某物”是对新集群形成的可能性的计算（将在其中创建新集群的选项数量除以将在其中创建新集群的选项数量加上不会导致创建新集群的选项数量）。 相对于固定单播src和免费单播dst来计算选项。 单播dst是“免费”的-这意味着要考虑其位置的所有可能选项。
也就是说，在示例中，我专门选择了最有可能形成新集群的那些选项。 不幸的是，实际上我们不能使用这样的（概率）估计。 难怪我最后写道：
这是一个理想的情况-我们要么知道网络拓扑，要么很幸运。
但是，下面评估我们形成新集群的可能性的能力对我们很有用。
＃在集群内部进行扫描，或使用跨集群扫描-这就是问题所在...
在上面的示例中，在最后（第3次）迭代中，使用了集群之间的扫描。 这样好吗，因为起初他们是在集群内部使用扫描的？
注意 ：如果单播src和dst在同一集群中，则这是集群内部的扫描 。 如果单播src在一个群集中，而单播dst在另一个群集中-这就是群集间扫描 。
如果您查看第三次迭代中的概率，则集群间扫描的集群内部扫描将为0.60对0.30。 可能性似乎告诉我们“使用群集间扫描，兄弟。”，但是盲目听从她的建议值得吗？
注意 ：仅使用一种类型的扫描（在群集内或群集间）将大大减少迭代次数。
如果在上面的示例中，从第4次迭代开始，我们仅开始在集群内部进行扫描，则将需要20次迭代（3×2 + 3×2 + 2×1 + 3×2） ，总共可以获得23次迭代，而不是110次（按原样）计算在本节的开头）。 如果从相同的第4次迭代开始，仅开始集群间扫描 ，则将需要87次迭代（3×（3 + 2 + 3）+ 3×（3 + 2 + 3）+ 2×（3 + 3 + 3） + 3×（3 + 3 + 2） -3） ，总共将进行90次迭代 。
此外，集群间扫描会明显丢失，而且第一次迭代无法使用（目前只有1个集群）。 如果我们注意上面示例中的第二次迭代，我们可以看到最后一个替代扫描选项有可能形成0.00的新簇。 我相信以下问题的答案：“这种替代方法有哪种类型的扫描？”已经很清楚了。
＃并行扫描的乐趣
如果使用集群内部扫描可以一次在所有集群中同时运行扫描，则额外的20次迭代（3×2 + 3×2 + 2×1 + 3×2）将减少为6次迭代（3×2）。 集群间扫描也可以从并行扫描中受益。
问题是，一次扫描是否会影响并行运行的另一次扫描的结果。
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 ;
…
如果文本中有错误，则可以在PM / LAN中编写有关它们的内容。
如果您可以减少保留的所有文字，同时保留所有信息并易于阅读，那么我将在同一PM / LAN中接受这些选项。
, / .
PS :
( “ ” “” (~~), ‑ ( ), ( : “ ”))
PS 
（； URI )
PPS , ；）
PPPS , , – . ( ) , / , – ：）
PPPPS , .