A building permits desk sees OSPF neighbors stuck in 2-WAY on a shared Ethernet segment that already has a DR and BDR. Two additional routers remain DR-other. Is this necessarily a failure?
Select an answer to reveal the explanation.
Short Explanation
On multi-access Ethernet, only the DR and BDR need the full database dance with everyone. Two DR-others waving politely in 2-WAY at each other is normal—not a ticket. Panic if they can’t go FULL with the DR/BDR.
Full Explanation
On OSPF broadcast segments, DR-other routers form FULL adjacencies with the DR and BDR but typically remain 2-WAY with other DR-others. That behavior reduces adjacency count and LSDB exchange load and is expected, not an inherent failure. A building-permits desk seeing neighbors stuck in 2-WAY among DR-others on a shared Ethernet segment that already has a DR and BDR should treat that as normal OSPF broadcast behavior unless FULL adjacency is missing toward the DR and BDR themselves.
It is not true that every OSPF neighbor on broadcast media must reach FULL with every other router—that would defeat the DR/BDR optimization and explode adjacency scale. 2-WAY does not always mean authentication has failed on both peers; authentication problems usually affect progression more broadly, including relationships that should become FULL. 2-WAY among DR-others also does not mean OSPF has been replaced by EIGRP on that segment.
Exam caveat: if a router that should be DR or BDR is stuck 2-WAY with others, investigate priority, hello/dead timers, MTU mismatches, and authentication; do not “fix” normal DR-other 2-WAY pairs. Operational check: identify the DR and BDR, confirm each DR-other is FULL with both, accept 2-WAY between DR-others, and escalate only when FULL to DR/BDR is missing or flapping on the permits desk segment.