Transit OCC routers on a shared Ethernet segment fail to form a stable OSPF adjacency after one side is set to point-to-point and the other remains broadcast. What is the most likely impact of that network-type mismatch?

OSPF network types dictate hello/dead timer expectations and whether DR/BDR election occurs. On a shared Ethernet segment at the transit OCC, a broadcast interface expects DR/BDR election and typically uses broadcast-style hello behavior, while point-to-point skips DR election and uses point-to-point adjacency rules. When one OCC router is set to point-to-point and the peer remains broadcast, those expectations disagree, which commonly prevents or destabilizes the adjacency even though IP connectivity on the LAN may look fine.

OSPF automatically converting both interfaces to EIGRP so metrics can converge is nonsense; network-type mismatch does not invoke another routing protocol. The mismatch only affecting BGP TTL security and never touching OSPF hellos misattributes the symptom to BGP. All OSPF areas collapsing into a single stub area until network types match invents an area-wide side effect that network-type mismatch does not cause.

Exam caveat: mismatched hello/dead timers from network types (or manual timer changes) are a top adjacency failure cause. On Ethernet used as a pure two-router link, intentionally setting both sides to point-to-point is valid—but both must match. Broadcast vs point-to-multipoint vs non-broadcast each carry different neighbor and DR rules.

Operational check: align ip ospf network type on both OCC Ethernet interfaces, verify matching hello/dead timers and expected DR behavior (or lack thereof), clear the adjacency, and confirm FULL state with stable LSDB exchange before returning the transit routers to production traffic.