ConnectX-4 MCX456A-ECAT tidak mau link ke Cisco NCS di 100GBASE-LR4, padahal loopback lolos di kedua ujung
Kami menjalankan sepasang rack yang hand-off ke Cisco NCS yang menghadap carrier, dan salah satu uplink server 100G-nya tidak pernah naik sejak build. Hasilnya sama setelah server dipindah ke cabinet lain dengan patch panel berbeda, jadi saya berhenti menganggap ini kejadian sekali doang.
- server Supermicro, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, kedua port kosong
- QSFP28 100GBASE-LR4 generik, single-mode, reach 10 km, satu di tiap ujung
- Cisco NCS di sisi seberang, dark fibre antara dua ruangan
Bagian yang bikin saya mentok: tiap modul lolos loopback di perangkatnya sendiri. Dengan fiber di-loop balik langsung ke QSFP28 yang sama, NIC-nya melaporkan link 100G yang bersih, dan NCS-nya juga begitu di sisinya. Pasang span yang sebenarnya di antaranya, dan tidak ada apa-apa.
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noYang sudah kami coba:
- ganti kedua modul dengan spare dari batch yang sama, tidak ada perubahan
- pindahkan server-nya dan patch ulang lewat panel yang berbeda
- buka case dengan vendor NIC-nya, jawabannya cuma arahan ke validated transceiver list di firmware release notes, yang tidak menjelaskan kenapa loopback-nya berhasil
Apa ada sesuatu soal LR4 di ConnectX-4 yang bikin dia bisa link lokal tapi tidak pernah lewat span beneran, atau saya mengejar ujung yang salah di sini?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Ini kedengarannya seperti jalur yang kotor, bukan masalah kompatibilitas.
Semua yang sudah kamu ganti sejauh ini ada di sisi yang sudah terbukti bagus, makanya tidak ada yang berubah - span itu sendiri satu-satunya hal yang belum tersentuh. Jadi kerjakan jalurnya:
Validated transceiver list yang diarahkan ke kamu itu layak dilihat, tapi modul yang naik bersih di loopback berarti sudah di-drive dengan benar oleh NIC-nya. Compatibility list menjelaskan modul yang ditolak langsung, bukan modul yang link lokal tapi mati lewat span.
Kalau membersihkan tidak menyelesaikan, langkah berikutnya adalah light source dan power meter di dark fibre-nya, atau OTDR kalau bisa pinjam, sebelum beli NIC lain atau sepasang optik lagi.
Loopback cuma membuktikan satu port bisa mendengar dirinya sendiri - laser, receiver, setting rate. Itu tidak bilang apa-apa soal kaca di antara dua ruangan kamu, dan itu satu-satunya bagian yang belum diuji. Jadi sebelum NIC-nya disalahkan lagi, ambil angka dari kedua ujung dengan span beneran terpasang: berapa Rx power di port NCS, dan berapa di NIC-nya? Rx yang duduk di bawah Low Warn threshold saat span-nya terpasang itu penunjuk klasik ke arah ujung jauh atau ke jalurnya, bukan ke port lokal. Di sisi Linux,
ethtool -mseharusnya kasih pembacaan yang sama, dan kalau hasilnyaCannot get module EEPROM information: Input/output error, jangan baca itu sebagai modul mati - di mlx5 itu biasanya soal akses modul di sisi firmware, danmst start,mst cable addlalumlxcablestetap akan kasih kamu nilainya.Membersihkan itu jawabannya. Kami taruh scope di end face-nya, dan kedua modul plus kedua patch cord ternyata terkontaminasi; kabel yang lewat panel antar-ruangan itu yang paling parah dari keduanya. Bersihkan semua di jalurnya, pasang ulang, dan link 100G ke NCS-nya naik di percobaan pertama dan tetap up sejak itu.
Sedikit kesal ke diri sendiri karena menghabiskan waktu selama itu di sudut pandang kompatibilitas, padahal hasil loopback-nya dari awal sudah bilang modulnya baik-baik saja dan jalurnya yang bermasalah. Buat siapa pun yang mendarat di sini nanti: loopback membuktikan port-nya, bukan fiber-nya.