A housing authority dual-homes citizen-facing prefixes to two ISPs with eBGP while keeping iBGP among civic core routers. What roles do those BGP peering types play?
Select an answer to reveal the explanation.
Short Explanation
You use eBGP to connect your civic ASN to the outside ISPs, then iBGP to share the learned paths among core routers. That role split keeps external peering distinct from internal route distribution.
Full Explanation
eBGP connects the civic ASN to external ISP ASNs across administrative boundaries, while iBGP distributes learned and locally originated paths among routers inside the civic ASN. eBGP sessions on directly connected handoffs typically use TTL 1 and prepend the local AS to AS paths; iBGP lets core routers learn the edge’s routes without making the internal distribution another external AS hop or requiring BGP to replace the IGP. The statement that iBGP exchanges public routes between separate ASes while eBGP carries routes within one AS reverses the peering roles. The claim that eBGP cannot advertise public prefixes and only iBGP can connect to ISPs is operationally backwards: eBGP is the ISP-facing peering. Saying the two types have identical TTL and AS-path rules ignores differences in multihop needs, AS-path handling, next-hop behavior, and attribute preferences. Exam caveat: iBGP scaling requires a full mesh, route reflectors, or confederations; next-hop-self and IGP reachability to next hops also matter on the core. Practical check: use show ip bgp summary to verify eBGP sessions toward the ISPs and iBGP sessions among core routers, then confirm citizen prefixes are learned externally and distributed internally, and validate AS paths and next hops.