Table of contents
- Start With OSPF-Enabled Interfaces
- Interpret Interface States
- Check Areas and Designated-Router Information
- Verify OSPF Neighbors
- Evaluate Point-to-Point Adjacencies
- Allow for Transitional States
- Decide Whether OSPF Is Operating Correctly
PassDump's practical standard for an OSPF check is simple: confirm the interfaces first, then confirm the neighbor state. An interface appearing in command output is not enough to conclude that OSPF is operating correctly. The interface state, configured area, designated-router information, neighbor count, and adjacency state all matter.
Start With OSPF-Enabled Interfaces
From the Junos CLI, enter:
show ospf interface
Use this command to verify that each interface on which OSPF is enabled is listed. The output is the starting point for checking whether the interfaces expected to participate in OSPF appear in the device's OSPF view.
The interface output includes several fields that support the check. Review the interface name, state, area, designated-router ID, backup designated-router ID, and neighbor count. The Area field shows the area configured for the interface. The DR ID field shows the IP address of the OSPF network's designated router. The neighbor count helps connect the interface view with the separate adjacency check.
A listed interface should therefore be read as an entry to inspect, not as an automatic operational result. The relevant question is whether the intended interface is present and whether its displayed fields match the expected OSPF arrangement.
Interpret Interface States
The State field distinguishes the condition or role shown for each interface. A state of PtToPt indicates a point-to-point connection. The supplied interface example also includes DR and Down states, so the output can contain different types of entries at the same time.
A Down state indicates a problem. Treat that interface as requiring further investigation rather than treating the entire interface listing as a successful OSPF verification. The supported check identifies the problem indication, but it does not identify the specific cause of the Down state.
The sample interface output illustrates why the state column must be read row by row:
Intf State Area DR ID BDR ID Nbrs
at-5/1/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-2/3/0.0 DR 0.0.0.0 192.168.4.16 192.168.4.15 1
lo0.0 DR 0.0.0.0 192.168.4.16 0.0.0.0 0
so-0/0/0.0 Down 0.0.0.0 0.0.0.0 0.0.0.0 0
so-6/0/1.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
so-6/0/2.0 Down 0.0.0.0 0.0.0.0 0.0.0.0 0
so-6/0/3.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
In this example, PtToPt identifies point-to-point entries, DR identifies designated-router entries, and Down identifies interfaces requiring further investigation. The area and DR ID values should be reviewed for each row, not assumed from the presence of another interface.
Check Areas and Designated-Router Information
For every intended OSPF interface, compare the displayed Area value with the area expected for that interface. The Area field represents the area for which the interface was configured. This makes the field useful for checking whether the interface is associated with the intended OSPF area.
Also review the DR ID field where designated-router information is relevant. The field contains the IP address of the OSPF network's designated router. The interface output can show different DR-related values for different rows, so inspect the value alongside the interface name and state.
The loopback and LAN interfaces linked to the OSPF network's designated router are identified under the Intf and State fields. That relationship should be read together with the DR ID field. A DR-related entry is not the same as a point-to-point entry, and the State field provides the distinction needed to interpret the row.
This part of the test answers whether the OSPF-enabled interfaces are present and whether their displayed area, state, and designated-router information are suitable for the intended topology. It does not establish that all adjacencies are fully formed.
Verify OSPF Neighbors
From the Junos CLI, enter:
show ospf neighbor
OSPF neighbors are interfaces that have an immediate adjacency. Use the neighbor output to verify which immediate adjacencies are listed and to inspect the fields associated with each one.
The neighbor output identifies the neighbor address, interface, state, router ID, priority, and the number of seconds allowed for inactivity, shown as dead time. These fields provide more information than a simple neighbor count. The State field is the key indicator for deciding whether the listed neighbor is fully established.
A listed neighbor is not necessarily a fully established neighbor. Check the state on each row. The supplied neighbor example includes both Full and 2Way entries:
Address Intf State Router ID Pri Dead
192.168.254.225 fxp3.0 2Way 10.250.240.32 128 36
192.168.254.230 fxp3.0 Full 10.250.240.8 128 38
192.168.254.229 fxp3.0 Full 10.250.240.35 128 33
10.1.1.129 fxp2.0 Full 10.250.240.12 128 37
10.1.1.131 fxp2.0 Full 10.250.240.11 128 38
10.1.2.1 fxp1.0 Full 10.250.240.9 128 32
10.1.2.81 fxp0.0 Full 10.250.240.10 128 33
The Full rows show neighbors that have reached the supplied target state. The 2Way row must be interpreted as a state value, not silently treated as Full. The interface, router ID, priority, and dead-time fields remain useful for identifying and comparing the neighbor entries.
Evaluate Point-to-Point Adjacencies
For a point-to-point connection between the device and another router running OSPF, verify that each router has a single OSPF neighbor. Then verify that the neighbor reaches Full state.
This gives the point-to-point check two parts. First, confirm the expected one-neighbor relationship. Second, confirm the adjacency state. A point-to-point interface showing PtToPt in the interface output does not by itself prove that the remote adjacency has completed. The neighbor command supplies the separate state check.
If the state is not Full after 30 seconds, the OSPF configuration between the neighbors is not functioning correctly. That result identifies an unsuccessful condition for the supplied verification, but it does not identify the specific reason. Do not infer a cause for a non-Full state from the state value alone.
Allow for Transitional States
OSPF connectivity may take several seconds to establish because full connectivity is established through a series of packet exchanges. If a neighbor is shown as Waiting, check the output again after several seconds.
During adjacency negotiation, a neighbor may temporarily appear in Attempt, Init, or 2way, depending on the stage of negotiation. These states should be interpreted in that context rather than automatically treated as final failure. The useful distinction is between a state observed during negotiation and a state that remains below the expected Full state after the stated interval.
A repeat check is therefore part of interpreting transient output. Waiting calls for another check after several seconds. Attempt, Init, and 2way can reflect a negotiation stage. A persistent state below Full after the stated interval indicates that the configuration between the neighbors is not functioning correctly, while the underlying cause remains outside this verification result.
Decide Whether OSPF Is Operating Correctly
Use both command outputs before reaching a conclusion. First, confirm that every intended OSPF-enabled interface is listed. For each relevant row, inspect the interface state, configured area, designated-router ID, and neighbor count. A Down interface is a problem requiring further investigation, even when other interfaces appear with PtToPt or DR states.
Next, run show ospf neighbor and inspect the adjacency state rather than relying only on the presence of a neighbor row. For point-to-point connections, check for one OSPF neighbor on each router and a Full state. Recheck Waiting after several seconds, and interpret temporary Attempt, Init, or 2way states according to their negotiation context.
PassDump's bounded decision is to call the OSPF check complete only when the intended interfaces are present, their displayed fields are appropriate for the expected arrangement, no relevant interface is left in Down state, and the required point-to-point neighbors reach Full state. This conclusion covers Junos interface and neighbor verification. It does not extend to initial OSPF configuration, broader route-control design, route-table completeness, or a specific diagnosis for a Down or non-Full state.