Optical Transceiver DOM Monitoring: Reading the Optics

Most fibre faults announce themselves twice: first as a warning buried in optical diagnostics, then hours or days later as a link that will not come up. Digital optical monitoring (DOM, also called DDM) exposes the transceiver's internal measurements through the CLI, and reading it is the difference between replacing a module during a maintenance window and replacing it during an outage. This article explains the five measured parameters, how the vendor thresholds work, and how to build monitoring that catches the slow degradation rather than the failure.

The five parameters

Receive power is the field you will read most often, because most real-world incidents are connector or patch-panel problems rather than transmitter deaths. Transmit power and bias current together tell you whether the module itself is ageing: a Tx power that has fallen while bias current has risen is a laser at the end of its life.

Reading the diagnostics

# Junos
show interfaces diagnostics optics ge-0/0/0
show interfaces diagnostics optics | match "Rx power|Tx power|bias"

# Cisco IOS / IOS-XE
show interfaces Te1/0/1 transceiver
show interfaces Te1/0/1 transceiver detail
show interfaces transceiver module 1/0/1

# Arista EOS
show interfaces Ethernet1 transceiver
show interfaces Ethernet1 transceiver detail

The output lists the current measured value alongside four thresholds per parameter: high alarm, low alarm, high warning and low warning. Alarms indicate the module is not operating properly; warnings indicate the module is still inside specification but drifting toward the edge. Critically, in Junos and many other platforms, an alarm does not bring the link down or change LED colour, and does not generate an SNMP trap by default — the link keeps running until it fails. That is precisely why polling is required: the device will not tell you, and the link will not drop until it is too late to be convenient.

Thresholds are vendor-specific, and that matters

Alarm and warning thresholds are set by the transceiver vendor, not by the network operating system, so two different modules in the same switch can have quite different limits for the same parameter. A receive power of -12 dBm might be a warning on one optics type and comfortably nominal on another. Two consequences follow:

• Do not build alerts on absolute dBm values alone. Compare each reading against the module's own reported thresholds, or against a baseline learned from that specific part number.
• When you standardise on a single optics vendor and model per link type, monitoring becomes dramatically simpler and comparisons across the fleet become meaningful.

What actually causes bad readings

1. Contamination. A fingerprint on an LC ferrule can cost several dB. Clean and inspect with a proper scope before replacing anything.
2. Macrobends and pinched patch leads. A patch cable routed around a tight corner or crushed behind a rack door attenuates specific wavelengths differently.
3. Mismatched optics on the two ends of a link, where the link budget is acceptable but the receive sensitivity is not.
4. Aging lasers, which show up first as rising bias current and then as falling output power.
5. Thermal problems, where high module temperature inside a hot rack pushes other parameters out of range.

Note that the two ends disagree in interesting ways: a low Rx at one end with normal Tx at the other points at the fibre, while low Tx and low Rx at the same end points at the module. Log both ends of every link so you can tell the difference.

Building the monitoring

Collect the diagnostics on a schedule and store the time series. Absolute thresholds catch hard failures, but trend analysis catches degradation: a receive power that has fallen by 1 dB over a month is a warning sign long before it crosses a vendor limit. Alert on rate of change as well as absolute value, and correlate with change tickets — a step change usually follows a patching job.

Export through SNMP with a proper engine and security level as described in SNMPv3 configuration for Cisco and Junos, or through streaming telemetry where the platform supports it. Two adjacent areas also benefit from the same discipline: coherent and encrypted optics carry their own richer diagnostics, relevant when you deploy MACsec link encryption, and any environment carrying precise timing should watch optical stability because timing accuracy depends on it — see PTP IEEE 1588 boundary clock configuration.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-interfaces-diagnostics-optics-10-gigabit-ethernet.html