Compare iBGP full-mesh session counts against a route-reflector design and size the sessions each RR carries.
iBGP does not re-advertise routes between peers, which forces a full mesh that grows quadratically. RFC 4456 lets a reflector pass routes between clients, using ORIGINATOR_ID and CLUSTER_LIST for loop prevention, so sessions grow linearly with speaker count instead. At 40 speakers a full mesh is 780 sessions and every new router touches all of them; reflection makes adding a router a two-session change, which is the difference between a maintainable network and a configuration freeze.
BGP Route Reflector
A full iBGP mesh needs n(n − 1) ÷ 2 sessions; with reflection it is clients × RRs-per-client plus the RR mesh of r(r − 1) ÷ 2.
Reflector memory
RR memory ≈ prefixes × paths × 300 bytes of path and attribute state.
A full iBGP mesh needs n(n − 1) ÷ 2 sessions; with reflection it is clients × RRs-per-client plus the RR mesh of r(r − 1) ÷ 2. iBGP does not re-advertise routes between peers, which forces a full mesh that grows quadratically. RFC 4456 lets a reflector pass routes between clients, using ORIGINATOR_ID and CLUSTER_LIST for loop prevention, so sessions grow linearly with speaker count instead.
At 40 speakers a full mesh is 780 sessions and every new router touches all of them; reflection makes adding a router a two-session change, which is the difference between a maintainable network and a configuration freeze.
This calculator takes 4 inputs: iBGP speakers, Route reflectors, RRs each client peers with, Prefixes carried. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
No, and it is usually better if they are not. Dedicated reflectors — often virtual machines — carry only control plane, but they must have full IGP visibility, since a reflector advertises the best path from its own perspective rather than the client's.