Parks and recreation engineers cannot form an OSPFv2 adjacency between a recreation-center router and a clinic WAN peer. Hello/dead timers and area IDs differ on the shared link. What is the most likely concept-level cause?
Select an answer to reveal the explanation.
Short Explanation
OSPFv2 neighbors are picky roommates—they need matching Hello/dead timers and the same area on that link. If parks and recreation and the clinic peer disagree on those basics, the adjacency never settles. Fix the mismatch before chasing fancy redistribution.
Full Explanation
Parks-and-recreation and clinic WAN peers form an OSPFv2 adjacency only when shared-link parameters are compatible. Matching Hello and dead timers and the same area ID on that link are classic adjacency prerequisites: mismatched intervals mean each side ages the neighbor differently, and different area IDs place the routers in different topologies so they never become neighbors on that interface. At concept level, timer or area disagreement on the common link is the most likely cause when Hellos are exchanged but adjacency never settles.
Claiming OSPFv2 ignores timer and area mismatches and fails only when Spanning Tree is disabled fails by concept: STP state on switches does not waive OSPF parameter matching, and OSPF explicitly checks timers and area. Blaming adjacency failure only when both routers advertise identical BGP router IDs mixes protocols—BGP RID collision is unrelated to OSPFv2 neighbor state on the municipal link. Requiring identical SNMP community strings before FULL invents a management-plane dependency; SNMP is not an OSPF adjacency prerequisite.
Exam caveat: CCNA troubleshooting prioritizes area ID, Hello/dead timers, network type, authentication, and subnet/mask compatibility—not STP, BGP, or SNMP—as first-line adjacency checks. Operational check: on both parks and clinic routers, compare show ip ospf interface Hello/dead values and area IDs on the shared link, align them, then re-check show ip ospf neighbor for TWO-WAY/FULL progression.