Edgecore AS5114-48X di dentOS: SFP+ di port 18 enumerate normal tapi onlpdump tetap di RX_LOS

RX_LOS sendirian cuma bilang receiver-nya tidak lihat cahaya yang cukup, jadi sebelum kamu nyalahin box-nya: apa yang dilaporkan sisi seberang? Kalau port peer-nya expose DDM, baca Tx power-nya dan pastikan laser-nya beneran nyala dan port-nya tidak shut. Layak diketahui juga apakah kedua sisi tipe optik dan mode fiber-nya sama - modul short reach ketemu long reach, atau fiber yang salah, kelihatannya persis kayak gini.

Dan kamu udah coba modul kedua dengan part number berbeda di port 18, atau cuma yang ini yang dipindah-pindah antar-port?

Sisi seberang itu port 10G di switch lain, optik short reach yang sama di kedua sisi. Port itu link dengan santai pakai modul yang beda lewat patch cord yang persis sama, jadi laser peer-nya hidup dan jalur fiber-nya baik end to end. Port 18-nya admin up, dan saya dapat hasil yang identik dengan cord-nya dibalik.

Bagian yang nyebelin itu apa yang bisa saya amati secara lokal: onlpdump ngasih saya presence plus status bitmask, dan itu doang. Saya tidak punya angka Rx di sisi dentOS buat dibandingin lawan sisi seberang, jadi saya mentok di "ada yang tidak nerima" tanpa tahu sisi mana.

Dari gejala ke penyebab, urutan yang bakal saya kerjain. Deteksi cuma membuktikan jalur I2C/EEPROM dan plumbing MAC-nya, tidak lebih. Baris kernel soal inband/10gbase-r itu host side lagi konfigurasi dirinya sendiri - itu tidak berarti satu foton pun sudah nyampe. Dengan RX_LOS ke-assert, ada tiga tersangka yang tersisa: fiber yang gelap atau kesilang, sisi seberang yang tidak transmit, dan receiver yang tidak bekerja di platform ini.

Kamu udah dorong keras dua yang pertama, jadi berhenti kumpulin bit dan ambil angka. Switch mana pun yang nge-print digital diagnostics bakal cukup. Di EXOS itu show ports <port> transceiver information, yang ngasih suhu, tegangan supply, bias laser, daya Tx dan Rx, dan nge-flag tiap nilai di luar threshold modulnya, dan debug hal show optic port <port> nambahin vendor, part number, serial, konektor, dan wavelength dari EEPROM-nya. Saya pernah ngejar port 10G yang mati di X460-G2-24x-10G4 dengan cara itu dan nemu kira-kira -26.78 dBm di receiver-nya, yang tidak akan bisa dikunci receiver 10G short maupun long reach mana pun.

Kalau sisi seberang bisa ngasih kamu bacaan Rx waktu modul kamu transmit, paling tidak kamu tahu apakah laser-nya bekerja. Yang tersisa setelah itu adalah platform-nya yang tidak nge-drive part yang ini secara khusus.

Box yang sama di sini, dan di platform ini dukungan modulnya per part, bukan per standar. Di AS5114-48X kami, Avago AFBR-703SDZ-IN2 rev G2.3 naik tanpa tuning apa pun - platform-nya melaporkannya sebagai Intel Corp dengan serial AA1329A5UTA, yang bikin orang bingung di lihatan pertama.

Dua part tidak pernah bekerja buat kami di switch yang sama di fiber yang sama: Intel FTLX8571D3BCV-IT rev A yang kamu punya, dan OPNEXT TRS5020EN-S301. Keduanya terdeteksi, keduanya nongkrong persis kayak port 18 kamu. Pinjam part yang sudah terbukti bagus sebelum kamu ngabisin satu malam lagi di fiber plant-nya.

Layak dipresisikan soal bit itu: RX_LOS itu output loss-of-signal modulnya sendiri sebagaimana didefinisikan di SFF-8472, dan platform layer-nya cuma nampilin itu sebagai status 0x00000004. Dia assert di bawah threshold LOS receiver-nya, jadi dia bilang "cahaya tidak cukup" dan tidak pernah bilang kenapa. Itu juga kenapa pembacaan EEPROM yang bersih sempurna dan jalur optik yang mati bisa hidup berdampingan tanpa kontradiksi.

Alasan lain buat ngotot dapat angka Rx yang beneran: attenuation kelihatan identik dengan inkompatibilitas dari CLI. Kolega saya punya port Zyxel yang nongkrong di sekitar -25.69 dBm, dan fix-nya itu patch cord plus patch panel yang pernah diotak-atik orang, bukan modulnya. Kalau kamu tidak bisa baca DDM di sisi dentOS, baca dari sisi seberang atau dari host - bitmask doang tidak akan nyelesain ini.