CliDeck
PlatformLog in
Workspace

Arista EOS Optical Readings: Capture DOM Values Without Certifying the Link

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

Short answer

Collect transceiver readings with their interface, units and update time, then compare supported DOM values with the correct optic's thresholds. A receive-power number is an optical observation. It does not certify a working link, error-free forwarding or successful delivery to an application.

This is an authorized read-only collection workflow before remote hands or refurbishment decisions. It does not change laser power, speed, breakout configuration or transceiver support policy.

Scope: confirm hardware before interpreting a value

This workflow targets the EOS 4.36.2F command family for transceiver data and DOM thresholds. Available fields depend on the installed switch, port, optic and release; older builds can have different support.

Use the actual interface naming scheme. Ethernet1 below is an example, not a universal connector identifier. Breakout and multi-lane optics need the correct physical-port and channel context. Do not collapse per-channel values into a single invented result.

1. Establish the interface and optic context

From an authorized EXEC session, collect the software identity and supported transceiver views:

show version
show interfaces Ethernet1 transceiver properties
show interfaces Ethernet1 transceiver

Replace Ethernet1 with the approved interface. Preserve the complete headers and units. The properties view provides media and administrative/operational speed-duplex information; the transceiver view can include temperature, voltage, bias current, optical transmit and receive power, and update time.

Relate this record to the EOS intake inventory, which has a different purpose. Inventory identifies reported hardware; optical telemetry describes measurements exposed by that hardware.

Save collection time and exact port identity privately. Missing or N/A telemetry is a coverage limitation, not a zero reading or automatic proof of a failed optic.

2. Collect thresholds only where supported

Where the installed platform and release support it, use authorized privileged EXEC inspection:

show interfaces Ethernet1 transceiver dom thresholds

Retain each parameter's value, channel, unit, warning/alarm limits and indicator. Keep the output's last-update context. If the command is unavailable, preserve that response and consult the exact release and optic documentation.

Do not enable performance-monitoring features merely to fill this checklist. The separate performance-monitoring threshold command can require an enabled feature and is not the same as ordinary DOM threshold inspection.

A generic receive-power target is unsuitable for all optics. Compare values with the applicable module's documented range and the thresholds actually reported. If those references disagree, mark the grading decision unresolved rather than choosing whichever value produces a pass.

3. Read the measurements without overstating them

Keep transmit and receive measurements distinct. Local transmit power and local receive power describe different directions; one cannot replace the other. Also retain their units. A negative dBm reading is not, by itself, a failure label.

Capture each reported lane or channel independently. An aggregate description such as “optic looks good” discards the detail needed to investigate an individual channel.

Record warnings, alarms, absent fields and update age as observations. Do not treat a stale reading as a newly collected measurement, or a missing indicator as proof that no alarm condition exists.

4. Decide the next task from the evidence

For an unexpected value, preserve the baseline before requesting physical intervention. Remote hands should have the specific chassis, port, cable endpoints and approved action. Avoid unplugging an unknown fiber solely because its displayed power differs from a remembered number.

If measurements appear acceptable but the service is failing, continue with the owner's interface/error and end-to-end checks. DOM does not test forwarding behavior. If an alarm is present, do not immediately certify the optic as defective: record the condition and route the optical path investigation to its owner.

Use a second timestamped snapshot to document change where needed. Preserve both snapshots and the circumstances between them.

Verification note: acceptance criteria

The record is complete when it ties readings to the actual device, release, interface, optic context, units, channels, thresholds and collection time. Supported fields must be distinguishable from unavailable fields. Any unexplained alarm or reference mismatch remains open.

Use CliDeck Workspace for the transcript and operator checklist, and the remote-hands workflow only if that guide applies to your team. This collection does not claim physical testing or certify a link.

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