The data center core has been running clean for two years. Twenty routers, full-mesh iBGP, every route from every rack reaching every other rack because every router peers directly with every other router. It has worked the whole time, which is exactly why nobody looked hard at it. Then procurement approves rack 21, and the ticket to bring its router online reads like a chore list: add a new iBGP session, on every single one of the twenty existing routers, before the new box can see a single route the others already know.
That's not a one-line config change. That's twenty separate sessions, twenty separate config touches, on hardware that's been running in production without incident since the last expansion. The reason traces back to a rule that's easy to forget once a mesh is already built: an iBGP router will not re-advertise a route it learned from one iBGP peer to another iBGP peer. eBGP gets its loop protection for free, a router refuses a route that already has its own AS number in the AS-path. iBGP peers all share the same AS number, so that trick doesn't work between them, and the protocol's fallback is blunt: don't reflect iBGP-learned routes to other iBGP peers at all. The only way to guarantee every router still learns every route is for every router to peer with every other router directly. Full mesh.
The math behind why this stops scaling is just n(n-1)/2. Ten routers need 45 sessions. Twenty need 190. Fifty need 1,225. Every router added to an existing full mesh needs one new session per router already in it, so growth isn't linear, it's a new peering table entry on every box you already trust not to need touching.
Route reflectors are the fix, and they work by deliberately breaking the rule that caused the problem. RFC 4456 designates one or more routers in the AS as route reflectors. Everything else becomes a client, and clients peer only with the reflector, never with each other. The reflector is explicitly permitted to do what an ordinary iBGP router can't: take a route learned from one client and re-advertise, "reflect," it to the reflector's other clients and to any full-meshed non-client peers. A 20-router core with two reflectors and 18 clients needs roughly 36 sessions, not 190, and adding router 21 means peering it to the two reflectors, not to the other twenty.
Breaking the no-reflect rule on purpose creates a new loop risk, so RFC 4456 adds two attributes to close it. CLUSTER_LIST works like AS-path, but for reflection instead of AS hops, every cluster a route passes through gets appended, and a reflector drops anything that already carries its own cluster ID. ORIGINATOR_ID records the router ID of whoever first put the route into iBGP, so if it somehow loops back around to its origin, that router recognizes and drops it. Production designs run at least two reflectors per cluster, same cluster ID, specifically so a single reflector going down doesn't strand every client behind it without a path to the rest of the AS.
None of this is exotic, and none of it matters until the mesh you built for ten routers is the mesh you're still running at fifty, and the twenty-first router turns a five-minute config push into an afternoon of touching boxes nobody wanted to touch.
This is exactly the depth the Network Engineer L3 Book is scoped for: advanced BGP, data-center architecture, the design decisions that only bite once a network has already grown past the size it was designed for. https://resources.codelivly.com/product/network-engineer-l3/
The free Network Design and Architecture and WAN, VPN and Cloud Networking learning paths on codelivly.com cover the same senior-level architecture ground hands-on if you want to work through it before spending anything: https://codelivly.com/learning-paths/network-design-and-architecture and https://codelivly.com/learning-paths/wan-vpn-and-cloud-networking
