If you've ever wondered how a backbone ISP with hundreds of routers actually distributes BGP routes internally without melting, the answer is almost certainly route reflection. RFC 4456 is one of those quiet workhorses: nearly every tier-1 and tier-2 network on the planet runs it, and almost no application engineer has heard of it.

The problem. BGP has two flavors: external BGP (eBGP) between autonomous systems, and internal BGP (iBGP) within one AS. To prevent routing loops inside an AS, the original BGP-4 spec mandated that a router which learns a prefix via iBGP must not re-advertise it to another iBGP peer. The consequence is brutal: every iBGP speaker must peer directly with every other iBGP speaker. That's a full mesh of N(N-1)/2 sessions. At 100 routers, you need 4,950 TCP sessions. At 500, nearly 125,000. Operationally impossible.

The fix. Designate certain routers as route reflectors (RRs) and allow them to break the no-re-advertise rule under controlled conditions. Other routers become clients that peer only with their RR(s). The RR reflects routes between clients and to non-client iBGP peers. Suddenly your topology is a hub-and-spoke, and you scale linearly.

The clever bits. Loop prevention without AS-path (since iBGP doesn't prepend) required two new optional non-transitive attributes:

• ORIGINATOR_ID (type 9): the router-ID of the iBGP speaker that first injected the route into the local AS. If an RR sees its own ID here, it drops the route.
• CLUSTER_LIST (type 10): a sequence of cluster IDs that the route has traversed. Each RR prepends its CLUSTER_ID when reflecting; if an RR sees its own ID in the list, drop. This is essentially an AS-path equivalent for the reflector topology.

Reflection rules (memorize these — they show up in every CCIE/JNCIE exam and every real outage post-mortem):

• Route from a non-client iBGP peer → reflect to clients only.
• Route from a client → reflect to all clients (except the originator) and all non-client iBGP peers.
• Route from an eBGP peer → send to everyone, as normal.

Design tradeoffs. Route reflection is not free. It can hide diversity: an RR picks one best path and only reflects that one, so clients may not see alternate paths that would be useful for load balancing or fast reroute. This led to follow-ons like RFC 7911 (ADD-PATH) which lets BGP advertise multiple paths for the same prefix. Reflection can also cause persistent oscillations in pathological MED configurations — a problem analyzed extensively in RFC 3345.

Why it matters today. Every modern data-center fabric using BGP (Clos/leaf-spine designs from Facebook, Microsoft, and the Cumulus/SONiC ecosystems) inherits the reflection vocabulary, even when the alternative — eBGP with private ASNs per ToR — is chosen instead. MPLS L3VPNs (RFC 4364) layer on top of route reflection to scale VPNv4/VPNv6 distribution. SD-WAN controllers often act as route reflectors. If you've ever opened a Junos or IOS-XR config and seen cluster-id or route-reflector-client, you're looking at RFC 4456 in production.

History. The original RFC 1966 (1996) was authored by Tony Bates and Ravi Chandra at Cisco specifically because the NSF-funded commercial internet was about to outgrow the full-mesh constraint. The 2000 revision (RFC 2796) clarified attribute handling; the 2006 version (4456) tightened loop detection after operators kept finding edge cases. It's a rare example of an RFC that was iteratively hardened by real-world deployment bruises rather than committee theorizing.