CliDeck
PlatformLog in
Workspace

Junos Optical Diagnostics: Power, Thresholds and Missing Data

Runbooks
#junos-optics#operational-evidence#runbooks#remote-operations#Runbooks
← Back to Blog

Short answer

Use Junos optical diagnostics to collect module telemetry, its corresponding thresholds and any alarm or warning flags. Keep each measurement tied to the physical interface and, where present, its lane. Missing telemetry means the field is unavailable; it does not mean the measured value is zero or the link passed inspection.

The result is an evidence packet for deciding what to investigate next. It cannot certify a cable, a distant transmitter or an entire service path by itself.

Scope and prerequisites

This workflow uses the Junos OS EX and QFX command references for supported optical interfaces. Confirm the exact switch, installed Junos release and transceiver support before collection. These references describe different module-dependent fields; they do not establish that every EX or QFX release reports every value. Copper interfaces and modules without the required diagnostics are outside the expected telemetry scope.

Use an authorized operational CLI session. Know the intended physical interface and its current cabling assignment. The interface below is an example: replace it with the physical interface actually installed on your device. Do not use a logical unit suffix such as .0 for this collection.

Create a CliDeck workspace record containing the device identity, release, interface, collection time and timezone, and optic identification already available in your asset record. Keep an unknown module identifier unknown until it can be confirmed.

Step 1: collect the complete diagnostics

show interfaces diagnostics optics xe-0/0/0

Preserve the complete response, including the interface heading and every lane block. Avoid an initial power-only filter: it can discard thresholds, flags or module conditions needed to interpret a reading.

If the interface is rejected, check the physical name, CLI context and platform reference. If the response lacks measurements, record the response and the missing fields. Do not insert values from vendor examples or silently translate an unavailable field into a passing result.

Step 2: keep units and lanes attached

The references describe transmit and receive optical power, bias current, temperature and voltage, with availability depending on the module. Preserve the printed units and names. Power may be expressed in mW and dBm; current, temperature and voltage are different quantities and belong in separate fields.

Where multiple lanes appear, create a separate ticket row for each lane and measurement. Do not average the lanes into one apparently healthy number. The row should contain the raw value, units, the associated thresholds if reported, and the corresponding flags.

Make comparisons within the same unit and field. Use the module's reported thresholds rather than a generic light-level number copied from another optic. Keep threshold availability explicit when the module supplies a reading without the matching limits.

Step 3: preserve flags and uncertainty

Record every reported On alarm or warning with its interface, lane and measurement. Keep the raw output alongside your interpretation so another engineer can inspect the context. A warning deserves investigation even when a ticket's requested link is currently carrying traffic.

The QFX reference documents module-specific omissions, including voltage thresholds for XFP modules and some alarm fields for SFP/SFP+ modules. Build the collection form with an “unavailable” option; requiring a numeric answer for every cell encourages fabricated completeness.

If flags and readings appear inconsistent, retain the discrepancy, collect another timestamped response and ask the platform owner to review module support and interpretation. Do not reset the optic or alter the interface merely to obtain tidier evidence.

Step 4: choose the next evidence request

An abnormal receive measurement is a reason to investigate the assigned optical path. It is not enough to blame one connector or replace the distant module. Request the far-end interface identity and its own timestamped evidence, and keep any physical inspection or power-meter work as a separate authorized task.

For a handoff, list what was collected, what is unavailable, which conditions require review, and who owns the follow-up. Include a freshness requirement if the cabling or module changes before the ticket is reviewed. A previously collected snapshot should not be reused as evidence for a different optic.

The Junos chassis alarm intake is a related task for broader device conditions. It complements this module-level record without substituting for optical measurements.

Verification note: acceptance criteria

The reviewer should be able to match the requested physical interface to the command response, retain all reported lanes and units, and distinguish measured values from missing fields. Any On flag or uncertain interpretation should have a named follow-up owner. Threshold comparisons should refer to the corresponding reported module fields.

A complete telemetry record is a collection outcome. Closing an optical fault or accepting refurbished hardware requires the additional checks defined by the service or refurbishment owner. These are operator verification criteria, not results from a physical test performed for this article.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides