Edgecore AS5114-48X con dentOS: el SFP+ en el puerto 18 se enumera bien pero onlpdump se queda en RX_LOS

RX_LOS por sí solo solo dice que el receptor no está viendo suficiente luz, así que antes de culpar al equipo: ¿qué reporta el otro extremo? Si el puerto par expone DDM, lee su potencia de Tx y confirma que el láser realmente está encendido y que el puerto no está en shutdown. También vale la pena saber si ambos lados son del mismo tipo de óptico y modo de fibra, un módulo de corto alcance frente a uno de largo alcance, o la fibra equivocada, se ve exactamente así.

¿Y probaste un segundo módulo de otro número de parte en el puerto 18, o solo moviste este entre puertos?

El otro extremo es un puerto de 10G en otro switch, los mismos ópticos de corto alcance en ambos lados. Ese puerto enlaza sin problema con un módulo distinto sobre el mismo latiguillo, así que el láser del par está vivo y la ruta de fibra está bien de punta a punta. El puerto 18 está admin up, y obtengo el mismo resultado con el cable invertido.

La parte molesta es lo que puedo observar localmente: onlpdump me da presencia más la máscara de estado, y eso es todo. No tengo una cifra de Rx del lado de dentOS para comparar contra el otro extremo, así que me quedo en "algo no está recibiendo" sin saber en qué extremo.

Del síntoma a la causa, en el orden en que yo lo trabajaría. La detección solo prueba la ruta I2C/EEPROM y la conexión del MAC, nada más. La línea del kernel sobre inband/10gbase-r es el lado del host configurándose a sí mismo, no significa que haya llegado un solo fotón. Con RX_LOS activado quedan tres sospechosos: una fibra apagada o cruzada, un extremo remoto que no está transmitiendo, y un receptor que no funciona en esta plataforma.

Ya presionaste fuerte en los dos primeros, así que deja de coleccionar bits y consigue un número. Cualquier switch que imprima diagnósticos digitales sirve. En EXOS es show ports <port> transceiver information, que da temperatura, voltaje de alimentación, corriente de polarización del láser, potencia de Tx y Rx, y marca cualquier valor fuera de los umbrales del módulo, y debug hal show optic port <port> agrega vendedor, número de parte, serie, conector y longitud de onda desde la EEPROM. Así perseguí un puerto de 10G muerto en un X460-G2-24x-10G4 y encontré algo así como -26.78 dBm en el receptor, que ningún receptor de 10G de corto o largo alcance va a poder engancharse.

Si el otro extremo te puede dar una lectura de Rx mientras tu módulo transmite, al menos aprendes si su láser funciona. Lo que queda después de eso es la plataforma no manejando esta pieza en particular.

Mismo equipo aquí, y en esta plataforma el soporte de módulos es por pieza, no por estándar. En nuestro AS5114-48X el Avago AFBR-703SDZ-IN2 rev G2.3 sube sin ningún ajuste, la plataforma lo reporta como Intel Corp con serie AA1329A5UTA, lo cual confunde a la gente a primera vista.

Dos piezas nunca nos funcionaron en el mismo switch con la misma fibra: el Intel FTLX8571D3BCV-IT rev A que tienes tú, y un OPNEXT TRS5020EN-S301. Ambos se detectaban, ambos se quedaban exactamente como tu puerto 18. Pide prestada una pieza de buen estado conocido antes de gastar otra tarde en la planta de fibra.

Vale la pena ser precisos con ese bit: RX_LOS es la propia salida de pérdida de señal del módulo tal como la define SFF-8472, y la capa de plataforma solo la muestra como status 0x00000004. Se activa por debajo del umbral de LOS del receptor, así que te dice "no hay suficiente luz" y nunca por qué. Esa es también la razón por la que una lectura de EEPROM perfectamente limpia y una ruta óptica muerta coexisten sin contradicción.

La otra razón para insistir en una cifra real de Rx: la atenuación se ve idéntica a la incompatibilidad desde el CLI. Un colega tenía un puerto Zyxel rondando -25.69 dBm, y el arreglo fue el latiguillo más un panel de parcheo que alguien había repasado, no el módulo. Si no puedes leer DDM del lado de dentOS, léelo del otro extremo o desde un host, una máscara de bits sola no va a resolver esto.