AvailabilitySign inBook a DemoJoin Waitlist
Back to Learning
CCNP · ENARSIAdvanced

BGP Route Reflector Scaling

Two route reflectors, two established sessions, and exactly one path. Find out why the second one is not reflecting, live, right below.

Interactive simRoutingBGPRoute Reflectors

Symptom

Replace a full iBGP mesh with route reflectors and clusters: clients, non-clients, and cluster-ID loop prevention.

Your mission

Inspect, recover, then verify

Format

Cisco IOS CLI

Start interactive labSee the investigation plan ↓Need a hint? Reveal the root cause ↓
BGP Route Reflectors: The Client That Is Not One

Investigate before you configure.

Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.

Observe the symptom and link state.

Diagnose by comparing the protocol evidence.

Verify the expected device state and confirm the original symptom is resolved.

Console access: R4 (client) · RR1 (working) · RR2 (broken)

This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.

Need a hint?

Reveal the root cause when you're ready.

Try the investigation first, then use this as your escape hatch, not a dead end.

Locked

Sign up with your email to open BGP Route Reflector Scaling, free. You get the root cause and the full step-by-step fix.

No spam. The fix lands in your inbox too. Signing up includes 4 guided labs free, tracked against your email. After that, the Learning Pass unlocks every remaining lab.

Lab debrief

Turn the session into a repeatable troubleshooting pattern.

Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.

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.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Read the paths the client has
show ip bgp 192.168.50.0
Check both sessions and prefix counts
show ip bgp summary
Ask each reflector what the client is
show ip bgp neighbors 10.0.0.4

Topology diagram

Fact-checked references

The commands and behaviour in this lab were checked against these primary references.

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.

View availabilityBook a demo