BGP Route Reflector Scaling
Route reflectors are where BGP scaling theory meets a genuinely confusing set of loop-prevention rules. This lab starts you on a full iBGP mesh, then has you convert it to a route-reflector design and prove the cluster-ID and originator-ID checks are actually working.
Not a mockup, this is the real topology
The problem
A client router in a route-reflector design stops receiving certain routes it should be reflected, even though the route reflectors themselves look healthy and their sessions are up.
What you'll practice
- Stand up a full iBGP mesh and observe its scaling limits
- Convert the mesh to a route-reflector and client design
- Configure a redundant route-reflector cluster with a shared cluster-ID
- Verify cluster-ID loop prevention and originator-ID handling
- Troubleshoot a client that isn't receiving reflected routes
The topology
Five iBGP routers begin fully meshed, then reconfigure around two route reflectors sharing a cluster-ID with three client routers, enough scale to see the mesh-to-RR conversion and its loop-prevention rules for real.
Topology diagram
Frequently asked
Is this the same BGP topic as the Peering & Path Selection lab?
No. That lab covers eBGP/iBGP peering and best-path policy. This one is scoped specifically to route-reflector design and its cluster/originator-ID loop-prevention rules.
Does this cover CCNP ENARSI route reflector topics?
Yes. Route reflector design and iBGP scaling are explicit ENARSI (300-410) blueprint items.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.