Adaptador QSA en una jaula QSFP28 de SONiC: el óptico de 10G enlaza pero no reporta DDM
Estamos reutilizando un montón de ópticos de 10G en un switch whitebox corriendo SONiC, así que un par de jaulas QSFP28 llevan adaptadores tipo QSA (10GTek QSA-100A) con módulos SFP+ de 10G comunes. Mecánica y eléctricamente esto está bien. Donde se cae es en el lado de la gestión.
- switch: whitebox de 1U, SONiC compilado para esa plataforma
- adaptadores: 10GTek QSA-100A, de jaula QSFP28 a SFP+
- ópticos: módulos SFP+ de 10G sacados de un switch de acceso dado de baja
- los mismos ópticos se leen normalmente en una jaula SFP+ nativa en otro equipo
Lo que veo en los puertos adaptados:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portLo que ya probé:
- cambié a un segundo adaptador y un segundo óptico, comportamiento idéntico;
- moví el par a otra jaula QSFP28, mismo resultado;
- verifiqué que los ópticos reportan diagnóstico completo en un puerto SFP+ nativo en otro lado.
¿Es que los datos de diagnóstico faltantes son algo que un adaptador pasivo simplemente no puede transportar, o es cosa del software del switch? Y si es software, ¿dónde va el arreglo: en la capa de plataforma o en el código genérico de transceptores?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
Antes de que alguien se meta en el código de plataforma, una pregunta que divide esto en dos. Pon un módulo QSFP28 nativo en esa misma jaula: ¿obtienes diagnóstico de él, o el DDM está muerto en ese puerto sin importar lo que conectes?
Si la pieza nativa se lee bien, la jaula y la ruta I2C están sanas y todo se reduce a cómo el driver del puerto interpreta lo que llega a través del adaptador. Si la pieza nativa también vuelve en blanco, deja de leer el resto del hilo, tienes una falla distinta y no tiene nada que ver con los adaptadores.
Diferencia bien conocida y bastante aburrida en la interfaz de gestión, y el adaptador no es el culpable aquí.
Del lado SFP hay dos direcciones I2C en juego: los datos de identificación viven en 0x50, el mapa de diagnóstico en 0x51. Una pieza QSFP guarda todo bajo 0x50 y alcanza el resto cambiando de página. Así que un driver al que se le dijo que la jaula es QSFP va a buscar páginas en una sola dirección y nunca le pregunta nada a 0x51. La identificación vuelve lo bastante plausible como para que el puerto suba, el diagnóstico simplemente nunca se resuelve, que es exactamente la forma de lo que publicaste.
El arreglo va en la capa de plataforma, no en el óptico ni en el adaptador. Cada plataforma trae su propia implementación de SfpUtil; en la tuya ese puerto tiene que declararse como jaula SFP en vez de QSFP. Hasta que alguien haga eso, el DDM/DOM en los puertos adaptados se queda vacío. Después, el módulo se lee tal como se leería en una jaula SFP+ nativa.
Un enlace vivo sin nada detrás en el diagnóstico es lo que se ve cuando el software está mal en estos puertos. No es lo que se ve con un óptico marginal.
Vale la pena nombrar los estándares, porque entonces la división es obvia. El lado SFP es SFF-8472, donde el diagnóstico vive en su propio mapa de memoria al que se llega por la segunda dirección. QSFP y QSFP28 siguen SFF-8636, y las piezas más nuevas CMIS, donde todo cuelga de una sola dirección detrás de una selección de página.
El adaptador no puede conectar eso. Es una pieza pasiva mecánica y eléctrica, los cables de gestión pasan directo por él y nada los traduce en el camino. Así que hay que decirle al host cuál de los dos modelos de memoria aplica antes de que lea un solo byte, y el adaptador no tiene forma de decírselo.
Como contraste, la misma clase de problema en hardware Dell ONIE muerde más fuerte. Un QSA 407-BBRO con un SFP+ 10GBASE-SR 407-BBOU dentro (SFP-10GSR-85), en los puertos de 40G de un S4048-ON y en cualquier puerto de un S6010-ON, ambos corriendo OpenSwitch OPX 3.1 dev2:
opx-ethtool identifica el medio correctamente, marca el transceptor como habilitado y calificado, admin state up, velocidades soportadas 1000, 10000 y 40000 Mbps, y el puerto de todos modos nunca sube, sea cual sea la velocidad, dúplex o autoneg configurado, valores por defecto incluidos. Alguien lo abrió en el repositorio opx-platform-config como una solicitud de mejora, por favor hagan que el QSA funcione aquí, y nadie respondió jamás. Sigue abierto.
No es un bloqueo de vendedor ni un óptico malo. Esa jaula simplemente nunca es puesta en modo adaptador por el sistema operativo de red, y ninguna combinación de configuraciones de interfaz te lo va a dar.
Relacionado, pero por favor no mezclen los dos casos. Lo que tiene el post original es un enlace funcionando con diagnóstico faltante: la ruta de datos está bien, solo la lectura de gestión está mal, y parchear el SfpUtil de la plataforma lo arregla. El caso Dell es un puerto que nunca sube en absoluto, porque el perfil de puerto para esa jaula nunca se aplica de entrada. Eso está una capa más abajo y necesita su propio arreglo.
Alguien que combine síntomas con prisa podría quemar un día reescribiendo código de transceptores mientras su puerto está caído por una razón completamente distinta.
Otro sabor de "el adaptador es una función de software" en vez de mecánica. En un Z9264F-ON bajo OS10 10.5.2.7, usar adaptadores QSA28 para medios SFP+ de 10G significa poner el puerto en el mismo perfil port-group que usa un cable breakout 4x10G:
Los perfiles port-group en esa plataforma actúan sobre pares de puertos QSFP28, así que aplicarlo deshabilita el puerto compañero de cada par. Un QSA28 es una sola interfaz y aun así pagas un precio con forma de breakout: 64 puertos usables se vuelven 32. Ni las guías de usuario de OS10 ni la hoja de especificaciones de ópticos de Dell documentan un modo QSA de un solo puerto.
Si necesitas mucho 10G nativo en ese equipo, planea de entrada la pérdida 2:1 o pon un switch de 10G separado en el rack.
Antes de que alguien pida una bandeja de estas cosas, yo pondría dos verificaciones en la lista. ¿El sistema operativo de red declara soporte QSA para esa plataforma exacta, y si lo hace, qué te cuesta activarlo: puertos, diagnóstico, o un perfil que arrastra a la jaula vecina con él. El encaje nunca es el problema, todos estos adaptadores entran en la jaula sin quejarse.
Los casos de este hilo difieren solo en qué tan lejos llega el software. En SONiC obtienes algo que puedes arreglar tú mismo, declara el puerto como SFP y el diagnóstico vuelve. En las plataformas Dell de arriba estás esperando el código de plataforma de otra persona, y cambiar adaptadores u ópticos no va a mover eso en absoluto.