pjhtech Tools
Network tools · Vendor-neutral / Junos and IOS XR examples

Optical Receive Power and CRC Errors: A Troubleshooting Checklist

There is no universal good receive-power number for every SFP. Evaluate the reading against the installed module's operating specifications and alarms. A value acceptable for one optic can be too weak or too strong for another. Also distinguish an optical power reading from error-free packet delivery: both observations matter.

Scope: Vendor-neutral workflow with Junos and Cisco IOS XR read-only command examples. Optical thresholds and diagnostic support depend on the installed module.

Record both directions #

For each end, record the module identity, wavelength, transmit power, receive power, temperature and current alarms. On a bidirectional single-fiber link, verify that each transmitter matches the opposite receiver. On multilane optics, retain per-lane values rather than reducing the result to one average.

Junos inspection example:

Record both directions
Vendor-neutral / Junos and IOS XR examples · Junos / Cisco IOS XR operational CLI as labelled

Read-only

Replace these example values: xe-0/0/0.

show interfaces diagnostics optics xe-0/0/0

Cisco IOS XR inspection examples, with a placeholder interface:

Record both directions
Vendor-neutral / Junos and IOS XR examples · Junos / Cisco IOS XR operational CLI as labelled

Read-only

Replace these example values: TenGigE0/0/0/0.

show interfaces TenGigE0/0/0/0
Read-only

Replace these example values: TenGigE0/0/0/0.

show controllers TenGigE0/0/0/0 all

These commands inspect state. Availability and exact output depend on hardware and software. Missing diagnostic fields are not proof that the power is normal.

Compare readings with symptoms #

EvidenceUseful next step
Receive power below the module limitInspect the associated transmitter and fiber path
Receive power above the module limitVerify optic pairing and the engineered attenuation
One direction differs markedly from its baselineCheck that direction's patching and components
CRC counters increase during the incidentCorrelate the receiving interface with the upstream path
Stable old counters and no new errorsPreserve the baseline and reproduce before replacing parts

Use two counter readings over a known interval. Lifetime totals alone cannot tell you whether the fault is active. Input CRC errors describe corrupt frames observed at a receiving interface; they do not uniquely identify the faulty component. On cut-through switching platforms, corrupted frames can be forwarded farther, so the first visible counter is not always the original fault location.

Isolate one change at a time #

Capture the evidence before any counter reset or component swap. During an agreed maintenance window, inspect and clean connectors with appropriate equipment, then change one suspected patch lead or module and repeat the same observation. Replacing both ends and every patch lead simultaneously may restore service while destroying the evidence needed to identify the cause.

Compare measured loss with the planned link budget, but do not assume DOM readings are a calibrated acceptance test. An intermittent fault needs readings and counters from the failing interval. If power is within specification and errors continue, expand the investigation to the modules, ports, signal quality and platform-specific diagnostics.

Sources

Documentation reviewed: 8 October 2026