廠商鎖定與「unsupported transceiver」

這是最常見的光模組問題。交換機和網卡廠商（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，即可。