TTR Networks

Intermediate · BGP Fundamentals · section 6 of 9

iBGP and route reflectors

✓ Lab-tested 17 October 2026 on FRR 10.2.1

eBGP loop prevention relies on the AS_PATH, but inside a single AS the AS_PATH never changes. So iBGP has a blunt rule instead:

iBGP split horizon: a route learnt from an iBGP peer is never advertised to another iBGP peer.

The consequence is that every iBGP router must hear each external route directly from the router that learnt it — which means a full mesh of iBGP sessions. That is n(n−1)/2 sessions, which becomes unmanageable quickly.

Two standard solutions:

  • Route reflectors (RFC 4456) — designated routers are allowed to re-advertise iBGP routes to their clients. Clients only peer with the reflectors. Loops are prevented by the ORIGINATOR_ID and CLUSTER_LIST attributes.
  • Confederations (RFC 5065) — split the AS into sub-ASes that run eBGP-like sessions between them while appearing as one AS externally. Less common today.

Two other iBGP details catch everyone at least once:

  • NEXT_HOP is unchanged over iBGP. An internal router receives the external peer's address as next hop and may have no route to it. Fix with neighbor X next-hop-self on the border router, or carry the edge links in the IGP.
  • iBGP peers use loopbacks. Peering loopback-to-loopback (update-source lo) keeps the session up as long as any IGP path exists between the routers.
Diagram: iBGP full mesh — A five-router full mesh needs 10 iBGP sessions. Step through to see why the split-horizon rule forces this.
  1. R1 learns a route over eBGP. The ISP advertises 203.0.113.0/24 to R1.
  2. R1 tells every iBGP peer. Routes learnt from eBGP are advertised to all iBGP peers. The AS_PATH is not changed inside the AS, and by default NEXT_HOP is still the ISP's address (hence `next-hop-self`).
  3. iBGP split horizon. R2 will NOT pass the route on to R3: a route learnt from an iBGP peer is never advertised to another iBGP peer. AS_PATH can't detect loops inside one AS, so this rule does instead. The cost: every router must hear the route directly from R1.
  4. Count the sessions. Every router peers with every other: n(n−1)/2 = 5 × 4 / 2 = 10 sessions. Adding a sixth router means touching all five existing routers.
Diagram: iBGP with a route reflector — The same AS with a route reflector: four sessions, and the RR re-advertises iBGP-learnt routes to its clients.
  1. R2 learns a route over eBGP. Same starting point: an edge router hears 203.0.113.0/24 from the ISP.
  2. R2 sends it to the RR. R2 has a single iBGP session — to the route reflector.
  3. The RR reflects to its clients. A route reflector is allowed to break split horizon: routes from a client are reflected to all other clients. It adds ORIGINATOR_ID and CLUSTER_LIST attributes so reflected routes can't loop.
  4. n sessions instead of n². Four sessions instead of ten, and adding a router means configuring only the new router and the RR. In production you deploy two RRs for redundancy. Note the RR only reflects its own best path, which can hide alternatives (add-path solves this).

Check your understanding

How many iBGP sessions does a full mesh of 20 routers need?

  • 20
  • 190
  • 380
  • 400