Monitoring DDM in production
Đội ngũ của chúng tôi đang thực hiện bản dịch. Bài viết này tạm thời chưa có bản tiếng Việt và đang được hiển thị bằng tiếng Anh.
Reading DDM once tells you a module's state; trending it tells you its future. Most optical failures announce themselves weeks in advance — as a drifting Rx power, a climbing bias current or a rising pre-FEC BER — to anyone who is recording the numbers.
Bench, CLI or NMS
| Where | Tool | Best for |
|---|---|---|
| Bench | CodingBox DDM screen, CSV export | incoming inspection, baselining, diagnosing a pulled module |
| Switch CLI | show interfaces transceiver and equivalents (per NOS) | spot checks during troubleshooting |
| NMS / telemetry | SNMP, streaming telemetry (gNMI), vendor APIs | fleet-wide trending and alerting |
Collecting over SNMP
Most platforms expose DDM through the standard ENTITY-SENSOR-MIB (entPhySensorValue, with type/scale/precision per sensor) and through vendor MIBs (Cisco entity sensors, Juniper DOM MIB, Arista, Huawei). Open-source NMS such as LibreNMS auto-discover optical sensors and graph them; Zabbix and Prometheus/Grafana work with the same OIDs or with streaming telemetry. Poll every 1–5 minutes — DDM values change slowly, and modules answer the two-wire bus at a leisurely pace.
The link passport
At installation, record for both ends of every link:
- Tx power, Rx power, bias current, temperature (the DDM set);
- module vendor / part / serial;
- fibre length and, where available, an OTDR trace.
This baseline is what later readings are compared with. Without it, "Rx is −12 dBm" is just a number; with it, "Rx has dropped 2.5 dB since March" is a work order.
Alerting: deltas, not just thresholds
Module thresholds are the maker's limits (Thresholds & alarms); your alerts should be tighter and relative:
| Signal | Suggested trigger | Likely meaning |
|---|---|---|
| Rx power | drop of 2–3 dB from baseline | dirty/damaged connector, fibre bend, far-end laser fading |
| Rx power | asymmetric between the two directions | problem on the weak side, not the path |
| Tx bias | rise of 15–20% from baseline | laser ageing — plan replacement |
| Temperature | > 65–70 °C or +10 °C from baseline | cooling or density problem |
| Pre-FEC BER (CMIS/VDM) | climbing towards the FEC limit | first sign on PAM4 links |
| Module alarm flags | any | backstop — should never be the first alert |
Reacting quickly
- BFD on important links detects a degraded path in milliseconds, long before routing protocols or users notice.
- Track per-lane values on multi-lane modules (Per-lane diagnostics) — a single lane failing is the usual AI/DC failure mode.
- When a threshold trips, follow the diagnostic ladder: levels → clean → swap → OTDR.
What DDM cannot tell you
- Tx power on cheap modules may be a constant (DDM levels).
- DDM sees light, not bits: a link can have perfect levels and still error from dispersion, FEC mismatch or a polarity fault — pair DDM with error counters.
- Resolution is 0.1 µW: nothing below −40 dBm is measurable.
In CodingBox
CodingBox is the bench side of this process: a configurable polling interval, a measurement log and CSV export produce the link passport before installation and let a pulled module be compared with its own history in the code database.
Collection details — CLI commands,
ethtool, ENTITY-SENSOR-MIB and vendor OIDs, OpenConfig paths: Reading DDM with tools. What to alert on for PAM4 links: VDM & FEC metrics.
Vendor-by-vendor SNMP objects, OpenConfig telemetry paths and syslog messages that carry the values discussed here: Management & monitoring.
Slow plant faults that trends reveal — contamination, closure ingress, seasonal swings — and the triage order once a trend breaks: Fibre plant faults.
DDM in the context of the whole active infrastructure — amplifier telemetry, OSC, OCM, RFTS, alarm hierarchies and correlating module data with fibre data: Monitoring & management.