How to pull uplink module data and ONU levels on a ZXA10 C320 - via CLI or SNMP
I run a ZTE ZXA10 C320 at a site, 10G uplink. I check levels and status by hand from the console, but I'd like to bring it all into monitoring so I don't have to jump into the CLI for every subscriber complaint.
- OLT: ZTE ZXA10 C320
- uplink: SFP+ in xgei_1/21/1
- subscribers on gpon-onu_1/1/1:1 and further down the branches
I've already found something for the uplink module, this command gives the output:
show int optical-module-info xgei_1/21/1From there I'm stuck on three things:
- which command gets the level for a specific ONU, rather than parsing the output for a whole branch
- is there an SNMP object with the same receive power, so I don't have to parse the CLI with a script; I haven't found a ready-made template for the C320 in monitoring
- how much can I even trust the receive level: on one uplink the number looks fine, yet CRC on the interface keeps slowly climbing
Who pulls this data from a C320 on an ongoing basis - what did you settle on, CLI or SNMP, and which OIDs?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 4
Clarify what exactly you need in monitoring. Module inventory (vendor, part number, serial number) and receive power over time are two different stories: the first is fine to collect once a day and store as a fact, the second is worth polling regularly and graphing.
And a second, more important question: have you already looked at CRC on the uplink deliberately, or noticed it in passing? If the counter is genuinely climbing, the receive level isn't the main suspect here, and you should start not with building graphs but with that interface.
For the uplink, the command you already found gives you everything you need:
The output includes the vendor name, part number, and serial number, module type (e.g. 10GBASE-LR), wavelength 1310 nm, Rx and Tx in dBm, bias current, laser speed, and temperature. Plus the alarm thresholds for power, current, voltage, and temperature are right there too - no need to query inventory separately.
For subscribers, check attenuation for a specific ONU:
For monitoring, receive power on the OLT is at .1.3.6.1.4.1.3902.1015.1010.11.2.1.2:
Be sure to divide the raw value by 1000, otherwise you get baffling thousands instead of dBm. Almost everyone trips on this the first time they graph this OID.
And about your third point: before drawing conclusions from the level, check the CRC counters on the uplink. A normal Rx by itself doesn't rule out a dirty connector or a damaged run.
Dividing by 1000 was exactly what I was missing. My graph showed thousands instead of dBm, and this whole time I thought I'd grabbed the wrong object.
On the uplink the picture checked out: module 10GBASE-LR, 1310 nm, normal receive level, yet CRC kept climbing. Went through the patch panel - the connector turned out dirty, after cleaning the counter stopped. So the advice to check CRC before the level was on point.
Levels for a specific ONU pull fine with the command, I'll put monitoring on it.
On monitoring: don't expect a ready-made template. Out-of-the-box coverage of the C320 is partial - GPON ports, ONU optics, and line length won't appear on their own. In LibreNMS (build 25.8.0-dev) proper support for this family still hasn't shown up: nobody has published ready OIDs or a documented method. So there's one path - your own objects and your own template, which you're already heading toward.
Also keep in mind that different hardware calls this by different names. On a Cisco ISR 4451 there's no familiar interface-level command, DOM is reported via
show hw-module subslot 0/0 transceiver 0 status, on a FortiGate it'sget system interface transceiver. If you're building a single poller for a fleet of different vendors, it's easier to pull everything via SNMP everywhere and keep the CLI for investigating a specific complaint.