LibreNMS tidak menemukan sensor optik di OLT ZTE ZXA10 C300/C320, dan sama sekali tidak ada interface ONU
Saya yang mengurus access layer di ISP kecil, dan saya mau dua OLT GPON kami muncul di monitoring sama seperti yang lain. Wish list-nya tidak eksotis: seberapa panas chassis-nya jalan, load CPU dan RAM, counter per port, dan bagian yang benar-benar saya pedulikan, sisi optiknya. Maksudnya dBm Rx/Tx untuk port OLT itu sendiri dan angka Rx per ONU pelanggan.
- ZTE ZXA10 C300 dan ZXA10 C320, community SNMP v2c read-only
- LibreNMS 25.8.0-dev, poller self-hosted di site yang sama
- uplink SFP dan SFP+ di kedua OLT
Out of the box saya tidak dapat apa pun yang optik sama sekali:
# discovery completes, device is green, but:
# - no transceiver Rx/Tx power sensors are discovered for either OLT
# - ONU interfaces do not exist in IF-MIB, only the OLT's own ports
snmpwalk -v2c -c <community> <olt> IF-MIB::ifDescrYang sudah saya lakukan:
- pastikan SNMP-nya sendiri sehat, grafik traffic di uplink dan port PON tergambar dengan benar
- rediscover perangkatnya setelah tiap perubahan dan cek tabel sensor standar, semuanya kosong
- cari template siap pakai untuk keluarga C320 dan tidak menemukan apa pun yang mencakup port GPON atau optik ONU
Jadi tree yang mana sebenarnya dipakai box-box ini untuk publish data itu, baik untuk port mereka sendiri maupun per ONU, dan apa ada yang pernah berhasil memasukkannya ke LibreNMS dalam bentuk yang tetap bertahan setelah upgrade?
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 4
Versi singkatnya: tidak ada apa pun yang optik di OLT ini yang hidup di MIB standar, semuanya ada di tree enterprise privat ZTE 3902.
Mulai dari yang gampang, temperature chassis di .1.3.6.1.4.1.3902.1015.2.1.3.2. Ada definisi sensor PHP yang beredar untuk itu dengan threshold 65/55/15/5 derajat. Jangan langsung percaya begitu saja, cek dulu terhadap suhu jalan sebenarnya di chassis kamu sebelum menyambungkan alerting ke situ.
Sisi ONU itu kerjaan yang sebenarnya. IF-MIB cuma mendeskripsikan interface OLT, dan satu port PON bisa membawa sampai 128 ONU, jadi tidak ada tempat untuk menggantungkan interface-nya. Yang akhirnya dilakukan orang-orang adalah membangun index dari shelf, slot, port dan nomor ONU yang dipadatkan jadi satu integer:
dan memakainya terhadap tree ONU:
Tree itu membawa level RX ONU dan counter byte Counter64, jadi traffic per ONU keluar dari walk yang sama.
Dua peringatan. Ini tumpukan patch user, tidak ada yang sampai ke upstream, jadi simpan salinannya di tempat yang bisa kamu apply ulang setelah update. Dan OLT dengan 300 lebih ONU mengalikan jumlah sensor kamu kira-kira sepuluh kali lipat, yang akan terasa oleh poller-nya. Di skala itu, taruh data ONU-nya ke Components, bukan ke interface biasa.
Dua pertanyaan sebelum ada yang menuliskan template buat kamu.
Sudah pernah walk sesuatu di luar MIB standar? Di keluarga ZXA10, data yang menarik itu tidak ada di IF-MIB, jadi tabel sensor kosong itu hasil yang memang diharapkan, bukan bug. Posting apa yang kamu dapat dari
Kalau itu mengembalikan nilai, kamu sudah di jalur yang benar dan sisanya cuma aritmetika index.
Kedua: berapa banyak ONU per port PON, dan berapa total per chassis? Angka itu menentukan apakah kamu mau sensor biasa atau sesuatu yang lebih ringan, dan itu cukup banyak mengubah sarannya.
Itu jawabannya. Walk 3902 secara manual langsung mengembalikan nilai, dan setelah saya sambungkan, sekarang saya punya temperature, CPU, memory, bandwidth, error counter dan RX dBm untuk port OLT maupun ONU-nya.
Peringatan soal skala itu juga bukan teori belaka. C300-nya membawa lebih dari 300 ONU, dan waktu jalan poller untuk perangkat itu jadi terlihat jauh lebih lama begitu setiap ONU berubah jadi sensor, jadi data per-ONU-nya dipindah ke Components dan cuma optik OLT yang tetap jadi sensor biasa. Saya masih menyebut ini partial, bukan solved: ini jalan, tapi ini patch set saya sendiri, dan tidak ada apa pun yang siap pakai untuk C320.
Vendor beda, pelajaran sama dari sisi saya: begitu satu box kasih kamu angka, cek dulu terhadap sisi seberang sebelum kamu bangun alerting di atasnya.
Kami punya dua link 20 km dengan SFP+ non-Juniper antara EX4550 dan sepasang EX3300. Kedua link-nya lewatin traffic normal, tapi di EX4550
show interfaces diagnostics opticsmencetaksementara ujung EX3300 dari fiber yang sama melaporkan 0.1196 mW / -9.22 dBm. Itu cacat scaling Junos di EX4550, PR1007055, sudah diperbaiki di 12.3R8. Sampai kami upgrade, kami memperlakukan pembacaan EX4550 sebagai dekorasi saja dan pakai sisi seberang.
Denger dari orang lain, jadi jangan terlalu dipercaya: di ICX 7450 dan ICX 7550, optical monitoring katanya tetap kosong untuk part number bikinan Ruckus 33211-100 dan 33210-100, sementara yang setara berkode Brocade di chassis yang sama melapor normal, dilacak sebagai FI-264785 dengan fix diperkirakan sekitar build 08.0.95j. Layak
show opticdulu sebelum siapa pun mulai pasang ulang modul.