LibreNMS finds no optical sensors on ZTE ZXA10 C300/C320 OLTs and no ONU interfaces at all
I look after the access layer at a small ISP and I want our two GPON OLTs to show up in monitoring the same way everything else does. The wish list is not exotic: how hot the chassis runs, CPU and RAM load, counters per port, and the part I actually caare about, the optical side. That means Rx/Tx dBm for the OLT ports themselves and an Rx figure per subscriber ONU.
- ZTE ZXA10 C300 and ZXA10 C320, SNMP v2c read-only community
- LibreNMS 25.8.0-dev, self-hosted poller on the same site
- SFP and SFP+ uplinks on both OLTs
Out of the box I get nothing optical at all:
# 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::ifDescrWhat I have already done:
- verified SNMP itself is healthy, traffic graphs on the uplinks and the PON ports are drawn correctly
- rediscovered the devices after every change and checked the standard sensor tables, all empty
- looked for a ready template for the C320 family and found nothing covering GPON port or ONU optics
So which tree do these boxes actually publish that in, both for thier own ports and per ONU, and has anyone got it into LibreNMS in a shape that survives an upgrade?
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
Short version: nothing optical on these OLTs lives in a standard MIB, it is all in the ZTE private enterprise tree 3902.
Start with the easy one, chassis temperature at .1.3.6.1.4.1.3902.1015.2.1.3.2. There is a PHP sensor definition floating around for it with 65/55/15/5 degree thresholds. Do not take those on trust, check them against what your chassis actually runs at before you wire alerting to them.
The ONU side is the real work. IF-MIB only describes the OLT interfaces, and a single PON port can carry up to 128 ONUs, so there is nothing to hang an interface off. What people ended up doing is building the index from shelf, slot, port and ONU number packed into one integer:
and using it against the ONU tree:
That tree carries the ONU RX levels and Counter64 byte counters, so traffic per ONU comes out of the same walk.
Two warnings. This is a pile of user patches, nothing that reached upstream, so keep your copies somewhere you can re-apply them after an update. And an OLT with 300 plus ONUs multiplies your sensor count by roughly ten, which the poller will notice. At that scale put the ONU data into Components rather than into ordinary interfaces.
Two questions before anyone writes you a template.
Did you walk anything outside the standard MIBs? On the ZXA10 family the interesting data is not in IF-MIB, so an empty sensor table is the expected outcome rather than a bug. Post what you get back from
If that returns a value, you are in business and the rest is index arithmetic.
Second: how many ONUs per PON port, and how many per chassis in total? That number decides whether you want ordinary sensors or something lighter, and it changes the advice quite a lot.
That was it. Walking 3902 by hand returned values immediately, and after wiring it up I now have temperature, CPU, memory, bandwidth, error counters and RX dBm for both the OLT ports and the ONUs.
The warning about scale was not theoretical either. The C300 carries well over 300 ONUs, and the poller run for that device got viisibly longer once every ONU turned into sensors, so the per-ONU data is moving to Components and only the OLT optics stay as normal sensors. I would still call this partial rather than solved: it works, but it is my own patch set, and nothing for the C320 comes ready made.
Different vendor, same lesson from my side: once a box does hand you numbers, check them against the far end before you build alerting on top of them.
We had two 20 km links with non-Juniper SFP+ between an EX4550 and a pair of EX3300. Both links passed traffic, but on the EX4550
show interfaces diagnostics opticsprintedwhile the EX3300 end of the same fibre reported 0.1196 mW / -9.22 dBm. That is a Junos scaling defect on the EX4550, PR1007055, corrected in 12.3R8. Until we upgraded we treated the EX4550 reading as decoration and used the far end.
Second hand, so take it lightly: on ICX 7450 and ICX 7550 optical monitoring reportedly stays blank for the Ruckus-supplied part numbers 33211-100 and 33210-100 while Brocade-coded equivalents in the same chassis report normally, tracked as FI-264785 with a fix expected around an 08.0.95j build. Worth a
show opticbefore anyone starts re-seating modules.