Adapter QSA di cage QSFP28 SONiC: optik 10G link tapi tidak lapor DDM
Kami lagi reuse setumpuk optik 10G di whitebox switch yang jalan SONiC, jadi beberapa cage QSFP28 dipasangin adapter gaya QSA (10GTek QSA-100A) yang bawa modul SFP+ 10G biasa. Secara mekanis dan elektris ini oke-oke saja. Sisi management-nya yang berantakan.
- switch: whitebox 1U, SONiC yang di-build buat platform itu
- adapter: 10GTek QSA-100A, cage QSFP28 ke SFP+
- optik: modul SFP+ 10G yang dicabut dari access switch yang sudah decommission
- optik yang sama kebaca normal di cage SFP+ native di box lain
Yang saya lihat di port yang di-adapt:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portSudah dicoba:
- ganti ke adapter kedua dan optik kedua, perilakunya identik;
- pindahin pasangannya ke cage QSFP28 yang lain, hasilnya sama;
- verifikasi optiknya lapor diagnostic lengkap di port SFP+ native di tempat lain.
Apa data diagnostic yang hilang ini memang sesuatu yang tidak bisa dibawa adapter pasif, atau ini di sisi software switch-nya? Dan kalau memang software, fix-nya harus ada di mana: platform layer atau kode transceiver generic-nya?
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 7
Sebelum ada yang gali kode platform, satu pertanyaan yang bisa membelah ini jadi dua. Pasang modul QSFP28 native ke cage yang sama itu: dapet diagnostic dari situ, atau DDM-nya emang mati di port itu apa pun yang dipasang?
Kalau part native-nya kebaca normal, cage dan jalur I2C-nya sehat dan semuanya balik ke soal gimana port driver interpretasiin apa yang datang lewat adapter. Kalau part native-nya juga balik kosong, berhenti baca sisa thread ini, kamu punya fault yang berbeda dan itu tidak ada hubungannya sama adapter.
Perbedaan yang cukup dikenal dan lumayan membosankan di management interface-nya, dan adapternya bukan pihak yang bersalah di sini.
Di sisi SFP ada dua alamat I2C yang main: data identification tinggal di 0x50, map diagnostic di 0x51. Part QSFP naruh semuanya di bawah 0x50 dan raih sisanya dengan pindah page. Jadi driver yang udah dikasih tau cage-nya itu QSFP bakal nyari page di satu alamat doang dan tidak pernah nanya apa-apa ke 0x51. Identification balik cukup masuk akal buat port-nya naik, diagnostic-nya cuma tidak pernah resolve, yang persis bentuk apa yang kamu posting.
Fix-nya harus ada di platform layer, bukan di optiknya dan bukan di adapternya. Tiap platform ship implementasi SfpUtil sendiri-sendiri; di punya kamu, port itu harus dideklarasikan sebagai cage SFP, bukan QSFP. Sampai ada yang ngerjain itu, DDM/DOM di port yang di-adapt bakal tetap kosong. Setelahnya, modulnya dibaca dengan cara yang sama kayak di cage SFP+ native.
Link yang hidup tanpa apa-apa di belakangnya di diagnostic itu yang namanya software salah di port-port ini. Itu bukan tampilan optik yang marginal.
Layak disebut nama standarnya, soalnya jadi jelas pembagiannya. Sisi SFP itu SFF-8472, di situ diagnostic tinggal di memory map sendiri yang diraih di alamat kedua. QSFP dan QSFP28 ikutin SFF-8636, dan part yang lebih baru CMIS, di situ semuanya nggantung di satu alamat di belakang page select.
Adapternya tidak bisa jembatanin itu. Itu part mekanis dan elektris pasif, kabel management-nya jalan lurus lewat situ dan tidak ada yang nerjemahin di tengah jalan. Jadi host-nya harus dikasih tau memory model yang mana dari dua itu yang berlaku sebelum dia baca satu byte pun, dan adapternya tidak punya cara buat ngasih tau itu.
Sebagai perbandingan, kelas masalah yang sama di hardware Dell ONIE gigitannya lebih parah. QSA 407-BBRO dengan SFP+ 10GBASE-SR 407-BBOU di dalamnya (SFP-10GSR-85), di port 40G S4048-ON dan di port mana pun S6010-ON, dua-duanya jalan OpenSwitch OPX 3.1 dev2:
opx-ethtool identifikasi media-nya dengan benar, tandain transceiver-nya enabled dan qualified, admin state up, supported speed 1000, 10000, dan 40000 Mbps, dan port-nya tetap saja tidak pernah naik, apa pun speed, duplex, atau autoneg yang di-configure, termasuk default-nya. Ada yang buka issue soal ini di repository OPX platform-config sebagai enhancement request, intinya minta QSA-nya dibikin jalan di situ, dan tidak ada yang pernah jawab. Masih tetap kebuka sampai sekarang.
Bukan vendor lock dan bukan optik jelek. Cage itu cuma tidak pernah dimasukin ke adapter mode sama network OS-nya, dan kombinasi interface setting apa pun tidak bakal ngerjain itu buat kamu.
Terkait, tapi tolong jangan digabung dua kasus ini jadi satu. Yang ada di post original itu link yang jalan dengan diagnostic yang hilang: data path-nya baik-baik saja, cuma pembacaan management-nya yang salah, dan nge-patch SfpUtil di platform itu bereskan itu. Kasus Dell itu port yang tidak pernah naik sama sekali, soalnya port profile buat cage itu memang dari awal tidak pernah diterapkan. Itu duduk satu layer di bawah dan butuh fix-nya sendiri.
Orang yang buru-buru cocokin gejala bisa buang satu hari nulis ulang kode transceiver padahal port-nya down karena alasan yang sama sekali tidak berhubungan.
Rasa lain dari "adapter itu fitur software" ketimbang mekanis. Di Z9264F-ON di bawah OS10 10.5.2.7, pakai adapter QSA28 buat media SFP+ 10G artinya naruh port-nya ke port-group profile yang sama yang dipakai kabel breakout 4x10G:
Port-group profile di platform itu berlaku ke pasangan port QSFP28, jadi nerapin itu bikin partner port di tiap pasangan jadi disabled. QSA28 itu satu interface tunggal dan kamu tetap bayar harga sebentuk breakout: 64 port yang bisa dipakai jadi 32. Baik user guide OS10 maupun spec sheet optik Dell tidak dokumentasiin single-port QSA mode.
Kalau kamu butuh banyak 10G native di box itu, rencanain dari awal buat loss 2:1 atau taruh switch 10G terpisah di rack.
Sebelum ada yang order satu tray barang-barang ini, saya bakal taruh dua pengecekan di daftar. Apa network OS-nya deklarasiin dukungan QSA buat platform yang persis itu, dan kalau iya, apa ongkos buat nyalain itu: port, diagnostic, atau profile yang narik cage tetangganya ikut down. Fit-nya tidak pernah jadi masalah, tiap adapter ini masuk ke cage-nya tanpa komplain.
Kasus-kasus di thread ini bedanya cuma seberapa jauh software-nya jalan. Di SONiC kamu dapat sesuatu yang bisa kamu benerin sendiri, deklarasikan port-nya sebagai SFP dan diagnostic-nya balik. Di platform Dell di atas, kamu nunggu kode platform punya orang lain, dan tukar adapter atau optik tidak bakal gerakin itu sama sekali.