Edgecore AS5114-48X on dentOS: SFP+ in port 18 enumerates fine but onlpdump stays at RX_LOS

RX_LOS on its own only says the receiver is not seeing enough light, so before you blame the box: what does the far end report? If the peer port exposes DDM, read its Tx power and confirm the laser is actually on and the port is not shut. Worth knowing whether both sides are the same optic type and fibre mode as well - a short reach module facing a long reach one, or the wrong fibre, looks exactly like this.

And did you try a second module of a different part number in port 18, or only this one moved between ports?

Far end is a 10G port on another switch, same short reach optics on both sides. That port links happily with a different module over the very same patch cord, so the peer laser is alive and the fibre path is good end to end. Port 18 is admin up, and I get the identical result with the cord reversed.

The annoying part is what I can observe locally: onlpdump gives me presence plus the status bitmask, and that is it. I have no Rx figure on the dentOS side to compare against the far end, so I am stuck at "something is not receiving" without knowing which end.

Symptom to cause, in the order I would work it. Detection proves the I2C/EEPROM path and the MAC plumbing, nothing else. The kernel line about inband/10gbase-r is the host side configuring itself - it does not mean a single photon arrived. With RX_LOS asserted there are three suspects left: a dark or crossed fibre, a far end that is not transmitting, and a receiver that does not work in this platform.

You have already pushed hard on the first two, so stop collecting bits and get a number. Any switch that prints digital diagnostics will do. On EXOS it is show ports <port> transceiver information, which gives temperature, supply voltage, laser bias, Tx and Rx power and flags every value outside the module thresholds, and debug hal show optic port <port> adds vendor, part number, serial, connector and wavelength from the EEPROM. I chased a dead 10G port on an X460-G2-24x-10G4 that way and found roughly -26.78 dBm at the receiver, which no 10G short or long reach receiver is going to lock onto.

If the far end can give you an Rx reading while your module transmits, you at least learn whether its laser works. What remains after that is the platform not driving this particular part.

Same box here, and on this platform module support is per part, not per standard. On our AS5114-48X the Avago AFBR-703SDZ-IN2 rev G2.3 comes up with no tuning at all - the platform reports it as Intel Corp with serial AA1329A5UTA, which confuses people at first glance.

Two parts never worked for us in the same switch on the same fibre: the Intel FTLX8571D3BCV-IT rev A that you have, and an OPNEXT TRS5020EN-S301. Both were detected, both sat exactly like your port 18. Borrow a known good part before you spend another evening on the fibre plant.

Worth being precise about that bit: RX_LOS is the module's own loss-of-signal output as defined in SFF-8472, and the platform layyer just surfaces it as status 0x00000004. It asserts below the receiver's LOS threshold, so it tells you "not enough light" and never why. That is also why a perfectly clean EEPROM read and a dead optical path coexist without contradiction.

The other reason to insist on a real Rx number: attenuation looks identical to incompatibility from the CLI. A colleague had a Zyxel port sitting around -25.69 dBm, and the fix was the patch cord plus a patch panel someone had rewrked, not the module. If you cannot read DDM on the dentOS side, read it from the far end or from a host - a bitmask alone will not settle this.