CliDeck
PlatformLog in
Workspace

Junos Route Summary: Destinations, Routes and Hidden Counts

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

Short answer

Use show route summary to compare routing-table counts while keeping destinations, routes, active, holddown and hidden values distinct. Scope the capture to the intended table and retain protocol contributions. An active-route count does not prove that a particular packet reaches its destination.

Scope and prerequisites

Juniper's generic Junos command reference documents this operational view and its table option. It requires view privilege. Confirm the actual platform, installed release, logical system and routing instance before interpreting the output.

This article describes normal Junos operational CLI output. It does not cover the separate platform-specific CLI-PFE compression view, restart routing protocols or change routing policy. Have the maintenance purpose and expected table identity available.

1. Capture the table context

At the operational prompt, run:

show route summary

Preserve each table heading and the associated protocol lines. Do not total unrelated tables and present the result as the size of one service's routing domain.

For the main IPv4 table, the documented scoped form is:

show route summary table inet.0

Use that example only when inet.0 is the intended context. Substitute the approved exact table name for a routing instance. The table selector matches names beginning with the supplied string, so a shortened prefix can return more tables than expected. Check every heading in the actual result.

2. Keep destinations and routes separate

Destinations count the destinations represented in the table; routes count route entries. Several entries can relate to one destination. Therefore, different totals are not automatically an inconsistency.

Record the active, holddown and hidden categories as printed. Juniper describes holddown as a state before inactivity and hidden entries as routes not used because of policy. A summary does not identify which individual entry or policy explains an unexpected count.

Avoid a universal healthy ratio. The expected mix depends on the service design and the routing policy. A routing owner should interpret a change relative to the approved baseline, not a number copied from another site's sample.

Protocol lines add context about where entries came from. Keep them with the relevant table. A smaller total could conceal a loss in one contribution and growth in another, so compare the categories that matter to the planned maintenance.

3. Compare captures under known conditions

Record capture time and whether route learning or a planned transition is in progress. Take a later bounded capture after the agreed stabilization period when a comparison is required.

Juniper advises allowing route learning to complete. If the command reports a timeout communicating with the routing daemon during that period, preserve the exception and wait several minutes before retrying. Do not create a tight polling loop or restart the daemon merely to get an immediate result.

Retain any displayed restart state and configured limits. Their presence and meaning depend on the actual configuration and release. An absent limit field is not evidence of unlimited hardware capacity.

4. Investigate the right question

If hidden counts rise unexpectedly, identify the affected table and protocol before proceeding to entry-level diagnosis. A count alone does not tell you to remove a policy or clear a peer.

For a reachability incident, combine this summary with the approved destination-specific route, forwarding and service checks. State explicitly which of those checks remain outstanding. The summary establishes a bounded control-plane view.

Use Routing Engine resource baselines when examining resource context, and Junos configuration review before an authorized policy change.

Verification note: acceptance criteria

For the actual Junos model, release and routing context, verify successful capture, correct table headings, retained protocol contributions and comparable timestamps. Explain expected transitions and keep timeouts or unexplained count changes as exceptions. Verify destination-specific service behavior separately. These criteria are checks to perform; no real routing transcript, convergence test or measured forwarding outcome 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