SONiC decodifica un QSFP-DD CMIS 4.0 con campos de vendedor corruptos mientras los módulos SFF se leen bien

¿En qué rama estás? Hay inconsistencias conocidas de nombres de clave entre show interfaces transceiver eeprom y sfputil en 202012 que se resolvieron en 202205, y vale la pena descartar eso antes de investigar más a fondo.

Publica la salida de sudo sfputil show eeprom -d para el mismo puerto. Si sfputil te da las mismas cadenas corruptas, la falla está en la ruta de decodificación compartida. Si en cambio da error, estás en otro terreno distinto, tenemos plataformas donde simplemente responde Cannot get Module EEPROM data: Invalid argument y nunca llega a decodificar nada.

Corrí ambos: sudo sfputil show eeprom -d y show interfaces transceiver eeprom -d en el mismo puerto. Corrupción idéntica, mismos campos, misma basura donde debería estar la serie. No sale Invalid argument en ninguna parte, la lectura en sí pasa sin quejarse.

Así que los dos comandos coinciden entre sí, solo que coinciden en la respuesta equivocada. Los puertos QSFP28 vecinos se mantienen limpios en ambos, lo cual hace que parezca específico de esta pieza CMIS más que de la plataforma.

Ese patrón es la firma de un parser aplicado a un mapa de memoria que no entiende: un número de parte sentado en el campo del nombre del vendedor, una serie ilegible, connector y encoding desplazados. Un módulo dañado o una lectura I2C rota te da un error o un bloque de ceros, no cadenas equivocadas de forma ordenada.

La ruta de decodificación vive en sonic_platform_base/sonic_sfp/sfputilbase.py, y ahí las tres cadenas de identidad se sacan de offsets fijos codificados contra el mapa SFF heredado, sea lo que sea que esté conectado. Un QSFP-DD CMIS 4.0 no guarda su bloque de identidad en esas direcciones, la especificación CMIS 4.0 lo describe en la sección 8.3, así que el código está leyendo bytes genuinos del módulo correcto, solo que no los que cree que está leyendo, e imprime lo que sea que ocupe ese rango. Esa es también la razón por la que nada falla limpiamente: ningún paso mira el byte identificador y cambia a un layout CMIS.

La conclusión práctica es que nada, salvo un parser que entienda el mapa CMIS, va a hacer esto bien, y hasta que eso llegue a tu rama, la salida del CLI para esta pieza no es de calidad para inventario. Para la base de datos de activos, lee las páginas en crudo y decodifícalas tú mismo en vez de raspar el CLI.

Para la lectura en crudo, el driver optoe es lo que quieres: expone las EEPROM de SFP, QSFP y CMIS para lectura y escritura directa, así que puedes sacar los bytes y decodificarlos en tu propio script. Eso es lo único que yo alimentaría a una base de datos de activos para piezas CMIS por ahora.

Una advertencia si vas a buscar offsets. La tabla que todos citan es la de SFF, bytes 20-35 de A0h para el nombre del vendedor, 40-59 para PN, revisión y SN. Esos son exactamente los offsets que producen tu basura en un módulo CMIS, así que no los reutilices ahí. Misma precaución en un host Linux como herramienta de banco: ethtool -m para la vista decodificada y ethtool -e para bytes en crudo están bien para piezas SFP, pero revisa qué entiende realmente tu build antes de confiar en los campos que imprime para CMIS.

El manejo de CMIS es débil en más sitios que el decodificador de EEPROM. Pusimos en servicio una bandeja de ópticos InnoLight QSFP-DD de 800G, T-DP8CNH-NNO y T-DP8CNT-NNO, y más o menos cada segunda inserción nos dejaba con un puerto muerto: los datapaths reportaban DataPathDeactivated, el log traía un timeout para 'ConfigSuccess', y de ahí en adelante el puerto quedaba caído permanentemente, sin reintento, nada que lo recuperara por sí solo.

El culpable resultó ser decommission_all_datapaths() en cmis.py. Recorre toda la secuencia una tras otra, DEINIT, ID de aplicación puesto a 0, luego INIT, y nunca comprueba que un paso realmente surtió efecto antes de empezar el siguiente. Nuestras piezas necesitan exactamente esa confirmación, así que el datapath queda medio configurado y la máquina de estados simplemente agota su temporizador. Un arreglo real tiene que esperar de forma asíncrona, ya que no puedes bloquear dentro de la máquina de estados CMIS en línea de xcvrd, y la última vez que revisé nadie había subido uno. Bug distinto, mismo tema: una ruta CMIS pegada a código escrito para piezas SFF.

Una corrección al rumbo hacia donde va esto, porque los dos modos de falla se mezclan constantemente. Cannot get Module EEPROM data: Invalid argument, o un QSFP que desaparece de sfputil tras un ciclo de energía hasta que se arregla el driver, o una plataforma que simplemente no implementa get_transceiver_info, esos son huecos de plataforma y de driver, y te detienen antes de que ocurra cualquier decodificación.

Lo que se describe aquí es lo opuesto: una lectura completa y exitosa que luego se interpreta con el layout de campos equivocado. No cambies módulos ni persigas versiones de driver por esto. Los bytes dentro de ese módulo están bien, y cualquier herramienta que los decodifique como CMIS te va a mostrar la serie de la etiqueta.