SONiC 上 QSFP28 笼子里插 QSA 转接头：10G 光模块能连上，但读不到 DDM
我们在一台运行 SONiC 的白牌交换机上重用一堆 10G 光模块，所以有几个 QSFP28 笼子装了 QSA 型转接头（10GTek QSA-100A），插的是普通的 10G SFP+ 模块。机械和电气层面这没问题。出问题的是管理面这一侧。
- 交换机：1U 白牌，为该平台构建的 SONiC
- 转接头：10GTek QSA-100A，QSFP28 笼子转 SFP+
- 光模块：从一台退役的接入交换机上拆下来的 10G SFP+ 模块
- 同样的光模块在另一台设备的原生 SFP+ 笼子里读取正常
转接端口上我看到的情况：
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the port已经试过的：
- 换了第二个转接头和第二个光模块，现象一样；
- 把这一对挪到另一个 QSFP28 笼子里，结果一样；
- 确认过这些光模块在别处的原生 SFP+ 端口上能报出完整的诊断信息。
缺失的诊断数据，是无源转接头本身就没法传递的，还是交换机软件那边的问题？如果是软件问题，应该在哪一层修：平台层还是通用的收发器代码？
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 7
在有人去翻平台代码之前，先问一个能把问题一分为二的问题。往同一个笼子里插一个原生的 QSFP28 模块：能读到诊断信息，还是这个端口不管插什么 DDM 都是死的？
如果原生模块读取正常，说明笼子和 I2C 通路是好的，整个问题就归结为端口驱动怎么解读经转接头传过来的数据。如果原生模块读回来也是空的，那就不用再看下面的讨论了，你遇到的是另一个完全不同的故障，跟转接头没关系。
这是管理接口上一个众所周知、也相当无趣的差异，转接头在这里是无辜的。
在 SFP 那一侧涉及两个 I2C 地址：身份识别数据在 0x50，诊断数据映射在 0x51。而 QSFP 部件把所有东西都放在 0x50 下面，通过切换页面访问其余内容。所以一个被告知这个笼子是 QSFP 的驱动，会去单一地址下找页面，从来不会去问 0x51 任何东西。身份识别信息读回来足够像样，端口能起来，诊断信息却永远解析不出来，这正是你贴出来的那种现象。
这个修复应该落在平台层，跟光模块和转接头都无关。每个平台都有自己的 SfpUtil 实现；在你这个平台上，得把这个端口声明为 SFP 笼子而不是 QSFP 笼子。在有人这么做之前，转接端口的 DDM/DOM 就会一直是空的。改完之后，模块的读取方式就会跟原生 SFP+ 笼子一样了。
链路正常但诊断信息背后什么都没有，这在这类端口上是软件出错的样子，而不是光模块状态临界的样子。
值得把标准名字点出来，这样这个划分就一目了然了。SFP 那一侧走的是 SFF-8472，诊断信息在自己的一张内存映射表里，通过第二个地址访问。QSFP 和 QSFP28 遵循 SFF-8636，更新的部件用 CMIS，这两者都是所有东西挂在同一个地址下面、通过选页访问。
转接头没法弥合这个差异。它是一个纯粹的机械和电气部件，管理线直通过去，中间没有任何东西做转换。所以在读任何一个字节之前，主机必须被告知这两种内存模型里哪一种适用，而转接头根本没有办法告诉它这件事。
作为对比，Dell 的 ONIE 硬件上同一类问题咬得更狠。一个 407-BBRO 型 QSA，里面插着 407-BBOU 10GBASE-SR SFP+（也就是 SFP-10GSR-85），插在一台 S4048-ON 的 40G 端口上、以及任意一台 S6010-ON 的端口上，两者都跑 OpenSwitch OPX 3.1 dev2：
opx-ethtool 能正确识别介质类型，标记收发器为已启用且合格，admin state 为 up，支持的速率有 1000、10000 和 40000 Mbps，但端口始终起不来，不管怎么配速率、双工或自协商，包括默认值都一样。有人在 OPX platform-config 仓库开了一个增强需求：请让 QSA 在这上面能用，但一直没人回复，到现在还是打开状态。
这不是厂商锁定，也不是坏模块。是这个笼子从来没被网络操作系统切换到转接模式，任何接口设置组合都做不到这一点。
相关，但请别把这两个情况混为一谈。楼主遇到的是链路能用但诊断信息缺失：数据通路是好的，只是管理面的读取出了错，修改平台的 SfpUtil 就能解决。Dell 那个例子是端口压根就起不来，因为那个笼子对应的端口配置从一开始就没被应用。那是更下面一层的问题，需要它自己的修复。
如果有人急着按现象对号入座，很可能白白花一整天去改收发器代码，而实际上端口 down 的原因完全是另一回事。
另一种"转接头其实是个软件特性而不是机械特性"的表现。在一台运行 OS10 10.5.2.7 的 Z9264F-ON 上，要用 QSA28 转接头接 10G SFP+ 介质，就得把端口放进跟 4x10G 拆分线缆一样的 port-group 配置里：
这个平台上 port-group 配置是作用在成对的 QSFP28 端口上的，所以应用这个配置会禁用每一对里的伙伴端口。QSA28 明明是单个接口，你却要付出跟拆分线缆一样的代价：64 个可用端口变成 32 个。OS10 的用户手册和 Dell 的光模块规格书都没有记录过单端口的 QSA 模式。
如果这台设备上需要大量原生 10G，最好提前把这个 2:1 的损耗算进规划里，或者在机架里单独放一台 10G 交换机。
在有人下单一整托这种东西之前，我会列两项要检查的内容。网络操作系统到底有没有针对这个具体平台声明支持 QSA，如果有，打开它要付出什么代价：端口数、诊断信息，还是一个会把相邻笼子也一起拖下水的配置。物理兼容从来都不是问题，这些转接头插进笼子都毫无怨言。
这个帖子里的几个例子区别只在于软件走到了哪一步。在 SONiC 上你能得到一个自己可以修的东西，把端口声明为 SFP，诊断信息就回来了。在上面说的那些 Dell 平台上，你得等别人去改平台代码，换转接头或者换光模块对此毫无帮助。