pjhtech Tools
Juniper · Junos OS

Junos OSPF Troubleshooting Commands and Neighbor States

Quick answer #

Use show ospf neighbor detail and show ospf interface detail together. The first describes the neighbor relationship; the second exposes the local OSPF settings on the link. Looking at only one side often hides the mismatch that matters.

Scope: Junos OS OSPFv2, MX routing focus; supported EX/SRX routing configurations can use the base commands. OSPFv3 commands are explicitly separated. Feature support depends on platform and release.

Commands #

Read-only operational commands for OSPFv2:

Commands
Junos OS · Operational CLI

Read-only
show ospf neighbor
Read-only

Replace these example values: ge-0/0/0.0.

show ospf neighbor interface ge-0/0/0.0 detail
Read-only

Replace these example values: ge-0/0/0.0.

show ospf interface ge-0/0/0.0 detail
Read-only
show ospf route
Read-only
show route protocol ospf

For OSPFv3, use its separate command family:

Commands
Junos OS · Operational CLI

Read-only
show ospf3 neighbor detail
Read-only
show ospf3 interface detail

For a named routing instance, use the supported instance selector, for example show ospf neighbor instance CUSTOMER-A. Always identify the address family and instance before comparing devices.

Read neighbor states in context #

Full means the neighbors have completed adjacency formation. Init means bidirectional hello recognition has not been established. ExStart and Exchange concern database synchronization; a persistent state here directs the investigation toward that stage rather than basic peer discovery.

Do not classify every 2-Way relationship as broken. On a broadcast network, two DROTHER routers can remain 2-Way while each forms full adjacencies with the DR and BDR. Check the network type and router roles before deciding that Full is required between this pair.

The interface detail view provides area, network type, MTU, cost and timer information. Collect the equivalent output from both ends. A side-by-side comparison is more reliable than remembering what the default should have been.

Workflow #

Begin with physical and logical interface state. Confirm that the expected logical unit participates in OSPF and is not intentionally passive. Compare area, addressing, hello/dead timers and authentication settings. For a database-exchange stall, investigate MTU consistency and packet delivery; do not use MTU workarounds to hide an unexplained difference.

After adjacency recovery, verify the required route independently. show ospf route and show route protocol ospf answer related but distinct questions about OSPF's route calculation and the main routing table. An established neighbor is not an end-to-end service test.

Pitfalls #

A passive loopback is not supposed to discover a neighbor. OSPFv3 often identifies a neighbor using a link-local address; do not compare it as if it were an OSPFv2 interface address. Capture relevant states and timestamps before enabling detailed protocol tracing, which can add processing and log volume.

Continue with #

Junos Interface Errors and Optical Power Commands checks the link, Junos Route Lookup and VRF Routing Table Commands verifies the selected route, and Junos Logs, NTP and System Health Commands aligns incident logs. Use the subnet and MTU tools when comparing link parameters.

Sources

Documentation reviewed: 8 October 2026