BGP Deep Dive Part 5: eBGP and iBGP Are Not the Same Protocol Wearing One Name

Every attribute and every algorithm step covered so far behaves differently depending on whether a session is eBGP or iBGP. This post pulls those differences together into one place, because the gap between the two isn’t a list of minor exceptions, it’s the reason iBGP needs an architecture at all, which is where Part 6 picks up.

AS_PATH loop prevention only works across AS boundaries

Part 1 introduced AS_PATH as BGP’s loop-prevention mechanism: a speaker rejects any route whose AS_PATH already contains its own AS number. That works cleanly for eBGP, because every eBGP hop prepends an AS number, so a route that loops back around to its origin AS will visibly contain that AS number again by the time it returns.

Part 3 covered the detail that makes this mechanism useless inside an AS on its own: an iBGP speaker does not modify AS_PATH when advertising to another iBGP peer. If three iBGP speakers inside the same AS just forwarded routes to each other freely, a route could circulate among them indefinitely with an AS_PATH that never changes and therefore never triggers the loop check. AS_PATH genuinely cannot do this job internally, because the entire signal it relies on, a growing list of hops, doesn’t grow within an AS by design.

The rule that actually prevents iBGP loops: no iBGP-to-iBGP re-advertisement

BGP’s real answer to that gap is a much blunter rule, and it’s worth stating precisely because it’s the single most consequential fact in this post: a route learned from an iBGP peer must not be re-advertised to another iBGP peer. A speaker is only allowed to advertise a route to its iBGP peers if that route was either learned via eBGP or originated locally. This is sometimes called iBGP split-horizon, and unlike AS_PATH’s loop detection, it doesn’t rely on inspecting anything in the route, it’s a blanket rule about which direction information is allowed to flow.

It works, but it has an immediate, unavoidable consequence. If iBGP speaker A learns a route from an external peer and advertises it to iBGP speaker B, and B is forbidden from passing that route on to iBGP speaker C, then C only learns the route at all if C has its own direct iBGP session to A, or to some other speaker that itself learned the route via eBGP. Generalize that across every router and every externally learned route in the AS, and the requirement falls out directly: every iBGP speaker needs a direct session to every other iBGP speaker in the AS. That’s the full mesh, and it isn’t a design convention someone chose for tidiness, it’s the mechanical consequence of the split-horizon rule being the only thing standing in for the loop detection AS_PATH can’t provide internally.

A full mesh of n routers requires n(n-1)/2 sessions, the count of unique pairs among them, which grows as O(n²): fine at three or four routers, and genuinely unworkable at the scale a real enterprise or provider network runs at. A 50-router AS needs 1,225 iBGP sessions; a 200-router AS needs 19,900. Part 6 covers the two mechanisms, route reflection and confederations, that exist specifically to relax this rule in a controlled way rather than remove it.

NEXT_HOP, revisited

Part 3’s next-hop gotcha is really just this same eBGP/iBGP asymmetry showing up in a different attribute. Advertising across an eBGP session, a speaker typically sets NEXT_HOP to itself. Advertising across an iBGP session, it doesn’t rewrite NEXT_HOP by default, the value keeps pointing at whatever router originally learned the route externally. Every iBGP speaker downstream of that point needs IGP reachability to that specific address, which is exactly why next-hop-self exists as a deliberate override on whichever router sits at the eBGP/iBGP boundary.

LOCAL_PREF and MED are asymmetric on purpose

LOCAL_PREF, from Part 3, is sent on every iBGP advertisement and never sent to an external peer at all, except under confederations. That’s not an oversight, it’s the attribute doing exactly its job: LOCAL_PREF represents this AS’s internal policy preference, and there’s no reason, and real reason not, to expose an internal preference ranking to a neighboring AS that has no business acting on it.

MED runs the opposite direction. A MED value received over eBGP can be passed on to iBGP peers within the same AS, but it must not be forwarded on to a third AS. It’s meant to influence exactly the one neighboring AS that sent it, or that AS’s own internal view of the route; it was never meant to become a global metric visible three ASes away.

Administrative distance: a vendor concept, not a BGP one, but a real practical difference

Most implementations also treat eBGP-learned and iBGP-learned routes differently at the RIB level, before any of BGP’s own attribute-based tie-breaking even runs. Cisco’s administrative distance gives eBGP routes a default value of 20 and iBGP routes 200, meaning an eBGP-learned route will always win a place in the routing table over an equally specific iBGP-learned route to the same destination, and in fact over most IGP-learned routes too. Juniper and FortiOS have their own equivalent preference mechanisms with different numbers but the same shape. None of this is defined in RFC 4271, it’s entirely a vendor RIB concept sitting one layer below BGP’s own decision process, but it’s real, and it’s worth knowing as a separate axis from everything Part 4 covered: Part 4’s algorithm picks the best BGP path among BGP candidates, administrative distance decides whether a BGP route wins a slot in the forwarding table at all against a non-BGP alternative.

A rule mostly retired: BGP synchronization

Older BGP implementations enforced a synchronization rule: a route learned via iBGP shouldn’t be used, or advertised to an eBGP peer, unless the same destination was also known via the AS’s IGP. The idea was to avoid a transit AS advertising reachability to a destination that its own interior routers, running the IGP alone, couldn’t actually forward toward yet. It made sense when IGPs sometimes carried full or near-full route information and BGP tables were smaller. It stopped making sense once IGPs were kept deliberately lean and BGP tables grew into the hundreds of thousands of prefixes, since requiring IGP synchronization at that scale is both unworkable and unnecessary given a properly full-meshed or reflected iBGP topology already guarantees reachability information gets where it needs to go. Every mainstream implementation disables synchronization by default today, but it’s worth knowing the rule existed and why it was retired rather than encountering the term in an old config and wondering what it does.

Part 6 is where the full-mesh problem this post ends on actually gets solved: route reflectors and confederations, the two ways of relaxing the iBGP re-advertisement rule without giving up the loop safety it provides.