Why iBGP Requires a Full Mesh in the First Place
BGP includes a loop-prevention rule specific to iBGP, discussed earlier in this series: a router will never re-advertise a route learned via iBGP to another iBGP peer. This rule exists because iBGP routes carry no AS path modification within the same AS, discussed earlier in this series regarding the AS path attribute, so BGP cannot rely on AS path loop detection the way it does between different autonomous systems.
The consequence of this rule: for every router
in an AS to actually learn every route, every
router must have a DIRECT iBGP session with
every other router in that AS -- since a route
cannot be relayed through an intermediate iBGP
peerThe Quadratic Scaling Problem
Number of required iBGP sessions for full mesh:
n(n-1)/2, where n is the number of routers
4 routers: 6 sessions
10 routers: 45 sessions
50 routers: 1,225 sessions
100 routers: 4,950 sessionsBeyond simply the administrative burden of configuring and maintaining this enormous number of individual sessions, each session consumes actual memory and CPU resources on every router, since each router must track the complete state of every one of its many neighbor relationships -- this becomes genuinely impractical well before reaching anywhere near a hundred routers.
Route Reflectors: Relaxing the Loop-Prevention Rule Safely
A Route Reflector (RR) solves this by acting as a designated exception to the standard iBGP rule: specific routers are configured to "reflect" (re-advertise) iBGP-learned routes to their other iBGP clients, eliminating the need for those clients to peer directly with every other router in the AS.
Route-Reflector(config)# router bgp 65001
Route-Reflector(config-router)# neighbor 10.0.0.2 remote-as 65001
Route-Reflector(config-router)# neighbor 10.0.0.2 route-reflector-client
Route-Reflector(config-router)# neighbor 10.0.0.3 remote-as 65001
Route-Reflector(config-router)# neighbor 10.0.0.3 route-reflector-client
-- The route-reflector-client keyword is applied
-- ONLY on the route reflector itself, identifying
-- which neighbors are its clients -- the clients
-- themselves require no special configuration
-- beyond a completely normal iBGP sessionResulting session count with a route reflector:
Clients only need ONE session each, to the RR,
rather than a direct session with every other
router -- reducing what would have been dozens
or hundreds of sessions down to just a handful
per clientClient, Non-Client, and the RR's Own Role
Route Reflector terminology:
Client: a router explicitly configured with
route-reflector-client, receiving reflected
routes from the RR without needing sessions
to every other router
Non-Client: a router with a normal iBGP session
to the RR, but WITHOUT the client keyword --
this router still needs the traditional full
mesh with every other non-client router,
since the RR does not reflect routes to
non-clients from other non-clients
Cluster: the RR together with all of its clients,
identified by a Cluster ID used to detect
reflection loops in more complex designs
with multiple redundant route reflectorsLoop Prevention Within Route Reflection
Since route reflection deliberately breaks the standard "never re-advertise iBGP routes to iBGP peers" rule, two new BGP attributes exist specifically to prevent loops that this relaxation could otherwise introduce.
Originator ID: identifies the router ID of the
route's original source within the AS -- if
a router receives a reflected route with its
own router ID as the Originator ID, it
recognizes and discards this as a loop
Cluster List: similar in concept to the AS Path
attribute, discussed earlier in this series,
but tracking which route reflector clusters
a route has passed through -- if a route
reflector sees its own Cluster ID already
present in this list, it discards the route
as a loopVerifying Route Reflector Operation
Route-Reflector# show ip bgp neighbors 10.0.0.2 | include reflector
Route-Reflector Client, for the address family: IPv4 Unicast
Client-Router# show ip bgp 192.168.5.0
BGP routing table entry for 192.168.5.0/24
Local
10.0.0.5 from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 10.0.0.5, Cluster list: 10.0.0.1The presence of an Originator and Cluster list in the route's detail confirms it was learned via reflection rather than a direct, traditional iBGP session -- useful verification when confirming a route reflector design is actually propagating routes as intended.
Confederations: An Alternative Approach
BGP Confederations solve the same full-mesh scaling problem through a fundamentally different mechanism: dividing one large AS into multiple smaller sub-autonomous systems, with eBGP-like sessions (though using a special confederation-aware variant) between the sub-AS, while the entire confederation still appears as a single AS to the outside world.
Router(config)# router bgp 65501
Router(config-router)# bgp confederation identifier 65001
Router(config-router)# bgp confederation peers 65502 65503
-- 65501, 65502, 65503 are private sub-AS numbers,
-- visible only within this organization's own
-- network
-- 65001 is the single AS number the outside
-- world actually sees when peering with this
-- organization via normal eBGPWhy this reduces the mesh requirement:
Full mesh is still required, but only WITHIN
each smaller sub-AS, not across the entire
original large AS -- dividing 100 routers into
4 sub-AS of 25 routers each reduces the total
mesh sessions from n(n-1)/2 for 100 routers
down to 4 separate meshes of only 25 routers
each, a dramatically smaller total numberComparing Route Reflectors and Confederations
Route Reflectors:
- Simpler to implement on an existing network,
since it only requires configuration changes
on the designated reflector routers themselves
- Client routers require essentially no
special configuration
- The most commonly deployed solution in
real-world large-scale networks
Confederations:
- Requires re-numbering routers into sub-AS
groups, a more significant redesign effort
- Provides a clearer visual/administrative
division that can align with an
organization's own internal structure
(e.g., separate sub-AS per region or
data center)
- Less commonly deployed than route reflectors
in practice, due to the greater
reconfiguration effort involvedWhy Both Solutions Address the Same Fundamental Constraint
Both route reflectors and confederations exist specifically to work around the same underlying iBGP loop-prevention rule discussed at the start of this article, using entirely different mechanisms -- one relaxes the propagation rule for designated routers, the other restructures the AS itself into smaller pieces where full mesh remains locally practical. Understanding this shared root cause, rather than simply memorizing each solution's configuration syntax, is what allows an engineer to correctly diagnose which approach best fits a specific network's existing topology and administrative structure when the standard iBGP full mesh has become impractical to maintain.