A parks department wants a known-good OSPF path to city hall to remain preferred over an iBGP-learned copy of the same prefix. What AD relationship makes that outcome correct by default?
Select an answer to reveal the explanation.
Short Explanation
The iBGP path is the polite distant relative at AD 200, so your local OSPF path at 110 already has dibs on city hall. You don't need knobs unless someone previously messed with distance.
Full Explanation
By default, OSPF’s administrative distance is 110 and iBGP’s administrative distance is 200. When a parks department router learns a city-hall prefix from OSPF and also receives an iBGP copy of the same prefix, the lower AD wins, so OSPF remains preferred without any distance tuning. That outcome matches the usual design intent: trust the local IGP path to city hall over an iBGP-reflected copy that may exist for overlay, Internet edge, or inter-VRF policy reasons.
The claim that iBGP AD 20 already beats OSPF, so distance must be raised on OSPF, reverses eBGP and iBGP. AD 20 is the eBGP default, not iBGP. iBGP at 200 loses to OSPF at 110, so there is no need to raise OSPF’s distance to protect the IGP path. The claim that both protocols share AD 110, so a route-map local preference is mandatory, is incorrect; they do not, and local preference is a BGP attribute used among BGP paths, not a mandatory knob to prefer OSPF over iBGP. The claim that iBGP always installs before any IGP, so OSPF can never win, invents a rule. IOS RIB selection is AD-driven; iBGP does not preempt OSPF by default.
Exam caveat: if the parks edge also has an eBGP path (AD 20) for the same city-hall prefix, eBGP would beat OSPF unless distance is raised on eBGP or lowered on OSPF—an important contrast with iBGP. Also watch for 'bgp distance' or 'distance bgp' configurations that lower iBGP below 110 and accidentally prefer reflected BGP over the IGP. Synchronization is largely historical and is not the modern mechanism that makes OSPF win here.
Operational check: show ip route <city-hall-prefix> should show O [110/…] while show ip bgp <prefix> still displays the iBGP path as a valid BGP route not installed (or installed only if AD/policy changed). show run | section router bgp and show ip protocols confirm no non-default BGP distances. Traceroute from a parks LAN toward city hall should follow the OSPF next hop, not the iBGP next hop.