Short answer: Syrotech (and V-SOL-family) OLTs report over SNMP v2c under enterprise OID 1.3.6.1.4.1.37950, but the EPON line (V1600D) and the GPON line (V1600G) branch into entirely different MIB tables from that same prefix — treating them as one device type is the single most common reason Syrotech monitoring setups quietly get ONU status wrong. The GPON line in particular has a legacy registry table that looks like a status table but isn't: its "valid entry" column reads 1 for every real ONU regardless of whether it's actually online, which is exactly how a monitoring dashboard ends up showing every ONU as "online" with zero optical signal. Getting this right means walking the correct second-generation table for run-state and treating placeholder values (0.00 dBm, zero-meter distance) as null instead of as real readings.
Why Syrotech/V-SOL OLTs need vendor-specific SNMP handling
Syrotech is one of the most widely deployed OLT brands among Indian FTTH ISPs, and like most of the industry it is a V-SOL original-design-manufacturer product underneath — which is why the same enterprise OID family (1.3.6.1.4.1.37950) shows up under other brand names too, including TechNext and Netlink. That shared ancestry is useful (one vendor's SNMP quirks are a good predictor of another's) but it is also the trap: assuming "same OID prefix" means "same MIB layout" is how a generic SNMP monitoring tool misreports ONU status on a Syrotech box, especially on the GPON line. This guide is the first in an OLT vendor series grounded in production SNMP behavior, not vendor documentation alone — every quirk described here was found and fixed against a real Syrotech deployment, not inferred from a datasheet.
Setting up SNMP monitoring on a Syrotech OLT
Before any ONU-level polling can work, three things need to be true on the OLT itself: SNMP v2c needs to be enabled (most Syrotech firmware ships it on by default, but confirm after any firmware upgrade), a read community string needs to be set and match what your monitoring platform is configured with, and the OLT's management IP needs to be reachable from wherever the poller runs — over UDP port 161, not blocked by a firewall rule that only opened TCP for SSH/Telnet management access. Once that baseline is confirmed with a simple SNMP GET against the standard system OIDs (sysDescr, sysObjectID, sysName), the monitoring platform can identify the device as Syrotech from the 1.3.6.1.4.1.37950 prefix and move on to the vendor-specific tables — but identification at the family level is only step one.
EPON (V1600D) vs GPON (V1600G): same vendor, different MIBs
This is the part that catches people. Syrotech sells two distinct PON technology lines under similar model numbers, and SNMP has to tell them apart correctly before it reads a single ONU row:
- V1600D (EPON): authentication and line-status tables live under a `.12.1.*` sub-tree (auth index, PON/ONU position, LLID, line status, MAC, description, LOID, round-trip time), with a second table under `.12.25.*` carrying deregistration reason and ranging distance, and optical power read from a separate `.12.2.1.8.*` table.
- V1600G (GPON): the picture is more subtle because there are genuinely two generations of table on this line. A legacy ONU registry (`.10.3.2.1`) only lists ONUs the OLT currently considers registered and gives you the Ethernet MAC plus a "PONx:ONUy" location string — but its status column is a static validity flag, not a live state. The authoritative run-state and optical DDM (temperature, voltage, bias, TX/RX power) live in a completely separate GPON ONU-management table family (`.1.1.6.1.1.*`), indexed directly by PON-and-ONU-number. A monitoring layer that only reads the legacy registry will faithfully report every currently-registered ONU as present — and since the registry's validity flag is always 1, it looks exactly like "online," even for an ONU that has been dark for hours. This was confirmed on a production V1600G unit: the GPON management table's run-state codes (3 = online, 4 = LOS, 6 = power-off) correlate exactly with real negative-dBm RX power for online ONUs versus a "0.00" placeholder for offline ones — the legacy table alone cannot distinguish the two.
| Property | V1600D (EPON) | V1600G (GPON) |
|---|---|---|
| PON ports | 4 | 8 |
| Uplink ports | 8 | 4 |
| Max ONUs | 256 | 1,024 |
| Primary status source | Auth/line-status table (`.12.1.*`) | GPON ONU-management table (`.1.1.6.1.1.*`) — NOT the legacy registry |
| Deregistration/phase codes | 0 = wire down (LOS), 1 = power off | Phase 3 = online, 4 = LOS, 6 = power off |
| Known monitoring pitfall | Low risk — line-status table reflects real state directly | High risk — legacy registry's "valid entry" flag looks like an online signal but isn't |
What you can see once monitoring is live
Done correctly, SNMP on a Syrotech OLT exposes more than a simple up/down ping ever would. Device vitals — CPU percentage, memory percentage, and board temperature — are available on the V-SOL system MIB branch for the chassis itself (Syrotech's ZTE-based competitors generally cannot report this; the ZTE C6xx card table gives slot/type/state instead, with no CPU or temperature at all over SNMP). Per-ONU, you get real-time optical RX and TX power in dBm, fiber distance in meters from OLT to ONU (useful for flagging a sudden jump that suggests a new splice or a damaged patch cord), and a phase/status code that maps to a human label (online, LOS, power-off) rather than a raw integer. Standard IF-MIB interface counters give uplink and PON-port traffic in bits per second, classified automatically into uplink vs PON vs ONU ports by interface-name pattern matching. Polled on a steady interval (every 15 minutes is a sensible default), this data builds exactly the kind of PRTG-style history and per-port graphs a network team actually wants to look at during an outage — uplink traffic trends over the last 24 hours, ONU signal-strength spread across a PON port, CPU/memory/temperature trend lines — instead of a single current-moment snapshot that tells you nothing about whether tonight's complaint call matches a pattern.
Reading Syrotech ONU status correctly
Three rules keep a Syrotech monitoring setup honest instead of misleading: first, never trust a "valid entry" or presence flag as a proxy for online/offline — on the GPON line specifically, that flag from the legacy registry is always 1 for a currently-registered ONU and tells you nothing about whether it's actually passing traffic right now. Second, treat placeholder optical and distance values as null, not as real measurements — a "0.00" RX power or a zero-meter distance on an offline ONU is the device saying "nothing to report," and graphing it as a literal reading produces a chart full of fake signal crashes that never happened. Third, anchor ONU identity on the serial number (Ethernet MAC for EPON, GPON registration serial for GPON), not on PON/ONU slot position alone — when a technician swaps a faulty ONT in the field, the slot stays the same but the device behind it changes, and identity has to follow the serial or the monitoring history silently merges two different physical devices into one timeline.
Troubleshooting common Syrotech OLT faults
With the tables read correctly, most field complaints map to a specific code instead of a guess. A subscriber reporting "internet is down" that correlates with a wire-down/LOS code almost always means a fiber-path problem — a cut, a disconnected patch cord, or a bad splice — and is a dispatch-worthy fault, not a software issue. The same complaint correlating with a power-off code points the technician toward the customer's premises power supply or ONT adapter instead of the fiber plant, which is a meaningfully different (and usually faster) truck roll. A subscriber who is intermittently "online" on monitoring but complains of a slow connection is better diagnosed from the RX power trend than from the binary status alone — optical power drifting toward the weak end of the usable range (even while technically still "online") is an early warning of a degrading splice or a dirty connector, well before it fails outright and generates a support ticket. And a PON port whose total ONU count looks wrong after a partial SNMP walk (common on boxes with a few hundred ONUs under load) should trigger a recount against the device's own ONU rows rather than silently overwriting a previously-correct count with an incomplete sweep's partial numbers.
Where this fits in a full ISP NMS
Syrotech-specific SNMP handling is one piece of a broader OLT and ONU management layer that also needs to run alongside SNMP monitoring for switches and NAS devices and, for CPE-side visibility, TR-069 ACS zero-touch provisioning — because an OLT-level "ONU online" signal only tells half the story of why a subscriber is complaining. NowaCRM runs Syrotech's EPON and GPON lines as two separate poller adapters precisely because of the table differences described above, alongside TechNext, Netlink, and ZTE adapters under the same dashboard, with per-port history and PRTG-style graphs built on top of the same 15-minute poll cycle. Future posts in this OLT vendor series will cover TechNext and Netlink's own SNMP quirks and a general EPON-vs-GPON monitoring primer for ISPs evaluating their next OLT purchase.
