Turris Omnia NG 的 SFP+ 笼位：哪些第三方 RJ-45 铜模块真的能建立链路
我家里用一台 Turris Omnia NG，金属 WAN 口上现在挂着的最后一段是到 ISP 路由器两米的一跳。我想把这一跳挪到 SFP+ 笼位里，把铜口空出来给实验室那一侧用。官方的 Turris SFP+ 铜模块（RTROM01-RTSF-10G）价格差不多能买一台小交换机了，而且相当不好买到。
环境：
- Turris Omnia NG，官方固件，SFP+ 笼位目前是空的
- 到 ISP 路由器一段很短的 RJ-45 链路，那一侧是 1G
- 实验室那一侧有两台 10G 主机，我早晚想让它们跑得比 1G 快
- 抽屉里没有备用的铜质 SFP+ 模块可以先试
模块到手之后，我用来判断好坏的全部手段：
dmesg | grep -i sfp
ethtool -m eth2目前做过的：找过这个笼位的官方兼容性列表，什么都没找到，问过一个卖家如果模块起不来能不能退货。
所以问题很简单——大家实际在 NG 的笼位里用的是哪些 10G 或 2.5G 铜质 RJ-45 模块，又有哪些是已知起不来的？我宁愿买一个已经在别人那里正常服役的型号，也不想连续赌三次。
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
这个笼位没有厂商兼容性列表，以后也不会有——模块和固件的组合数量太多，维护这样一份列表并不现实，所以你能得到的只有用户的实际反馈。从大家在 NG 上用的情况看：10Gtek 的那种 1.25/2.5/5/10GBASE-T RJ-45 SFP+ 是最常见能用的一款，一个 ipolex 10GBASE-T 模块也能用，一个 MikroTik S+RJ10 也能用，一个便宜的 Xicom 2.5G 铜质 SFP 也有人反馈没问题。如果这一跳距离够短，10Gtek 的 DAC 线缆也在能用之列。反面例子是，有人反馈一个 Solarflare SFM10G-TX 不能用。
两个实用的建议。找一个接受退货的卖家买——这台主机在这方面的支持面很窄，你很可能最后是在换品牌，而不是在调试什么东西。另外要有心理准备，装在 SFP+ 外壳里的 10GBASE-T 模块运行起来会比较烫，如果路由器放在一个封闭的柜子里，这一点就很重要。
模块到手之后，插上去马上执行
dmesg | grep -i sfp，并读一下ethtool -m eth2。如果内核在那里都没能识别出这个模块，接口配置再怎么折腾也救不回来。给用经典款 Omnia（而不是 NG）来到这里的人补充一点。在那台设备上，这个笼位完全不会带来额外的接口。笼位和金属 WAN 插口共用同一个 MAC，也就是 eth2，任意时刻只有其中一个真正接到它上面——具体是哪一个，取决于路由器启动时加载的设备树 blob。所以一个完全健康的铜模块看起来会像彻底死掉一样：接口列表里不会多出任何新东西，而且只要模块插着，金属 WAN 口甚至连自己的地址都会丢掉。把 /boot/dtb 指向 SFP 那个变体，重启，情况就会不一样：
我在 TurrisOS 6.2.3 上用一个 FS 的 2.5GBASE-T 铜模块正是这么做的，重启之后 WAN 立刻以 2.5Gbps 起来了。我不知道 NG 是不是也需要类似的操作，但在把一个模块判定为故障之前，先查一下主机这一层。
谢了，这正是我想要的那份清单。准备订 10Gtek 的，而且要找一个接受退货的地方买。
有件事我本该写进问题里，因为官方模块在这些帖子里每次都会被提到：那个笼位里我之前确实装过 RTROM01-RTSF-10G。用了一段时间，大约一个月之后开始报连接错误，我放弃了，把这条链路挪回了普通的以太网口。所以在这里，贵的选项并不天然等于稳妥的选项——这正是我为什么要问大家实际在用的模块，而不是要一个推荐。
同一个问题的另一个角度，结论是一样的。在经典款 Omnia 上，我唯一能担保的模块是 TP-Link TL-SM321B——1000Base-BX 单纤双向，1310 nm，LC 接口。内核不用任何特殊处理就能识别它，实际负载吞吐大约能到 920 Mbit/s。也不用去纠结缺的那 80 Mbit/s 去哪了：线路本身跑的是 1.25 Gbit/s，算上 8b10b 编码和以太网帧开销之后，能用的速率正好落在这个数上。
同一台路由器上的一个反例：一个 CTS SFP-31W2ASM10-DR 在 Turris OS 3.x 上跑得很好，升到 4.0 之后就彻底不工作了——这里的罪魁祸首是重做过的 VLAN 和交换机配置模型，而不是模块本身。还要记住修复是从哪来的：SFP 相关的工作会先合入 OpenWrt 的 master 分支，很久之后才会出现在稳定版的 Turris 分支里，所以一个今天怎么都连不上的模块，几个版本之后可能就悄悄能用了。