A public-health department advertises eBGP-learned defaults into iBGP toward internal civic routers, but those routers cannot reach the ISP next-hop address. Which BGP neighbor setting on the border router most directly fixes that reachability gap?
Select an answer to reveal the explanation.
Short Explanation
You may receive an eBGP next hop on the ISP side that your internal routers cannot reach. next-hop-self rewrites it to the border router, so your IGP can carry traffic there.
Full Explanation
When the public-health department advertises eBGP-learned defaults into iBGP, BGP normally preserves the external NEXT_HOP. Internal civic routers then need an IGP or static route to the ISP-facing next-hop address; without one, packets can be blackholed even though the BGP prefix is installed. Configuring next-hop-self on the border router’s iBGP sessions rewrites the next hop to the border router, so internal routers need only IGP reachability to that router. eBGP multihop adjusts TTL for multihop eBGP sessions, such as loopback peering; it does not rewrite the next hop in routes advertised to iBGP peers. Route refresh and soft reconfiguration refresh or store policy-processed updates; they do not rebuild an ISP next-hop MAC address as a substitute for reachability, or change the NEXT_HOP attribute to the border router. A peer group can group neighbors for configuration reuse, but does not by itself force them into Established state or fix external next-hop unreachability. Exam caveat: next-hop-self is typically used on iBGP or confederation sessions when advertising eBGP-learned routes inward; IPv6 and VPNv4 can have related next-hop behaviors. Practical check: inspect BGP on an internal router to confirm the NEXT_HOP is the border router, verify IGP reachability to it, and trace the default route to confirm traffic enters the border rather than targeting the raw ISP address. On the border, confirm next-hop-self under the iBGP address family.