A fire district sources iBGP sessions from loopback addresses on each router. What dependency must remain true for those sessions to stay up and for next hops to resolve?
Select an answer to reveal the explanation.
Short Explanation
iBGP over loopbacks is two firehouses calling each other by station number, not by the street they’re on today. The IGP has to know how to reach those station numbers, or the call never connects—and next hops still need a route.
Full Explanation
iBGP sessions bound to loopbacks require an underlying IGP or other underlay to reach those loopbacks independently of any single transit interface. Operators typically set update-source to the loopback and ensure BGP next hops resolve via the IGP. A fire district sourcing iBGP from loopbacks must keep that dependency true: the IGP must reach each peer’s loopback, and next-hop addresses must be resolvable in the routing table. Disabling the civic IGP breaks both session stability and next-hop resolution.
eBGP multihop is an eBGP concept and is not required on every iBGP loopback session for TCP to form. Loopback-sourced iBGP does not remove the need for update-source or IGP reachability between peers. Only static /32 routes to ISP PE addresses are not sufficient while disabling the civic IGP—that leaves iBGP next hops and loopbacks unresolved inside the AS.
Exam caveat: next-hop-self on route reflectors changes what must be resolved, but loopback reachability between iBGP endpoints remains foundational. Operational check: ping between loopbacks via IGP, confirm BGP sessions stay up when a single transit link fails, verify recursive next-hop resolution for learned prefixes, and avoid pointing iBGP solely at interface addresses without a resilience plan.