ZXA10 OLT di LibreNMS: tidak ada dBm transceiver di halaman port, dan sensor fan serta PSU hilang
Kami poll fleet campuran OLT ZTE ZXA10 dari LibreNMS dan ada dua hal yang salah. Saya curiga keduanya tidak berhubungan, tapi tidak yakin.
- ZTE ZXA10 C300 di V2.1.0, masih beroperasi di POP lama
- ZTE ZXA10 C620 di V2.0.30, plus C650 dan C650E
- satu ZTE ZXA10 C320 yang dulunya normal
- uplink SFP dan SFP+, card GPON di bawahnya
Masalah pertama: halaman port sama sekali tidak punya sensor transceiver. Tidak ada receive atau transmit power dalam dBm, tidak ada module temperature, tidak ada supply voltage, tidak ada laser bias current. Itu angka-angka yang saya mau untuk menangkap konektor kotor sebelum subscriber mulai menelepon.
Masalah kedua: sensor state yang dulunya jalan di C320, fan, power supply, dan card state, diam-diam hilang setelah rediscovery. Tidak ada error di log, tidak ada yang gagal, mereka cuma sudah tidak ada lagi di device-nya.
Waktu saya walk kotak-kotaknya secara manual, data optiknya jelas ada di MIB di suatu tempat, tapi OID yang menjawab di satu platform tidak mengembalikan apa-apa di platform lain:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Yang sudah dicoba:
- rediscovery dan full poll di setiap device
- bandingkan jawaban C650 dengan jawaban C300 di OID yang sama
- cek apakah cage kosong yang membuat discovery menyerah
Di mana sebenarnya pembacaan optik ini tinggal di keluarga ZXA10, dan apa yang membuat sensor state menghilang waktu discovery tanpa mencatat apa pun?
Comments 5
Dua-duanya sudah diketahui, dan seperti dugaan kamu, tidak berhubungan.
Tabel optik mana yang kamu dapat tergantung platformnya, dan keduanya tidak pernah hidup bersama di satu kotak. C300 yang lebih tua, dites di sini di V2.1.0, mengekspos zxAnOpticalModuleMonTable:
C620 di V2.0.30, C650, dan C650E sebaliknya mengekspos zxAnOpticalModuleInfoTable:
Tabel mana pun memberi kamu empat pembacaan yang sama: rx dan tx power dalam dBm, temperature modul, supply voltage, laser bias current. Nilai mentahnya butuh scaling 0.001. Ada dua sentinel yang juga perlu difilter, kalau tidak setiap cage kosong di chassis akan alarm ke kamu: port yang tidak didukung atau cage yang tidak diisi menjawab 2147483647, dan port yang gelap menjawab -80000. Kehadiran card sama sekali bukan bagian dari optical polling, itu sensor state operational-status terpisah yang melewati slot yang tidak diisi.
Fan, PSU, dan card state kamu yang menghilang itu bug yang berbeda. Entry state di platform YAML kehilangan key value:, dan tanpa itu discovery berakhir membaca nama tabel seolah-olah itu kolom, tidak menemukan apa pun yang bisa dipakai, dan menjatuhkan sensornya diam-diam, tidak ada error di mana pun, makanya kamu cuma menyadarinya sebagai ketiadaan. Mengembalikan key itu memulihkan enam sensor di fixture C320 di sini.
Tapi perlu diingatkan sebelum kamu merencanakan sesuatu di sekitar ini: ini masih menumpang di change yang masih open, belum merged, dan review-nya sudah memangkas ethernet error monitoring keluar dari situ karena dianggap out of scope. Perlakukan sebagai patch yang kamu bawa sendiri, bukan fix yang tinggal ditunggu.
Tunjukkan sysDescr yang dilaporkan masing-masing kotak itu. C300, C320, C620, C650, dan C650E bukan satu keluarga kalau soal optical MIB, jadi OID yang menjawab di sebagian dan diam di sisanya itu wajar, bukan fault.
Post ekor dari walk di dua yang paling beda, C300 dan salah satu C650, di OID yang sudah kamu coba. Kalau yang satu menjawab dan yang lain kosong, itu cerita lengkapnya dan fix-nya memang per-platform.
Terus pisahkan dua masalah kamu. Sensor fan dan PSU yang hilang itu soal definisi discovery dan tidak ada hubungannya dengan tabel optik mana yang diimplementasikan OLT-nya.
Mengonfirmasi celah ini dari sisi lain. Saya tanya soal keluarga yang sama ini di 25.8.0-dev: OLT GPON C320, dan yang saya cari waktu itu grafik di port GPON di kedua ujung, di OLT dan di ONU-nya - level rx dan tx power, seberapa panjang tiap link terukur, utilisasi per port - plus apakah template untuk keluarga ini sudah ada di suatu tempat.
Itu ditutup tanpa ada yang post OID, walk, atau metode, jadi yang terdokumentasi cuma bahwa coverage out-of-the-box untuk keluarga C320 itu parsial. Kalau dipikir lagi, seharusnya saya lampirkan walk ke request-nya. Kalau kamu memang sedang membangun ini, level optik ONU itu bagian yang belum ada yang kerjakan dan banyak dari kami yang akan pakai.
Itu cocok dengan yang terjadi di fleet kami. C300 menjawab di .1.3.6.1.4.1.3902.1015.3.1.13.1 dan tidak mengembalikan apa-apa di OID yang lain, C620 dan C650 kebalikannya, dan C650E berperilaku seperti C650.
Nilainya balik sebagai integer yang butuh scaling 0.001, persis seperti dijelaskan. Yang tadinya kelihatan seperti sampah sekarang masuk akal: 2147483647 di cage yang tidak pernah kami isi, dan -80000 di dua port yang ujung seberangnya mati. Dua sentinel itu nyata di sini, jadi siapa pun yang menulis threshold terhadap angka mentahnya akan dapat daftar alert yang sangat berisik.
Sudah dicek juga platform YAML-nya dan key value: memang hilang di sisi kami juga. Akan dibawa secara lokal karena change-nya masih open. Memisahkan dua masalah itu bagian yang saya salah sejak awal.
Satu hal yang perlu diingat waktu membangun ini: data DOM itu subset di mana-mana, bukan cuma di ZTE.
Di SONiC, CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 EEPROM-nya kebaca tanpa masalah, dan TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR plus TRANSCEIVER_STATUS semuanya terisi dengan identity plus temperature, voltage, bias dan power per-lane, tapi grup control dan status-nya sama sekali tidak ada: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode, dan get_power_override tidak mengembalikan apa pun di database view, jadi kalau kamu butuh bit-bit itu, kamu harus minta langsung ke platform API-nya.
Pelajaran yang sama dari sisi firewall. Di PAN-OS, show transceiver-detail all mencetak blok diagnostik, dan field pertama yang perlu dibaca diagnostic-monitor. Kalau isinya No, modulnya tidak mengimplementasikan digital optical monitoring dan semua nilai balik N/A. Tidak ada yang rusak di situ, cuma memang tidak ada yang bisa dibaca. Layak dikodekan perbedaan itu di alerting kamu supaya modul tanpa DOM tidak kelihatan sama seperti port yang mati.