厂商锁定与“不支持的光模块”

这是最常见的光模块问题。交换机和网卡厂商（Cisco、Intel、HPE/Aruba、Juniper、Mellanox 等）检查模块从其 EEPROM 报告的识别字符串，拒绝或标记它们无法识别的模块。

工程师往往要吃过亏才明白关键的一点："不支持"不代表"无法工作"。在大多数平台上，该状态只是提示信息，端口仍然可以被激活。

现象

平台	现象
Cisco IOS	端口 `notconnect — unsupported`；日志 `%C4K_TRANSCEIVERMAN-3-INCOMPATIBLE`
Cisco IOS（升级后）	端口进入 `errdisable`，原因为 `gbic-invalid`
Mellanox	已读取 EEPROM 但无链路：`speed and type: Not supported`
Intel X520 / ixgbe	使用非 Intel SFP 时出现 `no carrier`

Cisco。 以下两条命令通常写入基础配置，用于在所有端口上放行第三方模块：

service unsupported-transceiver
no errdisable detect cause gbic-invalid

平台差异：在部分 Catalyst 9200 版本上，第一条命令会返回 % Ambiguous command，需要完整输入命令；在 Nexus 9000 上它是隐藏命令，没有 Tab 补全，但可以正常执行。

Intel X520（Linux）。 加载驱动时使用允许非 Intel 模块的选项：

modprobe ixgbe allow_unsupported_sfp=1

还存在一种持久化方案，会翻转网卡自身 EEPROM 中的一个位，相关做法在下方来源中有记录；操作时需谨慎，因为对网卡 EEPROM 的错误写入在现场是无法恢复的。

ASR 9000 系列。 插入已经 up 的端口时，模块可能不会被识别：先 shut 该端口，插入模块，再执行 no shut。

彻底的解决办法：对模块重新编码。 重写模块的厂商 ID 和料号，使其表现为原生模块。这正是 CodingBox 在 EEPROM 编辑器中所做的：先备份，再重新计算 CC_BASE/CC_EXT。具体过程见 EEPROM 重新编码。

每种型号都在库房留一个原厂 OEM 模块。开工单之前先换上它，让厂商无法把问题归咎于第三方光模块。

完成上述操作后，需确认模块已被识别并读取：各操作系统的具体命令见在交换机上验证光模块，并与 CodingBox 在工作台上读取的身份信息进行比对。

主机具体比对什么（名称、料号、OUI、序列号格式、厂商签名）以及在上电流程的哪一步拒绝模块，见：厂商字段、主机的处理流程。

各厂商的校验行为与覆盖方式汇总在一张表中：各操作系统如何校验模块；平台期望的具体料号字符串：OEM 料号；各操作系统的命令语法：端口配置速查。

如果您发现本资料中有不准确之处或错误，请选中相应片段并按 Ctrl+Enter，即可。