第三方 DWDM SFP+ 在运行 EOS 4.10.6 的 Arista 7050T 上一直起不来 - 除了打补丁改镜像还有别的办法吗？
我们维护一个小型区域网络，从库存里翻出一台备用的 7050T 打算用作 DWDM 汇聚设备。Arista 原厂编码的 DWDM 光模块报价接近这台交换机本身的价格，所以我们改买了第三方的 DWDM SFP+，结果交换机根本不认它们。
- Arista 7050T，EOS 4.10.6
- 通用的第三方 DWDM SFP+，没有 Arista 编码
- 对端是非 Arista 设备，同样的模块在那边插上就正常起来，毫无问题
一插上这些模块，端口就一直是 down 的。据我判断，transceiver agent 会在端口被允许 up 之前先校验模块，而非 Arista 模块的存在性和认证检查根本就通不过：
/usr/lib/python2.7/site-packages/XcvrAgent.py, around line 172
assert xcvrStatus.presence == 'xcvrPresent'我已经做过的事：
- 重新插拔并换了好几个端口试，结果都一样
- 把一个 Arista 编码的 10G 模块插到同一个端口，立刻就起来了，所以端口、跳线、光纤本身都没问题
- 找过能放松这个检查的配置开关，这个版本上什么都没找到
我一直在琢磨重新构建 EOS 镜像、把那几行注释掉。在真走这条路之前想问一下：有没有官方支持的办法让这台设备接受这些光模块？如果在 4.10.6 上打补丁改镜像真的是唯一办法，那之后要付出什么代价？
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 6
在有人建议你改镜像之前，先问两件事。
这台 7050T 到底被锁定在哪个 EOS 分支上？如果必须留在 4.10.6，那针对这个版本的定制补丁至少还算自洽。如果可以升级，要明白后续版本里 transceiver 的处理逻辑已经重构过，针对 4.10.6 写的方法搬不过去。
另外，那家供应商到底能给模块烧录成什么样？值得问一下他们的编程器里到底有没有 Arista 的配置，还是只有大多数厂商都保留的那种按平台区分的 Cisco 编码 —— 比如 ASR9K 用的模块就需要专门的配置，光模块厂商确实也维护着这一份。把这批货重新编码，比长期靠一个改过的镜像便宜得多。另外单独问一句：你有没有找你的客户经理要过 unsupported-transceiver 密钥，还是出于商务原因这条路走不通？
这个镜像补丁在这个具体版本上确实管用，而且工作量不大 —— 但一定要在实验室设备或备用设备上做，绝不要在跑业务流量的设备上动手。
大致流程：解压 EOS-4.10.6.swi，保留其中的 boot0、initrd-i386、linux-i386、rootfs-i386.sqsh 和 version 这几个成员。以 root 权限解包根文件系统，修改 agent，再重新打包：
要改的地方在 squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py：把第 172 行附近那四行 —— 断言存在状态、然后执行 transceiver 认证的代码 —— 注释掉。zip 命令里的
-Z store不是可选项，swi 必须保持不压缩，否则设备启动不了。改完之后随便插什么模块端口都能起来，因为已经没有任何校验了。代价有两个：改过的镜像没有厂商支持，而且这个补丁是绑定这个具体版本的，所以 flash 上要留一份原厂 .swi，出问题时能启回去。
回答一下前面的问题：这台设备是没有支持合同的备用机，而供应商的编程器里根本没有 Arista 的配置 —— 他们只给 Cisco 平台编码，仅此而已，所以这批货重新编码是没法做的。找客户经理这条路也没有排除，只是这周解决不了问题。
我按上面说的重新构建了 4.10.6，启动补丁镜像后，两个 DWDM 端口第一次尝试就起来了。原厂镜像还在 flash 上留着。链路一直很稳定，对端也没看到任何异常。
很高兴这管用了，但你自己心里要清楚这个补丁的有效期有多短，因为前面这段讨论听起来比实际情况更通用。
它就是针对 4.10.6 写的，别的版本不行。有人问过怎么在 4.14.5F、4.14.7M 和 4.23.8M 上重复这个做法，没人给出过能用的答案，因为后续版本里 transceiver manager 已经重构过，那四行代码根本不在原来的位置等着你。而且每次升级都会替换镜像，补丁就没了，下次有人做例行维护端口就会掉。
能在升级之后还保得住的办法，是客户经理签发的那种按客户定制的
service unsupported-transceiver密钥，以及老平台上的 enable3px 标记文件。把改过的镜像当成让一台旧设备继续能用的手段就行，不要把它当成网络的标准做法。Cisco 那边也遇到过同样的问题，有个细节值得说一下。第三方的 80 km DWDM SFP+（Pro10Optix，标注为 SFP-10G-DWDM-192）在 Catalyst 6500 交换机上一直用得好好的。换到 ASR 9001 的内置 SFP+ 端口、跑 IOS XR 5.3.3 之后，报出：
端口 LED 变红，接口 down，状态报告为 link loss 或低光功率、无回环，波长读回来是 0 nm，激光器根本没有发光。在接口上配置
transceiver permit pid all本身没有任何变化，加上全局的service unsupported-transceiver也没能救回这批模块。这个平台要求料号符合自己光模块矩阵里 DWDM-SFP10G-xx.yy 这种格式，通用 PID 根本对应不到任何被支持的光模块，所以覆盖开关也没有可以放松的余地。同一版本上有人用 Skylane SPDTU080100D139 的 80 km 模块在 9001 上跑通了 —— 但前提是两条命令都配置上，否则链路抖动之后接口就恢复不了。那批出问题的模块最后换成了正确编码的模块。
补充一点，能帮你少跑一趟供应商那边：让他们按平台编码，而不是按品牌编码。这类帖子里很大一部分情况是模块厂商信息识别对了，但料号是平台矩阵里根本没见过的，而 permit 类的覆盖开关只对那些在设备看来本来就基本对的模块起放松作用。
趁模块还在他们那边的测试台上，让他们确认 EEPROM 严格符合 SFF-8472 规范。A2h 数据写得潦草的话读出来就是一堆乱码 —— 前面说的 0 nm 波长正是这种情况 —— 一旦读数干净了，平台还是拒绝这个模块，你手上就有具体证据去找厂商支持，而不是泛泛地争论第三方光模块行不行。