A county courts border router must form eBGP to an ISP using loopback endpoints rather than the directly connected interface addresses. Which feature enables that peering?
Select an answer to reveal the explanation.
Short Explanation
Loopback-to-loopback eBGP is like calling a friend two doors down. The peer is not on the directly connected subnet, so you need eBGP multihop permission for the TCP session to form. Without it, the courts border never completes the ISP handshake.
Full Explanation
When a county courts border router must form eBGP to an ISP using loopback endpoints rather than directly connected interface addresses, eBGP multihop is the feature that permits the TCP session to form across more than one IP hop. By default, eBGP expects TTL 1 to a directly connected peer; loopback-to-loopback peering requires raising the TTL (multihop) and ensuring the loopbacks are reachable via the IGP or static routing underneath. That is why eBGP multihop correctly enables the courts-to-ISP loopback peering design. OSPF demand circuit on the ISP handoff does not create BGP TCP reachability to loopbacks and is an OSPF interface feature, not an eBGP peering enabler. Disabling split horizon under the BGP process only is not how loopback eBGP is established and misapplies a routing-advertisement concept. Passive-interface default on all BGP-facing interfaces is an IGP concept and would not enable loopback eBGP; it is unrelated to BGP TCP multihop. Exam caveat: multihop alone is insufficient without route to the peer loopback, correct update-source loopback, and usually authentication/TTL security considerations; do not confuse with iBGP, which already allows multihop by default. Operational check: configure neighbor ebgp-multihop and update-source loopback; verify loopback reachability with ping/traceroute; confirm Established in show ip bgp summary and that the peer IP is the intended loopback.