To check the status of OSPF neighbors on a Juniper device, use the show ospf neighbor command in the CLI. A "Full" state for each neighbor indicates a healthy, fully operational OSPF adjacency.
Basic commands for checking OSPF neighbors
In the Juniper CLI, these commands provide different levels of detail for monitoring OSPF neighbor status:
| Command | Purpose | Example Output (Abbreviated) |
|---|---|---|
show ospf neighbor |
Shows the state of all OSPF adjacencies. It is the most common command for a quick status check. | Address Interface State ID Pri Dead``192.0.2.1 ge-0/0/0.0 Full 198.51.100.1 128 35 |
show ospf neighbor detail |
Provides a more detailed view, including the neighbor's uptime, the adjacency's uptime, and the DR/BDR roles. | Neighbor 198.51.100.1 (ID) is on interface ge-0/0/0.0`` Area 0.0.0.0, interface address 192.0.2.1`` State: Full, since 2025-08-29 05:00:00 EDT`` ... |
show ospf neighbor <address> |
Filters the output to show information for a single neighbor, identified by its interface IP address. | show ospf neighbor 192.0.2.1 |
show ospf interface <interface-name> |
Displays OSPF details specific to a particular interface. The output includes information about the DR/BDR election and how many neighbors are on that link. | Interface State DR ID BDR ID Nbrs``ge-0/0/0.0 DR 198.51.100.2 198.51.100.1 1 |
show ospf summary |
Offers a concise summary of the OSPF process, including the total number of neighbors and interfaces. | Instance: master``Router ID: 198.51.100.2``...``Areas: 1, interfaces: 1, neighbors: 1 |
Analysis of the show ospf neighbor output
The output of show ospf neighbor is a vital tool for diagnosing OSPF issues. The most important columns for analysis are State and Dead.
OSPF neighbor states
The state of a neighbor indicates how far along it is in the process of forming a full adjacency.
- Full: The desired state for an OSPF neighbor. It means the routers have synchronized their databases and can now share routing information.
- 2-Way: The routers have established bidirectional communication but are not yet fully adjacent. On multi-access networks (like Ethernet), routers that are not the Designated Router (DR) or Backup Designated Router (BDR) will stay in the 2-Way state with other non-DR/BDR routers.
- Init: A router has received a Hello packet from its neighbor, but the neighbor's Hello packet did not include the local router's ID in its neighbor list. This indicates one-way communication.
- Exstart / Exchange / Loading: These are transitional states. During this phase, routers are exchanging Database Description (DBD) packets to synchronize their link-state databases. If a router is stuck in one of these states, it often points to an MTU mismatch or a similar issue.
- Down: The router has not received a Hello packet from this neighbor within the
Deadtimer interval. The adjacency is lost. - Attempt (NBMA only): A unicast Hello packet was sent to a manually configured neighbor, but no reply was received.
Troubleshooting stuck neighbor states
A neighbor state that is not Full (or 2-Way on a multi-access network) indicates a problem.
- Down or Init: These states usually signify that OSPF Hello packets are not being received or processed correctly.
- Mismatched Parameters: OSPF neighbors must have matching parameters, including the area ID, subnet/subnet mask, authentication type/key, and Hello/Dead timer values.
- Connectivity Issues: Verify physical and data link layer connectivity with
show interfacesand by pinging the neighbor's IP address. - Firewall/ACLs: Check for firewalls or access control lists blocking OSPF multicast (224.0.0.5) packets.
- Exstart / Exchange / Loading: If a neighbor is stuck in one of these states, the most likely cause is an MTU mismatch.
- Check and Correct MTU: Use
show interfaces <interface-name>to verify the MTU on both sides of the link and configure them to match.
- Check and Correct MTU: Use
Dead Timer
The Dead timer shows the remaining time before the neighbor is declared down. You can monitor this value by repeatedly running the show ospf neighbor command. If the Dead timer is constantly counting down without resetting, it indicates Hello packets are not being received from the neighbor.
Advanced troubleshooting with traceoptions
For deeper analysis of OSPF behavior, Juniper's traceoptions feature can be configured to log OSPF events to a file. This is useful for capturing detailed information about why an adjacency is failing.
Configuration example:
# set protocols ospf traceoptions file ospf-trace size 10m
# set protocols ospf traceoptions flag hello detail
# set protocols ospf traceoptions flag error detail
Use code with caution.
After committing this configuration, you can view the log file from the CLI using show log ospf-trace. This log can reveal specific reasons for neighbor state transitions, such as mismatched parameters reported in Hello packets.