我在家里成功搭建10Gb/s以太网的全过程10Gb/s Ethernet: what I actually did to get it working in my home

Archives

Categories

Blogroll

在掌握了足够多的关于 10Gb/s 以太网知识，并能够自信地在自己家中进行部署之后，是时候下定决心了：向 ISP 订购服务，购买设备，然后开始动手。

我已经实现了 2.5Gb/s 的传输速度。公寓内有结构化布线系统——每个房间都至少有一个 RJ45 插座嵌入墙内，而在楼下玄关处有一个配线箱，其上的每个接口都与墙上的插座一一对应。因此，入住时我只需将一台 2.5Gb/s 交换机放在配线箱旁，并将所有线路连接好即可。当然，我们的大部分设备通过 WiFi 运行，但我需要一个有线骨干网络，以便将我书房里数量众多的计算机彼此互联，同时也能连接到外部世界。

我需要做什么？

简化描述一下当前的 2.5Gb/s 架构如下：

当然，周围还有其他一些设备，比如额外的 AP 等，但以上是核心架构，为简化问题，我将重点聚焦于此。

能否将整个系统全面升级至 10Gb/s？最关键的问题在于墙体内的结构化布线类型：是 CAT-5E、CAT-6，还是更高级的 CAT-6A？记得上次提到过，虽然官方标准不支持，但在短距离内 10GBASE-T 技术或许可以在 CAT-5E 线缆上工作。对于 CAT-6 来说，通常支持到约 55 米，而我认为房子里的任何一段线路都不会超过这个长度，所以应该没问题；至于 CAT-6A，则能稳定支持长达 100 米的 10Gb/s 传输。

我无法确切得知所用电缆的具体类型（可见部分没有任何标识），于是决定采取分阶段实施策略。

第一步是在书房内部构建一个 10Gb/s 的有线网络。其中有两个关键节点需要连接：我的主力台式机 perry，以及一个安装在 11 英寸机架中的 Proxmox 集群。目前我的配置是一台 2.5Gb/s 交换机置于机架顶部，既连接墙面，又直连集群主机和 perry。

然而，让 Proxmox 集群实现高速内部网络显然不现实。这些机器都比较老旧——基本上是我过去用于其他用途的小型 PC 的“退休之家”。它们大多只配备千兆以太网，仅有一台支持 2.5Gb/s。

但将 perry 升级到 10Gb/s 却是重要目标，因为这里是我主要的工作场所。我还希望留出空间给第二台机器，计划用它来进行训练或推理任务，以免占用 perry 的 GPU，同时也需要高速网络支持。

我希望设备运行温度能相对凉爽一些（毕竟 PC 和 GPU 在训练时本身就会产生相当可观的热量），所以 DAC 看起来是个不错的选择。我花了一笔不算贵的钱买了一个管理型 10Gb/s 交换机，型号是 MikroTik CRS305-1G-4S+IN，还配了一块 10GBASE-T 适配器，用来连接墙上的网口。我在网络中通常会给每个设备分配独立的 IP 地址，于是这台交换机就变成了“nigel”。接着，我为 perry 配备了一张 10Gb/s SFP+ PCIe 网卡——华硕 XG-C100F，并用一条 DAC 线缆将它与 nigel 连接起来。

对于 Proxmox 集群，我决定继续使用那台旧的 2.5Gb/s 非托管交换机，型号是 TRENDnet TEG-S5061。当初买它是因为它是亚马逊上评价不错且最便宜的 2.5Gb/s 交换机，后来才想起它其实有一个重要功能——上行端口支持 SFP+ 10Gb/s！于是我又加了一条短 DAC，把它和 MikroTik 连在一起，这样整个工作室的网络骨干就升级到了 10Gb/s。

当然，里面两台电脑并不能真正以这个速度通信，因为只有 perry 支持 10Gb/s。不过我可以把所有 Proxmox 主机都通过全速连接到 perry。我用 iperf3 做了一些测试来验证一切是否按预期工作；虽然没能进行非常全面的测试，但总算达到了约 4Gb/s 的总吞吐量，这让我感到安心：两台机器各提供 1Gb/s，另一台提供 2.5Gb/s，总和略低于 4.5Gb/s，结果基本吻合。

下一步是检查从配线架到终端的连接能力。我买了一个 Ubiquiti 的 10G 以太网 Dongle，带着我的笔记本 laura 3 下到机房。

好消息传来！我在结构化布线系统上用 iperf3 测试 perry 和 laura 之间的连接，发现从 laura 到 perry 可以达到接近 10Gb/s 的速度，但从 perry 到 laura 只有大约 7Gb/s。laura 端的接收速度较慢让我有些担心，但当我查看 ps 进程时发现真相大白——ksoftirqd 内核进程跑满了 100%，说明某个单核任务已经满载运行。

这根以太网 Dongle 是通过 USB 连接的，因此每次收到“数据到达”中断时，都需要比 perry 上的 PCIe 卡做更多 CPU 处理工作。这意味着 laura 最多只能以一个核心的处理能力接收数据，而它的极限恰好是 7Gb/s。laura 是一台主打轻薄长续航的 ThinkPad，CPU 性能本就不强，单核表现更是捉襟见肘，自然就撞上了天花板。

不过另一个方向能达到 10Gb/s 的速度，足以让我确信结构化布线系统完全支持这一速率，这是个非常好的消息——很可能那里用的是 CAT-6 或 CAT-6A 线缆，即使只是运气好碰上了优质的 CAT-5E 也能勉强达标。

不利的一面是发热问题。测试时那根 USB Dongle 热得几乎无法握持，虽然当时没机会检查 MikroTik 里的 SFP+ 模块，但上楼后再摸它时感觉更烫了。我决定先把这个问题记下来，以后再看（正如你即将看到的，它确实成了反复出现的问题）。

现在该继续推进升级了。

在机房配线架这边，选择很简单。所有接口都是 RJ45 的，而且只需要四个端口。MikroTik CRS304-4XG-IN 显然是不二之选。

最后需要升级的地方是在 ISP 端。服务提供商给我们的设备只有一个 10Gb/s 端口——一个 10GBASE-T RJ45 接口。不过，我通常不太信任 ISP 的路由器，所以一直以来都在他们设备和家庭网络之间放了一台自己的路由器——一台运行着加固版 Arch Linux 的双网口迷你 PC（型号 4）。我那台旧的设备是双 2.5Gb/s 的，显然需要升级了。

我选定了 Protectli VP2440，它有两个 SFP+ 10Gb/s 插槽，外加两个普通的 2.5Gb/s RJ45 接口。其实我不需要那两个 RJ45 口，但这是他们产品线里带 10Gb/s 最便宜的选项，而且我一直对他们的硬件和客户服务非常满意。

不过，我对散热有点担心。之前我在书房测试 MikroTik 设备时，那个 SFP+ 模块热得厉害。现在我的 Protectli 也需要两块 SFP+ 模块——一块接 ISP 盒子，另一块连墙上的插座，再引到配线架。会不会过热啊？

Protectli 的好处是你可以直接问他们。我给他们发了条消息，第二天就收到客服代表的回复，他说他觉得没问题，但还是想跟技术团队确认一下。结果第二天他跟进说，技术人员已经确认可以正常使用。

太好了！再加上他们有 30 天无理由退款保障，我决定下单试试。

几天后新路由器到了。我给它起了个名字叫 reggie，按照平时配置路由器的 Arch 系统装好，插上 ISP 盒子和墙面插座……一切正常！

所以现在的架构是这样的：

同时我还把主 WiFi AP（winona，Ubiquiti U6 Enterprise）从原来路由器旁边挪到了书房——让它接在 TRENDnet 交换机上。

使用一段时间后，我觉得还是应该把 winona 搬回路由器附近比较好——那里更中心，WiFi 覆盖效果更佳。于是我又搞了个 CRS304-4XG-IN——就是那种带 10GBASE-T 的 MikroTik 交换机，和配线架旁边那台一样。这样前面的拓扑就变成了：

所有这些设备都塞在一个紧挨着餐桌的边柜里，完全没有通风空间。这几乎可以说是这类发热型网络设备的一个极端案例了……那这些设备的温度到底怎么样？

我在考虑要不要把我的空气炸锅换成 SFP+ 模块

我喜欢随时掌握家里这一堆电脑的状态，所以在每台机器上都跑 Telegraf。它会收集 CPU 温度、系统负载、磁盘空间、CPU 和网络使用情况等信息，然后统一发送到 Proxmox VM（叫 varro，如果你记着的话）上的 InfluxDB 实例里。

配置好这些设备后，我还想监控交换机的状态。MikroTik 交换机通过 SNMP 协议对外提供统计数据，借助各种大模型的帮助，我成功修改了 reggie 上的 Telegraf 配置，使其也能采集这些数据并发送给 varro。

我用 Grafana 将所有数据整合到多个仪表盘中，其中一个就是网络设备温度监控。首先是 reggie——这台 Protectli 路由器配有两个 SFP+ 插槽，每个都插着一块 10GBASE-T 模块。我可以分别看到 CPU 和每个 SFP+ 模块的温度：

其实不算凉快，但说实话也没那么糟糕！我认为 SFP+ 插槽与机箱是热耦合的（本质上就是一个巨大的散热片）。所以它们比整机整体温度略高一些，但还不至于过热。我们看看随着天气变暖会怎样——过去一周左右里斯本经历了一段热浪，你可以看到温度确实在持续上升。

那 norman 呢？这台 MikroTik CRS304-4XG-IN 交换机——全部采用原生 10GBASE-T 接口，和 reggie 放在同一个侧柜里？

比我想要的要高一点——虽然超过了官方标称的 70°C 环境温度测试值，但这毕竟是内部温度而非外部环境温度；而紧挨着 norman 的 reggie 内部温度却低于 70°C，这说明我们可能还算安全，因为内部温度不可能低于环境温度。

我觉得这两台设备的散热都有改进空间。它们所在的侧柜完全没有通风，里面还装着 winona 这台 Ubiquiti U6 Enterprise Wi-Fi AP，它本身发热量就很大。因此合理的做法可能是先把 AP 移到别处，如果还不够，或许可以在侧柜后部加装一个 USB 风扇，引入较冷空气。

现在来看看楼下的 nelly，它就在配线架旁边的那台交换机。它也装在一个没有气流的柜子里，虽然没有和路由器放在一起，但里面还有一个 PoE 注入器和另一台 Wi-Fi AP——wilbur（不过是一台功耗更低的 Ubiquiti U7 Lite）。

总体来看还不错！还有很大的余量。

最后回到我的书房。记得我之前提过，那里有 nigel 这台 MikroTik CRS305-1G-4S+IN 交换机——四口 SFP+ 型号。我只获取了交换机本身的温度以及那块 10GBASE-T 模块的温度，DAC 线缆不提供读数。请看这张图，尤其是右边那个图表：

哎呀！交换机本体温度只有舒适的 48°C，但那个 SFP+ 模块却徘徊在 93°C 左右。这是内部温度而不是“可触摸”表面温度，但如果两者接近的话，那确实已经非常烫手了。我打算贴上一个小型贴片散热器——那种常用于树莓派的类型，看看是否有帮助。另外它还安装在 11 英寸机架内，也许能找到办法让它与机架实现更好的热传导。

尽管这些数值有点吓人，但系统运行一切正常！我在 perry 上定期运行网络测试，检查到 Google 8.8.8.8 DNS 服务器的端到端连接，从未发现异常。从 perry 到 reggie 的 iperf3 测试也显示错误数量几乎为零。

既然系统能正常工作，自然就想做些改动。改什么？

下一步该怎么做？

说实话，短期内我可能只会专注于解决那些令人担忧的温升问题。对于侧柜里的 reggie 和 norman，我认为再次把 winona 这个 Wi-Fi AP 移出去会有帮助。它支持以太网供电，所以我只需要拉一根线穿过墙壁，然后把 AP 藏在某幅画后面就行了。

对于 Nigel 上的近沸点 SFP+ 模块，研究交换机来说，贴上一个树莓派散热片（正如我之前所说）可能是一个不错的起点。如果还不够，或许可以加一个带风扇的散热器。那里的实际功耗并不高，只有大约 3W——之所以温度这么高，是因为它被安装在一个非常小的空间里。

更有趣的问题是，当需要升级到 40Gb/s 或更高速度时，我会怎么做？正如我在上一篇文章中提到的，10GBASE-T 基本上标志着我们过去 20 多年使用 RJ45 双绞线的时代的终结。显然，CAT-8 线缆可以达到 40Gb/s，但它也有自己的问题——它超级硬，很难绕过拐角或塞进墙插座后面有限的空间里。

我认为最合适的做法可能是转向光纤。在我还不确定现有布线是否可行的时候，我做过一些初步研究，看起来将每根电缆（即从墙插座到配线架的连接）至少替换为一根双光纤电缆（一根发送，一根接收）应该是可行的，甚至在有合适设备的情况下，最高可达 800Gb/s。墙插座可以是 LC 双工接口，这种设计在光纤标准下连接起来很方便。

如果我想真正为未来做好准备，甚至可以考虑铺设四芯或八芯光纤，然后把其中两根“留作暗线”。这样可能会为未来的升级留下更多空间，而且额外成本其实很低——安装费用远高于电缆本身的成本。

不过，每根电缆 drop 要几百欧元，再加上项目开销，我很庆幸现在不用这么做。能够把这个问题推迟到以后再做是个明智的决定；谁知道从现在开始，直到我的 ISP 提供更快网速之前，技术又会发生什么变化呢？

那么，让我们以大家肯定期待的时刻收尾……

高潮时刻来了

还不错！虽然没有达到宣传的 10Gb/s，但已经很接近了——而且我偶尔也能测到 9Gb/s（可惜没截图）。需要说明的是，这个速度是从 perry 那里测得的，也就是说数据经过了三个交换机 Nigel、Nelly 和 Norman，以及路由器 Reggie 的全部链路。直接从 Reggie 用 Ookla 测速工具的 CLI 版本测试也得到类似结果——事实上，奇怪的是，它们通常比从 perry 测得的速度慢约 5%。我不太明白为什么会这样，我得进一步调查。如果有人知道可能导致这种情况的原因，欢迎分享你的看法。

现在，当我上传模型到 Hugging Face、下载其他模型、同步大型 uv 环境、下载最新版 Arch ISO，同时还在播放音乐时，Sara 在看 Netflix，我的 Dropbox 也在正常同步——所有事情都能流畅运行。

太棒了！任务完成。希望这篇内容对正在考虑类似升级的人有所帮助。

好了，现在该回归我一贯的全 AI 内容了 ;-)