BGP Route Reflector Planner
Compare iBGP full-mesh session counts against a route-reflector design and size the sessions each RR carries.
About BGP Route Reflector Planner
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.
Formulas
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.
- n
- iBGP speakers in the autonomous system
- r
- Route reflectors, which remain fully meshed with each other
- RRs per client
- Redundancy — two is standard, so a single RR failure is not a partition
Reflector memory
RR memory ≈ prefixes × paths × 300 bytes of path and attribute state.
Worked example
With the default values below, BGP Route Reflector Planner returns iBGP Sessions with Reflection of 78. Change any input above and every figure here is recalculated in your browser.
Inputs used
- iBGP speakersaccepts 2–2,000 routers
- 40 routers
- Route reflectorsaccepts 1–64 RRs
- 4 RRs
- RRs each client peers withaccepts 1–8 RRs
- 2 RRs
- Prefixes carriedminimum 1 prefixes
- 100,000 prefixes
Results
- iBGP Sessions with Reflection
- 78
- Sessions in a Full Mesh
- 780
- Session Reduction
- 90.00%
- Sessions per Route Reflector
- 21.0
- Reflector Clients
- 36
- RR Path Memory
- 57.2 MB
Step by step
- 1Values used
- 2BGP Route Reflector
- 3Reflector memory
- 4iBGP Sessions with Reflection= 78
- 5Sessions in a Full Mesh= 780
- 6Session Reduction= 90.00
- 7Sessions per Route Reflector= 21.0
- 8Reflector Clients= 36
- 9RR Path Memory= 57.2 MB
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is BGP Route Reflector calculated?
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.
Why does BGP Route Reflector matter?
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.
What values do I need to enter?
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.
Do reflectors need to be in the forwarding path?
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.