SONiC декодирует CMIS 4.0 QSFP-DD в искажённые поля вендора, тогда как модули SFF разбираются нормально

На какой вы ветке? Есть известные несоответствия имён ключей между show interfaces transceiver eeprom и sfputil в 202012, устранённые в 202205, и стоит сначала исключить это, прежде чем копать глубже.

Выложите вывод sudo sfputil show eeprom -d для того же порта. Если sfputil даёт вам те же искажённые строки, неисправность в общем пути декодирования. Если он выдаёт ошибку вместо этого, вы находитесь в другой ситуации - у нас есть платформы, где он просто отвечает Cannot get Module EEPROM data: Invalid argument и вообще не доходит до декодирования.

Запустил оба: sudo sfputil show eeprom -d и show interfaces transceiver eeprom -d на том же порту. Идентичное искажение, те же поля, тот же мусор там, где должен быть серийный номер. Нигде Invalid argument, само чтение проходит без жалоб.

То есть обе команды согласны друг с другом, они просто согласны в неправильном ответе. Соседние порты QSFP28 остаются чистыми в обеих, что делает проблему специфичной именно для этого компонента CMIS, а не для платформы.

Эта картина - типичный признак парсера, применённого к карте памяти, которую он не понимает: партномер сидит в поле имени вендора, серийный номер нечитаем, connector и encoding сдвинуты. Неисправный модуль или неисправное чтение по I2C дают ошибку или блок нулей, а не аккуратно неправильные строки.

Путь декодирования находится в sonic_platform_base/sonic_sfp/sfputilbase.py, и там три строки идентификации извлекаются по смещениям, жёстко зашитым под старую карту SFF, независимо от того, что реально подключено. Модуль CMIS 4.0 QSFP-DD не хранит свой блок идентификации по этим адресам - спецификация CMIS 4.0 описывает его в разделе 8.3 - так что код читает реальные байты из правильного модуля, просто не те, которые считает, что читает, и выводит то, что оказалось в этом диапазоне. Именно поэтому ничего никогда не падает чисто: ни один шаг не смотрит на байт идентификатора и не переключается на раскладку CMIS.

Практический вывод в том, что ничего, кроме парсера, понимающего карту CMIS, не даст правильного результата, и пока это не появится в вашей ветке, вывод CLI для этого компонента не годится для инвентаризации. Для базы активов читайте страницы в сыром виде и декодируйте их самостоятельно, а не парсите вывод CLI.

Для сырого чтения вам нужен драйвер optoe: он предоставляет EEPROM SFP, QSFP и CMIS для прямого чтения и записи, так что можно вытащить байты и декодировать их своим скриптом. Это единственное, чем я бы сейчас питал базу активов для компонентов CMIS.

Одно предупреждение, если будете искать смещения. Таблица, которую все цитируют, - это таблица SFF: байты A0h 20-35 для имени вендора, 40-59 для PN, ревизии и SN. Это именно те смещения, которые дают вам мусор на модуле CMIS, так что не используйте их там. Та же осторожность и на Linux-хосте как настольном инструменте: ethtool -m для декодированного вида и ethtool -e для сырых байтов подходят для компонентов SFP, но проверьте, что ваша сборка реально понимает, прежде чем доверять полям, которые она выводит для CMIS.

Поддержка CMIS слаба не только в декодере EEPROM. Мы ввели в эксплуатацию партию оптики InnoLight 800G QSFP-DD, T-DP8CNH-NNO и T-DP8CNT-NNO, и примерно каждая вторая установка оставляла нас с мёртвым портом: датапути сообщали DataPathDeactivated, в логе был таймаут для 'ConfigSuccess', и после этого порт был down постоянно - без повтора, без чего-либо, что вернуло бы его самостоятельно.

Виновником оказалась decommission_all_datapaths() в cmis.py. Она проходит всю последовательность подряд - DEINIT, обнуление ID приложения, затем INIT - и никогда не проверяет, что шаг реально сработал, прежде чем начать следующий. Нашим компонентам нужно именно это подтверждение, поэтому датапуть остаётся наполовину сконфигурированным, а конечный автомат просто досиживает свой таймер. Настоящее исправление должно ждать асинхронно, поскольку внутри встроенного конечного автомата CMIS в xcvrd блокироваться нельзя, и на момент, когда я проверял в последний раз, никто такого не выкатил. Другой баг, та же тема: путь CMIS, прикрученный к коду, написанному для компонентов SFF.

Одна поправка к направлению, куда всё это сползает, потому что два вида отказов постоянно путают. Cannot get Module EEPROM data: Invalid argument, или QSFP, исчезающий из sfputil после power cycle, пока не исправлен драйвер, или платформа, которая просто не реализует get_transceiver_info - это пробелы платформы и драйвера, и они останавливают вас до того, как начнётся какое-либо декодирование.

Здесь же описано обратное: полное, успешное чтение, которое затем интерпретируется с неправильной раскладкой полей. Не меняйте модули и не гоняйтесь за версиями драйвера из-за этого. Байты внутри этого модуля в порядке, и любой инструмент, декодирующий их как CMIS, покажет вам серийный номер с этикетки.