SONiC decodifica um QSFP-DD CMIS 4.0 em campos de vendor embaralhados, enquanto módulos SFF são interpretados corretamente

Em qual branch você está? Existem inconsistências conhecidas de nome de chave entre show interfaces transceiver eeprom e o sfputil na 202012 que foram resolvidas na 202205, e vale a pena descartar isso antes de cavar mais fundo.

Poste a saída de sudo sfputil show eeprom -d para a mesma porta. Se o sfputil te der as mesmas strings embaralhadas, a falha está no caminho de decodificação compartilhado. Se ele der erro em vez disso, você está em outro território - temos plataformas onde ele só responde Cannot get Module EEPROM data: Invalid argument e nem chega perto de decodificar nada.

Rodei os dois: sudo sfputil show eeprom -d e show interfaces transceiver eeprom -d na mesma porta. Embaralhamento idêntico, mesmos campos, mesmo lixo onde deveria estar o serial. Nenhum Invalid argument em lugar nenhum, a leitura em si passa sem reclamar.

Então os dois comandos concordam entre si, só que concordam na resposta errada. As portas QSFP28 vizinhas continuam limpas nos dois, o que faz parecer específico dessa peça CMIS, e não da plataforma.

Esse padrão é a assinatura de um parser aplicado a um mapa de memória que ele não entende: um part number sentado no campo do nome do vendor, um serial ilegível, connector e encoding deslocados. Um módulo quebrado ou uma leitura I2C quebrada te dá um erro ou um bloco de zeros, não strings erradas de forma organizada.

O caminho de decodificação mora em sonic_platform_base/sonic_sfp/sfputilbase.py, e ali as três strings de identidade são retiradas de offsets fixos no código, escritos contra o mapa SFF legado, seja lá o que estiver conectado. Um QSFP-DD CMIS 4.0 não mantém o bloco de identidade nesses endereços - a especificação CMIS 4.0 descreve isso na seção 8.3 - então o código está lendo bytes genuínos do módulo certo, só que não os que acredita estar lendo, e imprime o que quer que ocupe aquela faixa. É também por isso que nada nunca falha de forma limpa: nenhuma etapa olha o byte identificador e muda para um layout CMIS.

A conclusão prática é que nada menos que um parser que entenda o mapa CMIS vai acertar isso, e até que isso chegue no seu branch, a saída da CLI para essa peça não tem qualidade de inventário. Para o banco de dados de ativos, leia as páginas em bruto e decodifique você mesmo, em vez de raspar a CLI.

Para a leitura em bruto, o driver optoe é o que você quer: ele expõe as EEPROMs de SFP, QSFP e CMIS para leitura e escrita direta, então você consegue puxar os bytes e decodificar no seu próprio script. É a única coisa que eu alimentaria num banco de dados de ativos para peças CMIS no momento.

Um aviso se você for atrás de offsets. A tabela que todo mundo cita é a da SFF - A0h bytes 20-35 para o nome do vendor, 40-59 para PN, rev e SN. Esses são exatamente os offsets que produzem o seu lixo num módulo CMIS, então não reuse eles ali. Mesma cautela num host Linux como ferramenta de bancada: ethtool -m para a visão decodificada e ethtool -e para bytes em bruto são bons para peças SFP, mas confira o que o seu build realmente entende antes de confiar nos campos que ele imprime para CMIS.

O tratamento de CMIS é raso em mais lugares do que só o decodificador de EEPROM. Colocamos em serviço uma bandeja de ópticas InnoLight 800G QSFP-DD, T-DP8CNH-NNO e T-DP8CNT-NNO, e mais ou menos a cada segunda inserção sobrava uma porta morta: os datapaths reportavam DataPathDeactivated, o log carregava um timeout para 'ConfigSuccess', e a partir daí a porta ficava down permanentemente - sem retry, nada que trouxesse ela de volta sozinha.

O culpado acabou sendo o decommission_all_datapaths() no cmis.py. Ele percorre a sequência inteira de uma vez - DEINIT, ID de aplicação zerado, depois INIT - e nunca checa se um passo realmente fez efeito antes de começar o próximo. Nossas peças precisam exatamente dessa confirmação, então o datapath fica meio configurado, e a máquina de estados simplesmente espera o timer dela passar. Uma correção de verdade tem que esperar de forma assíncrona, já que você não pode bloquear dentro da máquina de estados CMIS inline do xcvrd, e da última vez que conferi, ninguém tinha lançado uma. Bug diferente, mesmo tema: um caminho CMIS parafusado em cima de código escrito para peças SFF.

Uma correção para a direção que isso está tomando, porque os dois modos de falha se misturam o tempo todo. Cannot get Module EEPROM data: Invalid argument, ou um QSFP sumindo do sfputil depois de um power cycle até o driver ser corrigido, ou uma plataforma que simplesmente não implementa get_transceiver_info - essas são lacunas de plataforma e driver, e elas te param antes de qualquer decodificação acontecer.

O que está descrito aqui é o oposto: uma leitura completa e bem-sucedida que depois é interpretada com o layout de campos errado. Não troque módulos nem corra atrás de versões de driver por causa disso. Os bytes dentro daquele módulo estão bons, e qualquer ferramenta que os decodifique como CMIS vai te mostrar o serial da etiqueta.