Edgecore AS9716-32D: sfputil decodifica um módulo QSFP-DD de 400G como QSFP28 no PDDF
Estamos subindo um par de AS9716-32D como spine de 400G no laboratório, numa imagem SONiC da comunidade com a camada de plataforma PDDF. A óptica não é o problema, o peer linka direitinho, mas tudo que o switch fala sobre eles está errado.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- build SONiC da comunidade com PDDF para essa plataforma
- módulo QSFP-DD de 400G (peça NeoPhotonics) no primeiro slot
A leitura em si funciona, o módulo aparece listado, e o slot é reportado como QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsÉ na linha do identifier que desanda. Essa é uma peça QSFP-DD, então os bytes abaixo estão sendo decodificados contra o conjunto de campos do SFF-8636 em vez do CMIS, e os campos seguintes saem como ruído.
Já verificado até agora:
- o módulo em si está bom, a mesma peça lê certo em outra plataforma e o outro lado vê luz;
- reencaixar e mover para outro slot não muda nada, todas as portas de 400G se comportam igual;
- na descrição de dispositivo do PDDF esses slots estão declarados como QSFP28 e amarrados ao optoe1.
Esse último ponto é a resposta inteira, os slots QSFP-DD simplesmente precisam de um optoe diferente, e editar a descrição da plataforma é o jeito aceito de corrigir isso, ou tem algo acima que também precisa aprender o tipo do slot?
Comments 4
Seu sintoma bate exatamente com o binding, então não precisa olhar mais para a óptica.
A descrição de dispositivo do PDDF para o AS9716-32D declara os slots de 400G como QSFP28 e amarra eles ao optoe1. O optoe1 expõe o layout de EEPROM do SFF-8636 que QSFP+ e QSFP28 usam, então um módulo CMIS é lido pelo mapa errado e tudo depois do identifier vira ruído. O tipo de porta que você vê não é detectado de verdade, é simplesmente o que a descrição diz.
QSFP-DD segue o CMIS, e o CMIS é servido pelo optoe3. A correção é trocar os dois campos na descrição de dispositivo do PDDF para esses slots: o tipo de QSFP28 para QSFP-DD, e o driver de optoe1 para optoe3. Verifiquei isso na mesma caixa com uma peça NeoPhotonics de 400G, e depois da mudança o
sfputil show eepromretorna o módulo decodificado direito.Duas ressalvas. É dado de plataforma, então um upgrade de imagem coloca a descrição antiga de volta com o maior prazer, a menos que a mudança esteja na imagem que você constrói. E lá na origem essa mudança exata foi aprovada mas o pull request foi fechado sem ser mesclado, o trabalho tendo sido incorporado numa mudança posterior, então não assuma que sua imagem já carrega isso. Leia primeiro a descrição de dispositivo da sua plataforma e em um minuto você já sabe se tem alguma coisa para correr atrás.
Antes de mexer em qualquer arquivo de plataforma, posta o dump bruto:
sudo sfputil show eeprom -dnessa porta. Se todos os bytes estão lá e só a interpretação está errada, isso é um problema de binding e não de módulo, e essa distinção vale dez minutos antes de alguém começar a falar em RMA.A outra metade você já respondeu sozinho. O optoe1 é a variante SFF-8636 usada por QSFP+ e QSFP28, então um módulo CMIS lido por ele sai bagunçado a partir do identifier, que é exatamente a saída que você colou. Uma vez que a descrição nomeia optoe1 para um slot QSFP-DD não sobra nada para suspeitar do lado do módulo.
Então cola também as linhas relevantes da descrição de dispositivo do PDDF para um desses slots. Isso diz se só o campo do driver está errado ou o tipo de slot declarado também.
Era isso mesmo. Tipo do slot para QSFP-DD, driver para optoe3, reload, e o módulo decodifica direito agora, com o
sfputil show eepromnão chamando mais o slot de QSFP28. Coloquei a mudança na imagem que construímos em vez de aplicar no switch rodando, justamente por causa do ponto do upgrade lá em cima.Uma nota honesta para quem achar isso depois: isso corrige como o EEPROM é lido, nada mais. O resto da tubulação de transceiver nessa plataforma ainda tem suas próprias esquisitices e eu não diria que a caixa está totalmente resolvida.
Já que você mencionou as esquisitices que sobram, aqui está a que está te esperando na mesma plataforma. No nosso AS9716-32D (x86_64-accton_as9716_32d-r0) rodando uma build master do SONiC, o
sudo sfputil show presencelista as portas ocupadas como Present e lê o EEPROM delas sem problema, enquanto oshow interfaces transceiver presencereporta todas as portas como Not present. O syslog repete:e ler o EEPROM pela CLI falha com RuntimeError('PddfEeprom is not Programmed'). Isso aparece aleatoriamente depois de um reboot e nenhuma causa raiz jamais foi postada, então o sfputil continua sendo a única verificação de presença em que confio ali.
Sem relação mas na mesma área: os dois comandos também são conhecidos por discordar nos nomes de chave na branch 202012, que foi limpa na 202205. Se suas saídas diferem no texto e não no conteúdo, provavelmente é só isso.