Skip to content
Calcrivo

BGP Route Reflector Planner

Compare iBGP full-mesh session counts against a route-reflector design and size the sessions each RR carries.

Inputs

routers
RRs
RRs
prefixes

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.2MB

Step by step

  1. Values used

    iBGP speakers = 40 routers; Route reflectors = 4 RRs; RRs each client peers with = 2 RRs; Prefixes carried = 100,000 prefixes

  2. 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.

  3. Reflector memory

    RR memory ≈ prefixes × paths × 300 bytes of path and attribute state.

  4. iBGP Sessions with Reflection

    = 78

  5. Sessions in a Full Mesh

    = 780

  6. Session Reduction

    = 90.00

  7. Sessions per Route Reflector

    = 21.0

  8. Reflector Clients

    = 36

  9. RR Path Memory

    = 57.2 MB

How it works

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.

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.

You might also need