OLT shows only a fraction of its ONUs

Symptom

An OLT is polling: traffic and PON data show up, but only a fraction of its ONUs appear (for example 21 of 165), or many ONUs show as “UNKNOWN”. Meanwhile the same OLT “works fine” in Observium, Zabbix or similar tools, which makes NetSense look like the problem.

It isn’t, and the difference in behavior is actually the clue.

Cause

The OLT’s firmware has a bug in handling multi-OID SNMP GET requests: when asked for several OIDs in one request, it returns a value only for the last OID and answers “No Such Instance currently exists at this OID” for all the others.

Tools like Observium and Zabbix mostly use SNMP WALK on a modest set of parameters, which this bug does not affect. NetSense uses efficient bulk GET requests (around 20 OIDs per request) to collect 4000+ parameters per device at scale. That’s why the other tools appear healthy while NetSense sees only slivers of the ONU table: “works in Zabbix” is not evidence the SNMP stack is correct.

Confirm it

Two commands against the OLT tell the whole story:

snmpget -v2c -c <community> <olt-ip> ifName.1 ifName.2

On an affected OLT, only the second (last) OID returns a value. Swap the order and again only the new last one returns. Then:

snmpwalk -v2c -c <community> <olt-ip> ifName

returns the full table. WALK works + multi-OID GET fails = this firmware fault, confirmed.

Also check that no OIDs are administratively disabled: show snmp-server oid-disable should return nothing.

Affected devices

We have confirmed this on several EPON OLT families, including Syrotech / GoIP and other OEM builds of the same platform. The bug persists even on the newest openly published firmware for some of them.

Fix

The fix is a corrected firmware build from the OLT vendor. Contact NetSense support with your OLT model and firmware version: for several affected models we can point you to a build with corrected SNMP tables (remotely uploadable via the OLT web UI), and for some platforms we have shipped a NetSense-side workaround, so an update on our end may already cover you.

Things that do not help, so you can skip them: restarting the OLT’s SNMP daemon, and deleting/re-applying the SNMP configuration.