Edgecore AS5114-48X no dentOS: SFP+ na porta 18 enumera bem, mas onlpdump fica em RX_LOS

RX_LOS sozinho só diz que o receptor não está vendo luz suficiente, então antes de culpar a caixa: o que a ponta remota reporta? Se a porta do peer expõe DDM, leia a potência de Tx dela e confirme que o laser está realmente ligado e que a porta não está com shutdown. Vale saber também se os dois lados são do mesmo tipo de óptica e modo de fibra - um módulo de alcance curto de frente para um de alcance longo, ou a fibra errada, parece exatamente com isso.

E você chegou a testar um segundo módulo de outro part number na porta 18, ou só esse mesmo, movido entre portas?

A ponta remota é uma porta 10G em outro switch, mesma óptica de alcance curto dos dois lados. Aquela porta linka numa boa com um módulo diferente sobre o mesmíssimo cordão, então o laser do peer está vivo e o caminho de fibra está bom de ponta a ponta. A porta 18 está admin up, e tenho o resultado idêntico com o cordão invertido.

A parte chata é o que consigo observar localmente: o onlpdump me dá presença mais a bitmask de status, e é só isso. Não tenho número de Rx do lado do dentOS para comparar com a ponta remota, então fico travado em "alguma coisa não está recebendo" sem saber de qual lado.

Do sintoma à causa, na ordem que eu seguiria. A detecção prova o caminho I2C/EEPROM e a parte MAC, nada além disso. A linha do kernel sobre inband/10gbase-r é o lado host se configurando sozinho - não significa que um único fóton chegou. Com RX_LOS ativo sobram três suspeitos: uma fibra morta ou cruzada, uma ponta remota que não está transmitindo, e um receptor que não funciona nessa plataforma.

Você já forçou bastante nos dois primeiros, então pare de coletar bits e vá atrás de um número. Qualquer switch que imprima diagnóstico digital serve. No EXOS é show ports <port> transceiver information, que dá temperatura, tensão de alimentação, bias do laser, potência de Tx e Rx, e sinaliza todo valor fora dos limiares do módulo, e debug hal show optic port <port> acrescenta vendor, part number, serial, conector e comprimento de onda da EEPROM. Persegui uma porta 10G morta num X460-G2-24x-10G4 desse jeito e encontrei algo em torno de -26,78 dBm no receptor, o que nenhum receptor 10G de alcance curto ou longo vai travar.

Se a ponta remota consegue te dar uma leitura de Rx enquanto seu módulo transmite, você pelo menos descobre se o laser dela funciona. O que sobra depois disso é a plataforma não conseguindo operar essa peça específica.

Mesma caixa aqui, e nessa plataforma o suporte de módulo é por peça, não por padrão. Na nossa AS5114-48X, a Avago AFBR-703SDZ-IN2 rev G2.3 sobe sem nenhum ajuste - a plataforma a reporta como Intel Corp com serial AA1329A5UTA, o que confunde o pessoal à primeira vista.

Duas peças nunca funcionaram para nós no mesmo switch, na mesma fibra: a Intel FTLX8571D3BCV-IT rev A que você tem, e uma OPNEXT TRS5020EN-S301. As duas eram detectadas, as duas ficavam exatamente como sua porta 18. Peça emprestada uma peça sabidamente boa antes de gastar mais uma noite na planta de fibra.

Vale ser preciso nesse bit: RX_LOS é a própria saída de loss-of-signal do módulo, como definida na SFF-8472, e a camada de plataforma só expõe isso como status 0x00000004. Ela ativa abaixo do limiar de LOS do receptor, então te diz "não tem luz suficiente" e nunca o porquê. É também por isso que uma leitura de EEPROM perfeitamente limpa e um caminho óptico morto coexistem sem contradição.

O outro motivo para insistir num número real de Rx: atenuação parece idêntico a incompatibilidade pela CLI. Um colega teve uma porta Zyxel parada em torno de -25,69 dBm, e a correção foi o cordão mais um patch panel que alguém tinha retrabalhado, não o módulo. Se você não consegue ler DDM do lado do dentOS, leia da ponta remota ou de um host - uma bitmask sozinha não vai resolver isso.