Optical Transceiver Power: Reading Rx/Tx dBm Correctly

An interface that shows up does not mean the optics are healthy - it means the receiver can still recover enough signal, possibly with almost no margin left. Digital optical monitoring (DOM, defined by SFF-8472) exposes the transceiver's Tx power, Rx power, temperature, voltage and laser bias current, and reading those numbers correctly is one of the most valuable fiber troubleshooting skills. This guide explains dBm, what typical Tx and Rx power ranges look like for 10G SR/LR optics, how to interpret the alarm and warning thresholds in CLI output, and what to check when power levels drift.

dBm: The Language of Light Levels

dBm is optical power relative to 1 milliwatt: 0 dBm equals 1 mW, every +3 dB doubles the power and every -3 dB halves it. A reading of 466 uW is 10 x log(466/1000) = -3.3 dBm. Because the scale is logarithmic, a 3 dB change is already a factor of two - small-looking dBm differences are large real changes.

The table below is worth keeping next to a console session. It converts the milliwatt values that some vendors print into dBm, and it makes clear why a link that "only moved 3 dB" has actually lost half its received power:

Two consequences follow. First, when you compare a live reading against a specification, work in dBm and dB, never in microwatts - adding loss in dB is an addition problem, multiplying loss in microwatts is not. Second, the difference between a healthy link and a marginal link is often only 5-10 dB, which is a factor of three to ten in real optical power, and that difference is entirely normal to lose through a bad patch panel.

Typical Tx and Rx Power Ranges

Absolute numbers depend on the transceiver data sheet, but field experience gives useful rules of thumb for 10GBASE-SR multimode optics:

• Tx power is normally good in the -1 to -7 dBm band for SR optics (check your module's spec; LR modules transmit higher, around -3 to +2 dBm).
• Rx power is normally expected between -1 and roughly -10 dBm for SR.
• Rx around -14 dBm or lower on an SR link usually means a real cable-plant fault: bad splice, dirty connector, or poorly seated jumper.
• Tx or Rx at -30 dBm or below is typically the receiver's noise floor - in practice, no signal at all.

Always compare against the module's own DOM thresholds, which the switch reports next to the live reading. As a rough orientation for the most common Ethernet optics:

The column that matters when you are judging a live link is not the typical range but the sensitivity: the link works only while Rx stays above sensitivity, and it works reliably only while Rx stays a few dB above sensitivity. Treat anything within 3 dB of sensitivity as an incident waiting to happen, even though the port is up.

Reading DOM Output: Values and Thresholds

Cisco-style output shows the measured value plus high/low alarm and warning limits. The reading is healthy when it sits inside the warning band; alarms are the emergency stops:

# Cisco IOS-XE: show interface transceiver details
Temperature  47.05 C     High Alarm 89.00 C    Low Alarm -9.00 C
Tx Power     -4.87 dBm   High Alarm 1.00 dBm   Low Alarm -13.50 dBm
Rx Power     -7.69 dBm   High Alarm 4.00 dBm   Low Alarm -21.02 dBm
Transmit Fault Count = 0

# Brocade: sfpshow 3/1
# Linux host: ethtool -m eth2

On Brocade gear the equivalent is sfpshow, which prints power in both dBm and uW with the same alarm/warning columns. On Linux hosts with a supported SFP+ NIC, ethtool -m ethX reads the same EEPROM pages and prints the same thresholds, which is useful when you suspect the switch is reporting stale data. On Arista EOS, show interfaces transceiver detail gives the same four values plus the threshold table.

The four-level threshold scheme is worth understanding properly, because it explains why a link can be "up but unhappy":

• High/Low Warning: the module is operating outside its comfortable range. The link still passes traffic, but log an event - this is your early alert window.
• High/Low Alarm: the module is outside its specified operating range. Expect errors, flapping or link-down, and expect the platform to log against the port.
• High Alarm on Rx: the receiver is saturating. This happens when a long-reach optic is used on a very short link, and it produces errors just as reliably as too little light.
• Low Alarm on Tx: the laser is no longer emitting within spec - replace the module rather than the fiber.

Interpreting Common Patterns

Never judge a module by a single reading - check the current value, its thresholds, and the trend over several weeks. A classic case: Rx drifting from -10 dBm to -16 dBm while the link stays up; cleaning mid-span LC connectors recovered the margin without replacing a good optic.

Turning Readings Into a Diagnosis

Three questions convert a DOM dump into an answer:

1. Is the light actually there? If Tx on the far end is nominal but Rx on the near end is at the noise floor, the light is being lost between two known-good transmitters, so the fiber path - including patch panels and adapters nobody documents - owns the problem.
2. Is the loss symmetric? Read both directions. Asymmetric loss means a physical strand problem; symmetric loss that grows with distance means the link is simply designed past its budget.
3. Is it drifting? A value that has been stable for a year at -12 dBm is a design characteristic. The same value reached after a slow slide from -8 dBm is a degradation, and the rate of the slide tells you how much time you have before the link fails.

For the maths, use the standard budget calculation: transmitter output minus connector and splice losses minus fiber attenuation must leave more margin than the receiver sensitivity plus any penalties. Half a dB per connector pair and around 0.2 to 0.3 dB/km of single-mode attenuation are reasonable planning figures; a real link that measures 6 dB worse than the calculation has a physical fault somewhere in it.

Worked Examples: From Reading to Root Cause

Case 1 - a link that is up but has no margin. A 10GBASE-LR link between two buildings reports Rx -14.1 dBm at one end and -1.8 dBm at the other, while both transmitters read around -2 dBm. Nobody had touched the link in months, and it was passing traffic without errors. The asymmetry is the clue: only one direction is lossy, which rules out a weak laser and rules out a design problem, because both fibres are the same length and use the same optics. Cleaning the LC connectors at the mid-span patch panel moved the bad direction from -14.1 dBm to -4.6 dBm. The module was never at fault, and the "fix" that had been proposed - replacing the far-end optic - would have changed nothing.

Case 2 - the slow drift that empties a budget. A data centre link started at commissioning with Rx -6.9 dBm, and over eight months the monitoring platform recorded a slow slide to -13.2 dBm. No single reading was alarming until it was nearly at the low warning threshold, but the trend was unambiguous. Investigation found a patch cord that had been re-routed during a cabinet refresh and was now bent sharply behind a rail; the macrobending loss accounted for roughly 4 dB of the drift, and contaminated connectors added the rest. Restoring the routing and cleaning both ends put the link back at -7.4 dBm - within 0.5 dB of the original commissioning value.

Case 3 - too much light. A new 10GBASE-ER module installed on a 15 metre intra-rack jumper showed Rx +2.5 dBm, inside the module's high warning band, with intermittent CRC errors. The link "worked", but every receiver in that role was operating outside its designed range. Fitting a 10 dB inline attenuator produced Rx -7.1 dBm and eliminated the errors permanently. This is the one pattern where the correct fix is to add loss rather than to remove it, and it is easy to miss because the port comes up immediately.

Practical Monitoring Rules

• Poll DOM values every few minutes and store them; the trend is the signal, and alarms arrive too late.
• Alert at 3 dB above the low warning threshold rather than at the alarm itself.
• Record a baseline for every new link at commissioning time, including the module part numbers at both ends.
• Log cleaning and reseating events against the port so a later drift can be correlated with recent physical work.
• Watch bias current and temperature alongside power: a module whose power is fine but whose bias has doubled is much closer to failure than the power column suggests.

Related Reading

See our SFP/SFP+/SFP28/QSFP28 transceiver types guide and ethtool network diagnostics for host-side checks. For the full fault-finding workflow see the SFP transceiver troubleshooting checklist; for link design see how to calculate an optical power budget.

原文链接：https://community.cisco.com/t5/optics-and-optical-networking/understanding-tx-rx-light-level/td-p/2794532