Edgecore AS9716-32D: sfputil decodifica un módulo QSFP-DD de 400G como QSFP28 bajo PDDF
Estamos levantando un par de AS9716-32D como spine de 400G en el laboratorio, con una imagen SONiC comunitaria y la capa de plataforma PDDF. La óptica no es el problema, el enlace con el otro extremo funciona, pero todo lo que el switch dice sobre ella está mal.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- build SONiC comunitario con PDDF para esta plataforma
- módulo QSFP-DD de 400G (pieza NeoPhotonics) en la primera jaula
La lectura en sí tiene éxito, el módulo aparece listado, y la jaula se reporta como QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsEsa línea de identificador es donde todo se desmorona. Esto es una pieza QSFP-DD, así que los bytes de abajo se están decodificando contra el conjunto de campos SFF-8636 en lugar del de CMIS, y los campos que siguen parecen ruido.
Revisado hasta ahora:
- el módulo en sí está bien, la misma pieza se lee correctamente en otra plataforma y el otro extremo ve luz;
- reinsertarlo y moverlo a otra jaula no cambia nada, todos los puertos de 400G se comportan igual;
- en la descripción de dispositivo de PDDF estas jaulas están declaradas como QSFP28 y vinculadas a optoe1.
¿Es ese último punto toda la respuesta, las jaulas QSFP-DD simplemente necesitan un dispositivo optoe distinto, y editar la descripción de la plataforma es la forma aceptada de arreglarlo, o hay algo por encima que también necesita aprender el tipo de jaula?
Comments 4
Tu síntoma coincide exactamente con el enlace de dispositivo, así que no hace falta seguir mirando la óptica.
La descripción de dispositivo de PDDF para el AS9716-32D declara las jaulas de 400G como QSFP28 y las vincula a optoe1. optoe1 expone el diseño de EEPROM SFF-8636 que usan QSFP+ y QSFP28, así que un módulo CMIS se lee con el mapa equivocado y todo lo que va después del identificador parece ruido. El tipo de puerto que ves no se detecta en absoluto, es simplemente lo que dice la descripción.
QSFP-DD sigue CMIS, y CMIS se sirve mediante optoe3. La solución es invertir ambos campos en la descripción de dispositivo de PDDF para esas jaulas: el tipo de QSFP28 a QSFP-DD, y el driver de optoe1 a optoe3. Lo verifiqué en el mismo equipo con una pieza NeoPhotonics de 400G, y tras el cambio
sfputil show eepromdevuelve el módulo correctamente decodificado.Dos advertencias. Son datos de plataforma, así que una actualización de imagen volverá a poner la descripción antigua a menos que el cambio esté en la imagen que construyes. Y en upstream este cambio exacto fue aprobado pero el pull request se cerró sin fusionarse, ya que el trabajo se incorporó a un cambio posterior, así que no des por hecho que tu imagen ya lo trae. Lee primero la descripción de dispositivo de tu plataforma y en un minuto sabrás si estás persiguiendo algo real.
Antes de tocar ningún archivo de plataforma, publica el volcado crudo:
sudo sfputil show eeprom -den ese puerto. Si todos los bytes están ahí y solo falla la interpretación, esto es un problema de vinculación y no de módulo, y esa distinción vale diez minutos antes de que nadie empiece a hablar de un RMA.La otra mitad ya la has respondido tú mismo. optoe1 es la variante SFF-8636 usada para QSFP+ y QSFP28, así que un módulo CMIS leído a través de él sale desfigurado desde el identificador en adelante, que es exactamente la salida que pegaste. Una vez que la descripción nombra optoe1 para una jaula QSFP-DD ya no queda nada que sospechar del lado del módulo.
Así que pega también las líneas relevantes de la descripción de dispositivo de PDDF para una de esas jaulas. Eso nos dirá si solo está mal el campo del driver o también el tipo de jaula declarado.
Eso era. Tipo de jaula a QSFP-DD, driver a optoe3, recarga, y el módulo ahora se decodifica correctamente, con
sfputil show eepromya sin llamar QSFP28 a la jaula. Puse el cambio en la imagen que construimos en vez de parchear el switch en producción, precisamente por lo que se comentó sobre las actualizaciones.Una nota honesta para quien encuentre esto más tarde: arregla cómo se lee la EEPROM, nada más. El resto de la fontanería de transceptores en esta plataforma sigue teniendo sus propias rarezas, y yo no diría que el equipo está totalmente resuelto.
Ya que mencionas las rarezas que quedan, aquí está la que te espera en la misma plataforma. En nuestro AS9716-32D (x86_64-accton_as9716_32d-r0) con un build master de SONiC,
sudo sfputil show presencelista los puertos poblados como Present y lee bien su EEPROM, mientras queshow interfaces transceiver presencereporta todos los puertos como Not present. El syslog repite:y leer la EEPROM por la CLI falla con RuntimeError('PddfEeprom is not Programmed'). Aparece al azar tras un reinicio y nunca se publicó una causa raíz, así que sfputil sigue siendo la única comprobación de presencia en la que confío ahí.
Sin relación pero en la misma zona: los dos comandos también son conocidos por no coincidir en los nombres de las claves en la rama 202012, lo cual se limpió en 202205. Si tus salidas difieren en la redacción y no en el contenido, probablemente sea solo eso.