iBGP & Route Reflection
iBGP has no loop prevention inside the AS, so it forbids a router from re-advertising an iBGP-learned route to another iBGP peer — which forces a full mesh: n*(n-1)/2 sessions, 4,950 of them in a 100-router AS. Route Reflection lifts that rule safely by stamping ORIGINATOR_ID and CLUSTER_LIST for loop detection. Change the topology and watch the session count and failure domain move. Validated against FRRouting bgpd/bgp_route.c + bgpd/bgp_attr.c and RFC 4456.
What you'll explore
- 01
Why iBGP Demands a Full Mesh
eBGP prevents loops with the AS_PATH — a router drops any route already carrying its own AS. Inside an AS the AS number never changes, so that mechanism is blind. iBGP's answer is a hard rule: a route learned from an iBGP peer is never re-advertised to another iBGP peer. Correct for loops, brutal for scale — every router must therefore peer directly with every other, which is n*(n-1)/2 sessions. Ten routers is 45; a hundred is 4,950. The session count is computed server-side and shown in the cascade, not in the browser.
- 02
The Split-Horizon Trap
The no-readvertise rule is iBGP split horizon, and it is exactly what breaks as the AS grows. Add one router and you don't add one session — you add a session to every existing router. The mesh grows quadratically while your team grows linearly, and a single missed session silently blackholes prefixes for the routers that never heard the UPDATE. This is the pain Route Reflection and Confederation exist to remove.
- 03
Route Reflection Lifts the Rule Safely
A Route Reflector is allowed to do the forbidden thing — reflect an iBGP route to other iBGP peers — but only because it also adds two attributes so loops can still be caught. ORIGINATOR_ID records the router that first injected the route (a client ignores a reflection of its own origination); CLUSTER_LIST records every cluster the route passed through. Clients need no mesh among themselves: they peer only with the reflector, collapsing the session count dramatically.
- 04
Clusters & Multi-Cluster Loop Prevention
Each reflector (or redundant reflector set) is a cluster with a CLUSTER_ID. When a reflector forwards a route it prepends its own CLUSTER_ID to the CLUSTER_LIST. If a reflector ever receives a route whose CLUSTER_LIST already contains its own CLUSTER_ID, the route looped and is dropped. This is what makes hierarchical, multi-cluster designs safe — and why a single reflector is a single point of failure that a redundant cluster removes.
- 05
Confederation — The Other Answer
Confederation attacks the same full-mesh problem differently: it splits one AS into several sub-ASes that speak eBGP-like sessions to each other while each sub-AS runs its own small internal mesh. Loop prevention comes back via AS_PATH — the sub-AS numbers are carried in confederation segments, which the best-path comparison counts. It scales like Route Reflection but changes your AS_PATH semantics, so the two are rarely mixed. When to use which is a design judgment the cascade spells out.
Validated against FRRouting frr-10.6.1 — bgpd/bgp_route.c and friends. Every simulated behavior cites a real source function, and a server-side correlation engine computes how each layer's state cascades into the next. See the methodology →
This module is part of zerohop Pro — it unlocks alongside the full kata library, progress tracking, and weak-area analysis.