Junos Interface Down: Separate Admin State from Link State

Short answer

On Junos, an interface's administrative state and link state answer different questions. Start with the physical interface row in show interfaces terse, then inspect that same interface in detail. Admin up with link down means the interface is administratively enabled but has no operational link; it does not identify the failed component.

This is a read-only Ethernet triage workflow for owned or customer-authorized Junos devices. Juniper documents the command family across releases; exact fields vary by model, interface hardware and Junos build. Confirm the installed platform and version before using a field as an acceptance criterion.

Capture the physical interface first

Stay at the operational prompt. Collect the installed version and summary:

show version
show interfaces terse

Identify the physical interface associated with the approved task. In the next example it is ge-0/0/0; substitute the observed name. Do not infer a connector location from an unfamiliar interface name without the platform's port map.

A logical unit such as ge-0/0/0.0 is not a second physical socket. An irb interface or aggregated interface also has a different scope. Preserve the physical row and relevant logical rows separately instead of reporting whichever row happens to contain an IP address.

Interpret the two state columns

Physical row	Bounded interpretation
Admin down	The interface is administratively disabled; establish why before proposing an enable action
Admin up, Link down	Administrative permission is present, but the physical link is not operational
Admin up, Link up	The physical interface reports a link; application or routed service success is still unproved

Treat unexpected combinations or missing fields as a reason to inspect the detailed output and platform documentation. Do not normalize them into a familiar story.

An admin-down port may be deliberately isolated, awaiting a change window or part of a planned recovery procedure. Enabling it is a configuration change, not a harmless way to test a theory. An admin-up/link-down port can reflect several physical or far-end conditions. The summary alone cannot distinguish an unplugged cable from an unavailable peer.

Collect detail without changing the baseline

For the physical interface selected above, use:

show interfaces ge-0/0/0 extensive

Record the administrative and physical link indications, available speed information, active alarms or defects, and any last-flap or counter information. Keep the original output rather than extracting a single favorable line.

Field availability is platform dependent. If a field is absent, write “not present in this output” rather than “no faults.” Last-flap information helps place a link transition in time; it is not a root-cause statement. Counters describe accumulated observations and require a known baseline before a rate or recent error increase can be calculated.

Do not clear statistics during initial triage. A cleared baseline can obscure whether errors predated the reported incident.

Choose the next investigation from the evidence

For admin down, compare the state with the approved configuration intent and ask the responsible operator whether the disable is expected. A subsequent configuration review belongs to its own change procedure.

For admin up/link down, ask remote hands to confirm the correct connector, cable path and far-end equipment state. Record each observation separately. If the appliance uses a transceiver, follow that model's supported transceiver inspection procedure rather than assuming that all Junos devices provide identical optics output.

For up/up with a service complaint, widen the investigation to the appropriate logical interface, VLAN, aggregate or routing context. Physical link presence does not verify addressing, forwarding, policy or the application.

After an independently authorized action, collect the same summary and detailed commands again. Preserve before and after timestamps, what changed and what remained uncertain. Avoid rebooting, reseating components or enabling interfaces simply because the display includes the word “down.”

Verification note: criteria for read-only triage

An acceptable Junos triage record identifies the physical interface, records Admin and Link independently, includes the installed build and preserves the detailed output available on that platform. The conclusion must stay within those observations: physical link present, absent or administratively disabled.

These criteria describe what an operator should verify. They do not report a lab result or an observed EX-series fault. If a planned physical intervention follows, the work order must identify the exact connection and its own authorization.

Use Junos configuration diff review when a separate configuration investigation is needed. Keep the next operator's context explicit using the command handoff guide, and retain the evidence in the CliDeck workspace.

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

• Junos Configuration Diff: Review the Candidate Before You Commit - Review a Junos candidate diff against the active or rollback baseline, interpret changes, and avoid accidentally confirming a pending rollback timer.
• Junos Rescue Configuration: Save, Review, and Restore a Known Baseline - Save a reviewed Junos rescue baseline, inspect its contents, load it into the candidate, review the diff, and activate it through an approved commit.
• FortiGate Backups: Encryption and Password Masking Serve Different Jobs - Keep encrypted FortiGate recovery candidates separate from masked review copies, record scope and custody, and check file integrity without claiming a restore.
• Cisco Catalyst Interface Errors: Measure the Change, Preserve the Baseline - Compare two Catalyst interface-counter snapshots without clearing the baseline; distinguish new receive errors, congestion, and counter discontinuities.
• FortiGate CLI Packet Capture: Use a Filter, a Count, and a Stop Condition - Run a narrowly filtered FortiGate CLI packet capture with a finite count, an operator deadline, private logging, and explicit offload limits.