Edgecore AS5114-48X op dentOS: SFP+ in poort 18 enumereert prima maar onlpdump blijft op RX_LOS staan

RX_LOS zegt op zichzelf alleen dat de ontvanger niet genoeg licht ziet, dus voor je de box de schuld geeft: wat meldt de andere kant? Als de peer-poort DDM blootgeeft, lees dan zijn Tx-power uit en bevestig dat de laser echt aan staat en de poort niet shut is. Ook de moeite waard om te weten of beide kanten hetzelfde optic-type en dezelfde fibermodus gebruiken - een short-reach-module tegenover een long-reach-module, of de verkeerde fiber, ziet er precies zo uit.

En heb je een tweede module met een ander partnummer in poort 18 geprobeerd, of alleen deze ene tussen poorten verplaatst?

De andere kant is een 10G-poort op een andere switch, dezelfde short-reach optics aan beide kanten. Die poort linkt probleemloos met een andere module over precies dezelfde patchkabel, dus de laser aan de peer-kant leeft en het vezeltraject is end-to-end goed. Poort 18 staat admin up, en ik krijg hetzelfde resultaat met de kabel omgedraaid.

Het vervelende deel is wat ik lokaal kan observeren: onlpdump geeft me presence plus de statusbitmask, en dat is het. Ik heb geen Rx-waarde aan de dentOS-kant om tegen de andere kant af te zetten, dus ik zit vast op "iets ontvangt niet" zonder te weten aan welke kant.

Van symptoom naar oorzaak, in de volgorde waarin ik het zou aanpakken. Detectie bewijst het I2C/EEPROM-pad en de MAC-bekabeling, verder niets. De kernelregel over inband/10gbase-r is de hostkant die zichzelf configureert - dat betekent niet dat er ook maar één foton is aangekomen. Met RX_LOS actief blijven er drie verdachten over: een dode of gekruiste fiber, een andere kant die niet zendt, en een ontvanger die op dit platform niet werkt.

Je hebt al hard op de eerste twee ingezet, dus stop met bits verzamelen en haal er een getal bij. Elke switch die digitale diagnostiek print voldoet. Op EXOS is dat show ports <port> transceiver information, wat temperatuur, voedingsspanning, laserbias, Tx- en Rx-power geeft en elke waarde buiten de modulethresholds markeert, en debug hal show optic port <port> voegt vendor, partnummer, serienummer, connector en golflengte uit de EEPROM toe. Ik heb op die manier een dode 10G-poort op een X460-G2-24x-10G4 nagejaagd en vond ruwweg -26,78 dBm bij de ontvanger, waar geen enkele 10G short- of long-reach-ontvanger op gaat locken.

Als de andere kant je een Rx-waarde kan geven terwijl jouw module zendt, weet je in elk geval of die laser werkt. Wat daarna overblijft is het platform dat dit specifieke onderdeel niet aanstuurt.

Zelfde box hier, en op dit platform is modulesupport per onderdeel, niet per standaard. Op onze AS5114-48X komt de Avago AFBR-703SDZ-IN2 rev G2.3 op zonder enige tuning - het platform meldt hem als Intel Corp met serienummer AA1329A5UTA, wat mensen op het eerste gezicht in verwarring brengt.

Twee onderdelen hebben bij ons nooit gewerkt in dezelfde switch op dezelfde fiber: de Intel FTLX8571D3BCV-IT rev A die jij hebt, en een OPNEXT TRS5020EN-S301. Beide werden gedetecteerd, beide zaten er precies zo bij als jouw poort 18. Leen een bekend goed onderdeel voordat je nog een avond aan het vezeltraject besteedt.

De moeite waard om precies te zijn over dat bit: RX_LOS is de eigen loss-of-signal-uitgang van de module zoals gedefinieerd in SFF-8472, en de platformlaag geeft dat gewoon door als status 0x00000004. Het wordt actief onder de LOS-drempel van de ontvanger, dus het vertelt je "niet genoeg licht" en nooit waarom. Dat is ook waarom een volkomen schone EEPROM-uitlezing en een dood optisch pad zonder tegenspraak naast elkaar bestaan.

De andere reden om op een echte Rx-waarde aan te dringen: verzwakking ziet er vanuit de CLI identiek uit aan incompatibiliteit. Een collega had een Zyxel-poort die rond de -25,69 dBm hing, en de oplossing was de patchkabel plus een patchpaneel dat iemand had omgebouwd, niet de module. Kun je DDM niet aflezen aan de dentOS-kant, lees het dan van de andere kant of van een host - een bitmask alleen gaat dit niet oplossen.