Code enforcement cannot bring up OSPFv2 neighbors on a link where one router is in area 0 on 10.10.10.0/30 and the peer is in area 5 on 10.20.20.0/30. What prerequisite issue should they fix first?
Select an answer to reveal the explanation.
Short Explanation
OSPFv2 neighbors need to share a subnet and agree on the area—like meeting on the same street in the same district. Code enforcement’s area-0 /30 versus area-5 different /30 setup fails those basics. Fix addressing and area match before blaming Spanning Tree or BGP.
Full Explanation
Code-enforcement routers cannot form OSPFv2 neighbors when one side is in area 0 on 10.10.10.0/30 and the peer is in area 5 on 10.20.20.0/30. Adjacency requires (among other matches) the same area on a shared subnet so Hellos are accepted and both routers agree they are in one topology on that link. Different areas and disjoint /30s violate those prerequisites, so the first fix is placing both neighbors in the same area on a common subnet.
Installing BGP route reflectors so OSPF can ignore IP addressing fails by concept: BGP reflectors do not waive OSPF area or subnet matching. Enabling port-security sticky MAC learning on both WAN serial interfaces fails by concept: port security is a Layer-2 access control feature, not an OSPF adjacency cure, and serial WAN links are the wrong place for that framing. Lowering Spanning Tree priority on both routers until OSPF Hellos appear fails by concept: STP priority does not create OSPF parameter compatibility.
Exam caveat: area mismatch and subnet mismatch are independent blockers—fixing only one may still leave adjacency down. Operational check: renumber or re-address so both interfaces share a subnet, set the same area ID on that link, then verify Hellos and show ip ospf neighbor before chasing advanced features.