Junos Routing Engine Baselines: Keep Slots and Windows Separate

Short answer

Capture show chassis routing-engine before Junos maintenance and retain the slot identity and sampling window for each reported resource value. Compare like-for-like observations. A quiet Routing Engine does not certify packet forwarding, and a backup role alone does not establish that a switchover will succeed.

Scope and prerequisites

Juniper's command reference documents the generic command and platform-specific variants. It requires view privilege. Confirm the chassis family, Routing Engine model, installed Junos release and relevant member scope before adding selectors.

This is a resource baseline, not a failover or reboot procedure. Have the expected Routing Engine inventory and maintenance purpose available. If the operator cannot identify the inspected context, resolve that uncertainty before drawing conclusions from percentages.

1. Capture the full Routing Engine view

At the operational prompt, run:

show chassis routing-engine

Preserve each slot heading and its associated fields. Do not combine two Routing Engines into a single average. The currently active and backup contexts can have different workloads, so a difference is a question to investigate rather than proof of failure.

Record which expected engines appear. If the platform returns one engine, do not label that result as an inspection of a second engine that was not shown. Use exact platform help and the approved runbook to establish whether another context is needed.

Keep private hardware identifiers in the restricted capture location. A handoff can reference a private asset record without publishing its serial number.

2. Separate resource types and intervals

Read CPU, memory and temperature as separate observations. When the release reports several CPU windows, keep each window's label with its values. A short burst and a longer average can tell different stories about the same maintenance interval.

Preserve processor categories as printed instead of reducing every output to one unexplained busy percentage. Do not equate a load-average number with a CPU percentage. If a field is absent on the installed platform, record it as unavailable rather than filling it with an assumed zero.

Memory accounting can change between software families and releases. Juniper documents an inactive-memory accounting change for upgraded-FreeBSD platforms starting in Junos 15.1R1. Label a comparison across such a change instead of presenting the percentage difference as a hardware improvement.

Use the documented hardware limits and the organization's baseline when reviewing temperature. There is no universal temperature threshold in this runbook that certifies every Routing Engine model.

3. Make the comparison reproducible

Take another bounded capture at an agreed interval and record the workload or maintenance activity between captures. Compare the same engine, context, software and window. If the engine role changed, identify that change before comparing the numbers.

Include uptime or start information when printed so that a restart does not become an invisible break in the baseline. Retain an unknown reboot reason as unknown. It should not be rewritten into a convenient cause for an incident.

If one engine is unexpectedly missing or the resource view is incomplete, preserve the partial capture and escalate to the platform owner. Avoid performing a switchover as a diagnostic shortcut.

4. Define what remains unverified

Attach the resource baseline to a specific capture period and maintenance purpose. It does not establish forwarding capacity, routing convergence or configuration synchronization. Those outcomes need their own approved checks.

Use Junos alarm baselines for a separate alarm view, and Junos timing context when reconciling boot and protocol times. Keep each result's scope explicit in the handoff.

Verification note: acceptance criteria

For the actual chassis, Routing Engine models and Junos release, verify that the command completes, expected engines are accounted for, fields remain attached to slots and intervals, and comparison conditions are documented. Missing engines, unexplained role changes or incompatible memory accounting remain exceptions. These criteria describe an operator review; no physical test, measured capacity result or real device log is claimed.

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

• Arista EOS Logging Checks: Preserve Configuration and Coverage - Capture EOS logging settings, severity and retention limits before maintenance; distinguish available local evidence from confirmed collector receipt.
• Catalyst 9300 Stack Members: Roles and Readiness Checks - Capture Catalyst 9300 StackWise members, roles and readiness, then reconcile neighbors and port evidence with the approved physical inventory.
• Linux Transcript Permissions: File and Directory Checks - Inspect Linux transcript files, parent directories and ACLs before sharing, with clear limits for umask and copies elsewhere.
• Arista EOS NTP Checks: Status and Associations - Read EOS NTP status and associations together, preserve release differences and avoid unsupported claims about clock accuracy.
• FortiGate Resource Baselines: Read the Sampling Window - Capture FortiGate CPU and memory baselines with sampling windows, repeated observations and clear limits on capacity conclusions.