Edgecore AS9716-32D: sfputil membaca modul QSFP-DD 400G sebagai QSFP28 di bawah PDDF
Kami sedang menyalakan sepasang AS9716-32D sebagai 400G spine di lab, pakai image SONiC komunitas dengan layer platform PDDF. Optiknya bukan masalah, peer-nya link normal, tapi semua yang dilaporkan switch soal itu salah.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- build SONiC komunitas dengan PDDF untuk platform ini
- modul QSFP-DD 400G (part NeoPhotonics) di cage pertama
Pembacaannya sendiri berhasil, modulnya terdaftar, dan cage-nya dilaporkan sebagai QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsBaris identifier itu yang bikin semuanya berantakan. Ini part QSFP-DD, jadi byte-byte di bawahnya dibaca pakai field set SFF-8636, bukan CMIS, dan field-field sesudahnya kebaca seperti noise.
Yang sudah dicek:
- modulnya sendiri sehat, part yang sama kebaca benar di platform lain dan ujung satunya melihat cahaya;
- lepas-pasang ulang dan pindah ke cage lain tidak mengubah apa-apa, semua port 400G berperilaku sama;
- di device description PDDF, cage-cage ini dideklarasikan sebagai QSFP28 dan di-bind ke optoe1.
Apakah poin terakhir itu jawaban lengkapnya, apakah cage QSFP-DD memang butuh device optoe yang berbeda, dan apakah mengedit platform description adalah cara yang lazim untuk memperbaikinya, atau ada sesuatu di atasnya yang juga perlu tahu tipe cage-nya?
Comments 4
Gejalamu cocok persis dengan binding-nya, jadi tidak perlu cari-cari lagi di sisi optik.
Device description PDDF untuk AS9716-32D mendeklarasikan cage 400G sebagai QSFP28 dan mem-bind-nya ke optoe1. optoe1 menyajikan layout EEPROM SFF-8636 yang dipakai QSFP+ dan QSFP28, jadi modul CMIS dibaca lewat map yang salah dan semua yang setelah identifier kebaca seperti noise. Tipe port yang kamu lihat itu sama sekali bukan hasil deteksi, itu cuma apa yang dikatakan description-nya.
QSFP-DD mengikuti CMIS, dan CMIS dilayani oleh optoe3. Perbaikannya adalah balik dua field di device description PDDF untuk cage-cage itu: tipe dari QSFP28 ke QSFP-DD, dan driver dari optoe1 ke optoe3. Saya verifikasi ini di box yang sama dengan part NeoPhotonics 400G, dan setelah perubahan itu
sfputil show eeprommengembalikan modul yang terbaca dengan benar.Dua catatan. Ini data platform, jadi upgrade image akan dengan senang hati mengembalikan description lama kecuali perubahannya ikut masuk ke image yang kamu build. Dan di upstream, perubahan persis ini sudah disetujui tapi pull request-nya ditutup tanpa di-merge, karena kerjaannya dilebur ke perubahan berikutnya, jadi jangan asumsikan image kamu sudah membawanya. Baca dulu device description untuk platform kamu, dalam semenit kamu akan tahu apakah ini memang yang sedang kamu kejar.
Sebelum menyentuh file platform apa pun, post dulu raw dump-nya:
sudo sfputil show eeprom -ddi port itu. Kalau semua byte-nya ada dan cuma interpretasinya yang salah, ini masalah binding, bukan masalah modul, dan bedanya itu layak dipastikan dulu sepuluh menit sebelum ada yang mulai bicara soal RMA.Separuh lainnya sudah kamu jawab sendiri. optoe1 itu varian SFF-8636 yang dipakai QSFP+ dan QSFP28, jadi modul CMIS yang dibaca lewat situ keluar berantakan mulai dari identifier, dan itu persis output yang kamu tempel. Begitu description menyebut optoe1 untuk cage QSFP-DD, tidak ada lagi yang perlu dicurigai di sisi modul.
Jadi tempel juga baris-baris relevan dari device description PDDF untuk salah satu cage itu. Itu akan menunjukkan apakah cuma field driver yang salah atau tipe cage yang dideklarasikan juga.
Itu memang penyebabnya. Tipe cage ke QSFP-DD, driver ke optoe3, reload, dan sekarang modulnya terbaca dengan benar,
sfputil show eepromsudah tidak lagi menyebut cage-nya QSFP28. Saya masukkan perubahan ini ke image yang kami build, bukan nge-patch switch yang sedang jalan, justru karena soal upgrade yang disebutkan di atas.Satu catatan jujur buat siapa pun yang menemukan ini belakangan: ini cuma memperbaiki cara EEPROM dibaca, tidak lebih. Sisa pipa transceiver di platform ini masih punya keanehannya sendiri, dan saya tidak akan bilang box-nya sudah beres total.
Karena kamu menyebut keanehan yang tersisa, ini satu lagi yang menunggu di platform yang sama. Di AS9716-32D kami (x86_64-accton_as9716_32d-r0) yang jalan di SONiC master build,
sudo sfputil show presencemendaftar port yang terisi sebagai Present dan membaca EEPROM-nya dengan baik, sementarashow interfaces transceiver presencemelaporkan semua port sebagai Not present. Syslog terus mengulang:dan membaca EEPROM lewat CLI gagal dengan RuntimeError('PddfEeprom is not Programmed'). Muncul acak setelah reboot dan tidak pernah ada root cause yang diposting, jadi sfputil tetap satu-satunya pengecekan presence yang saya percaya di situ.
Tidak terkait tapi masih di area yang sama: kedua command ini juga diketahui beda nama key di branch 202012, yang sudah dibersihkan di 202205. Kalau output kamu beda di penyebutan saja, bukan di isinya, kemungkinan besar cuma itu penyebabnya.