Twenty iBGP routers need 190 sessions for a full mesh; fifty need 1,225. Every new router means touching every existing router. The full mesh exists because of the iBGP split-horizon rule — no router may relay an iBGP-learned route to another iBGP peer — so the fix is surgical: relax that rule for one designated class of router, and give it attributes that keep loop-freedom intact.
Route reflectors
A route reflector (RR) is an iBGP speaker allowed to reflect routes between its clients. The rules: a route from a client is reflected to all other clients and all non-clients; a route from a non-client is reflected to clients only; eBGP routes go to everyone. Clients simply peer with the RR (or, always, two RRs for redundancy) and need no special configuration — the mesh collapses from n² sessions to one or two per router.
Two attributes replace the safety the split-horizon rule provided: originator-ID (the router ID of the route's first iBGP speaker — a router seeing its own ID discards the route) and cluster-list (the chain of RR cluster IDs the route has crossed — an RR seeing its own cluster ID discards it). AS-path, next-hop and MED are never changed by reflection.
One design caution: an RR chooses and reflects its best path, so clients see the RR's choice, not all choices. Place RRs along the physical topology (or use add-path/optimal-route-reflection features) so 'best from the RR's seat' does not mean 'wrong from the client's seat'.
RR(config)# router bgp 65001RR(config-router)# neighbor 10.0.0.11 remote-as 65001RR(config-router)# neighbor 10.0.0.11 route-reflector-clientRR(config-router)# neighbor 10.0.0.12 remote-as 65001RR(config-router)# neighbor 10.0.0.12 route-reflector-client
Configuration and update scaling
Peer groups (or the modern peer templates) exist for two reasons. Administratively, fifty neighbours sharing one policy are configured once. Computationally, BGP builds each update once per update group — the set of neighbours sharing outbound policy — instead of once per neighbour; on a router with hundreds of peers this is the difference between minutes and seconds of update generation. IOS forms update groups automatically, but coherent per-class policy is what makes the groups large and the wins real.
Convergence: detect fast, react calmly
- Session failure: BFD (neighbor x fall-over bfd) detects a dead peer in milliseconds; fast-external-fallover tears down eBGP on interface loss. Waiting for the 180-second hold timer is the pathological default to design away.
- Next-hop tracking: BGP registers its next hops with the RIB watcher and reacts to IGP changes in seconds — this, more than any timer, is what modern iBGP convergence rests on. Keep next hops as stable loopbacks reachable via the IGP.
- Path pre-installation: BGP PIC and additional-paths install a backup path in the FIB so failover is a pointer swap, not a best-path recomputation.
- Flap control: route dampening penalises flapping prefixes (suppress at 2000, half-life 15 min) — useful facing customer edges, blunt facing the full table; prefer fixing the flap.
- Table hygiene: maximum-prefix guards against a peer accidentally sending you the Internet twice.
The architecture that emerges — loopback-peered iBGP over a fast IGP, a redundant pair of route reflectors per region, BFD everywhere, policy expressed in communities — is the reference design that MPLS VPN backbones (over on the Service Provider shelf) inherit wholesale. Master it here, and VPNv4 is the same machine with longer addresses.