ZXA10 OLTs in LibreNMS: no transceiver dBm on the port pages, and the fan and PSU sensors vanished
We poll a mixed fleet of ZTE ZXA10 OLTs from LibreNMS and two things are wrong. I suspect they are unrelated, but I am not sure.
- ZTE ZXA10 C300 on V2.1.0, still in service in an old POP
- ZTE ZXA10 C620 on V2.0.30, plus a C650 and a C650E
- one ZTE ZXA10 C320 that used to behave
- SFP and SFP+ uplinks, GPON cards below them
First problem: the port pages have no transceiver sensors at all. No receive or transmit power in dBm, no module temperature, no supply voltage, no laser bias current. Those are the numbers I want for catching a dirty connector before subscribers start calling.
Second problem: the state sensors that did work on the C320, fans, power supplies and card state, quietly disappeared after a rediscovery. No error in the log, noothing failed, they are simply not on the device any more.
Walking the boxes by hand, the optical data is clearly in the MIB somewhere, but an OID that answers on one platform returns nothing on another:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Tried so far:
- rediscovery and a full poll on every device
- comparing what a C650 answers against what the C300 answers on the same OID
- checking whether empty cages are the reason discovery gives up
Where do the optical readings actually live on the ZXA10 family, and what makes a stae sensor disappear at discovery without logging anything?
Comments 5
Both are known, and as you guessed they are unrelated.
Which optical table you get depends on the platform, and the two never coexist on one box. The older C300, tested here against V2.1.0, exposes zxAnOpticalModuleMonTable:
C620 on V2.0.30, C650 and C650E expose zxAnOpticalModuleInfoTable instead:
Either table hands you the same four readings: rx and tx power in dBm, temperature of the module, supply voltage, laser bias current. Raw values need the 0.001 scaling. Two sentinels need filtering too, or every empty cage in the chassis will alarm at you: an unsupported port or an unpopulated cage answers 2147483647, and a dark port answers -80000. Card presence does not belong in the optical polling at all, that is a separate operational-status state sensor which skips unpopulated slots.
Your vanished fans, PSUs and card state are a different bug. The state entries in the platform YAML were missing the value: key, and without it discovery ends up reading the table name as if it were a column, finds nothing usable and drops the sensor silently, no error anywhere, which is why you only noticed it as an absence. Putting the key back restored six sensors on the C320 fixture here.
Fair warning before you plan around it: this is riding in a change that is still open rather than merged, and review already trimmed ethernet error monitoring out of it as out of scope. Treat it as a patch you carry, not a fix to wait for.
Show us the sysDescr each of those boxes reports. C300, C320, C620, C650 and C650E are not one family as far as the optical MIB is concerned, so an OID that answers on some of them and stays silent on the rest is expected rather than a fault.
Post the tail of a walk from the two that differ most, the C300 and one of the C650s, on the OID you already tried. If one answers and the other is empty, that is the whole story and the fix is per-platform.
Also keep your two problems apart. The missing fan and PSU sensors are a discovery definition issue and have nothing to do with which optical table the OLT implements.
Confirming the gap from the other side. I asked about this same family on 25.8.0-dev: a C320 GPON OLT, and what I was after was graphing on the GPON ports at both ends, on the OLT and on the ONUs - rx and tx power levels, how long each link measures out at, utilisation per port - plus whether a template for the family already existed somewhere.
It got closed without anyone posting OIDs, a walk or a method, so all it documents is that out-of-the-box coverage for the C320 family is partial. In hindsight I should have attached a walk to the request. If you are building this anyway, ONU optical levels are the part nobody has done and plenty of us would use it.
That matches what the fleet does. The C300 answers on .1.3.6.1.4.1.3902.1015.3.1.13.1 and returns nothing on the other OID, the C620 and C650 are the other way round, and the C650E behaves like the C650.
Values come back as integers needing the 0.001 scaling, exactly as described. The ones that looked like garbage at first mke sense now: 2147483647 on the cages we never populated, and -80000 on two poorts where the far end is powered off. Both sentinels are real here, so anyone writing thresholds against the raw numbers will get a very noisy alert list.
Checked the platform YAML too and the value: key is missing on our side as well. Will carry that locally since the change is still open. Splitting the two problems was the part I had wrong from the start.
One thing to keep in mind while building this: DOM data is a subset everywhere, not just on ZTE.
In SONiC a CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 gets its EEPROM read without trouble, and TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR plus TRANSCEIVER_STATUS all fill in with identity plus temperatrue, voltage, per-lane bias and power, but the control and status group is simply absent: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode and get_power_override return nothing in the database view, so if you need those bits you go and ask the platform API for them yourself.
Same lesson from the firewall side. On PAN-OS, show transceiver-detail all prints the diagnostic block, and the first field to read is diagnostic-monitor. If it says No, the module does not implement digital optical monitoring and every value comes back N/A. Nothing is broken there, there is just nothing to read. Worth encoding that distinction in your alerting so a module without DOM does not look the saame as a dead port.