A county elections office runs OSPF over a hub-and-spoke radio WAN to landfill sites where spoke-to-spoke multicast is unreliable. Which OSPF network type best fits that design and what must the engineers plan for?
Select an answer to reveal the explanation.
Short Explanation
Picture a radio hub that cannot reliably reach every landfill spoke with multicast—you can use NBMA for that design. You define neighbors manually, and the multi-access segment still elects a DR and BDR, so plan their priorities and visibility.
Full Explanation
A county elections office running OSPF over a hub-and-spoke radio WAN should match the network type to the transport’s multicast and adjacency behavior. Nonbroadcast (NBMA) fits when spokes cannot reliably receive multicast hellos from one another: engineers statically define neighbors so adjacencies do not depend on multicast discovery across the radio cloud. NBMA remains a multi-access network, however, so DR and BDR elections still apply; typically, the hub has a nonzero priority and spokes have priority 0, making the hub the DR and keeping flooding centered there. Broadcast fails because it relies on multicast neighbor discovery, which unreliable spoke-to-spoke multicast can prevent, leaving adjacencies incomplete or unstable. Point-to-point on the hub interface fails because one interface facing multiple spokes does not become a set of true point-to-point circuits merely by changing its network type; it also does not make every spoke a DR simultaneously. Disabling OSPF hellos and relying on static routes to flood LSAs fails because it abandons OSPF adjacency formation and link-state database synchronization across the WAN. Exam caveat: do not assume that static neighbor configuration removes the NBMA DR/BDR election; plan which router should win and ensure the design supports that role. Practical check: verify neighbor statements and interface network type with show ip ospf neighbor and show ip ospf interface, confirm the hub and spoke priorities, and validate that LSAs flood through the hub without requiring spoke-to-spoke multicast.