An emergency-management office peers city edge routers to two ISPs with eBGP and uses route reflection for iBGP inside the civic ASN. Which behavioral contrast should engineers keep foremost?
Select an answer to reveal the explanation.
Short Explanation
eBGP is the conversation with the outside world—you stamp your ASN and usually hand over a new next hop. iBGP is the hallway chat inside city hall—AS-path stays put, and you still need the IGP to reach whoever originated the route. Reflectors scale that hallway; they don’t turn it into eBGP.
Full Explanation
eBGP updates normally prepend the local AS and set next-hop to self (or the peering address), advertising reachability across AS boundaries. iBGP does not prepend the local AS again and commonly leaves next-hop unchanged, so an IGP must reach the advertising router’s next hop. An emergency-management office peering city edge routers to two ISPs with eBGP and using route reflection for iBGP inside the civic ASN should keep that behavioral contrast foremost: eBGP rewrites next-hop and prepends the local ASN, while iBGP preserves AS-path and often relies on IGP reachability to the original next hop.
iBGP and eBGP do not use identical next-hop and AS-path rewrite rules on every update. iBGP sessions still require an underlying IGP (or equivalent) for loopback and next-hop reachability; eBGP does not flood civic prefixes in a way that removes that need. Route reflectors relax iBGP full-mesh scale without converting all iBGP sessions into eBGP or forcing AS-path length to increase by one on every reflection.
Exam caveat: next-hop-self on route reflectors or borders is a common design choice that changes the “leave next-hop unchanged” default—know when your civic design applies it. Operational check: compare an eBGP-learned prefix’s AS-path and next-hop with the same prefix reflected via iBGP, confirm IGP reachability to next hops, and avoid treating RR clients like eBGP peers.