The adjacency contract
A link can carry ICMP while lacking an OSPF adjacency. Pinging the directly connected address exercises local forwarding and an ICMP response; it does not check Hello parameters or database exchange. First identify interfaces, addresses, area, router IDs and network type at both ends. Compare Hello and Dead intervals, authentication and policy permitting OSPF. Do not change all these fields together: that would lose the connection between hypothesis and result. Retain a baseline observation and choose the smallest change that tests the hypothesis.
Case: the batch lost its route
In a fictional scenario, R2 connects the backbone to area 10 and R3 advertises batch endpoints. A change makes R2’s transit interface passive. This option stops OSPF participation on that interface but does not shut down its IP address or inherently prevent data traffic. R2 can still ping R3’s directly connected address; R1 eventually loses routes to endpoints behind R3. APS should correlate the change time with neighbors and routes instead of accepting a transit ping as proof of service recovery.
The same setting in different roles
A loopback can be passive while remaining advertised through other OSPF interfaces. That is appropriate when its prefix must be reachable but no neighbor needs discovery on that interface. Applying the same policy to required transit breaks the design. In Cisco IOS XE, passive-interface is configured under the OSPF process; the FRRouting lab uses ip ospf passive on the interface. A shared concept does not make commands interchangeable. Before moving a solution between platforms, confirm syntax, version and observed state. A FRRouting result validates this protocol exercise, not execution on IOS XE.
Timers and intermediate states
The lab starts with one-second Hello and four-second Dead intervals on point-to-point transit links. Changing only R3’s Hello to two seconds creates a mismatch. Adjacency and route withdrawal can take time; one snapshot immediately after the change does not settle the diagnosis. The runner waits for a condition with a timeout rather than assuming a fixed delay is sufficient. These timers accelerate the exercise and are not a production recommendation. On broadcast networks, also consider DR and BDR roles before interpreting 2-Way as failure; this lab uses point-to-point links and does not demonstrate that election.
Exstart does not identify the cause alone
If a neighbor remains in Exstart or Exchange, investigate Database Description exchange. An MTU mismatch is a Cisco-documented possibility, but not the only one. Compare both endpoint MTUs and diagnostic messages before correcting them. Ignoring the MTU check does not increase the path’s transport capability. After recovering adjacency, check routes and traffic with source addresses and sizes appropriate to the service. This lab does not inject MTU failures: that diagnosis is an additional documentation exercise requiring its own test on the chosen platform.
# FRRouting 10.4.5, disposable lab only
show ip ospf neighbor
show ip ospf interface eth1
show ip route
# On r2, inject one failure, then remove it:
configure terminal
interface eth1
ip ospf passive
# Recovery: no ip ospf passive
Transit ping works; the endpoint route disappeared after making transit passive.
Common pitfalls
Changing several parameters without a baseline; copying syntax between platforms; accepting a connected ping as a complete test.
Related topics: OSPF: areas, summarization and covered destinations · OSPF lab and operational acceptance
Observe neighbors, parameters, routes and the destination from the relevant source before accepting recovery.
Reference: FRRouting OSPFv2 · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise