Short answer: BGP route reflectors let an iBGP speaker advertise routes learned from one iBGP peer to other iBGP peers, avoiding a full mesh. ORIGINATOR_ID and CLUSTER_LIST prevent reflected routes from looping back through their origin or a reflector cluster.[1]
Why route reflection exists
Traditional iBGP split-horizon rules prohibit advertising an iBGP-learned route to another iBGP peer. That avoids loops but a full mesh needs n(n−1)/2 sessions. Route reflection relaxes that rule under defined conditions, allowing scalable internal distribution.[1]
The two loop-prevention attributes
When a route reflector reflects a route, it sets ORIGINATOR_ID to the originating speaker's BGP identifier if absent, and prepends its cluster ID to CLUSTER_LIST. A router rejects a route whose ORIGINATOR_ID matches its own identifier; a reflector rejects a route whose CLUSTER_LIST contains its local cluster ID.[1]
These are optional, non-transitive attributes used within the AS. They complement—not replace—AS_PATH loop detection, which primarily protects inter-AS routing. A cluster ID should be unique per reflector cluster; deliberately shared IDs can represent a redundant cluster, but must be designed consistently.
Topology and route flow
- R1 learns a route from an external peer.
- R1 advertises it to its client RR1.
- RR1 reflects the route to eligible clients and non-client peers, recording originator and cluster path.
- Another reflector checks those attributes before accepting/reflection, preventing the route from circling indefinitely.
Configuration example (Cisco IOS-style)
router bgp 65010
bgp router-id 10.255.0.1
neighbor 10.0.0.2 remote-as 65010
neighbor 10.0.0.2 route-reflector-client
neighbor 10.0.0.3 remote-as 65010
neighbor 10.0.0.3 route-reflector-client
bgp cluster-id 10.255.0.1Mark only intended clients. A second RR can serve the same clients for resilience; define cluster IDs and client/non-client relationships deliberately. Syntax varies by platform. FRRouting documents route-reflector-client configuration in its BGP reference.[3]
Traffic engineering: what this does and does not control
Route reflection is a control-plane scaling mechanism, not a traffic-engineering attribute. It can indirectly affect which paths routers learn: a reflector's best-path selection and policies may hide alternate paths. That can influence outbound forwarding decisions within the AS. It does not directly choose an ISP's inbound path or force external networks to send traffic through a chosen ingress. Use LOCAL_PREF and policy for internal exit choice; use provider-supported communities, MED, or carefully evaluated AS_PATH prepending to influence external ingress.
Modern use
Large service-provider and enterprise WANs commonly use route reflectors to distribute IPv4/IPv6 unicast and VPN routes. Data-center fabrics may use BGP EVPN with leaf-spine or dedicated RR designs; ensure address-family, next-hop reachability, and path-diversity behavior are understood. In Cisco ACI-like fabrics, controller-managed policy and fabric topology change operational details; do not assume a generic IOS RR stanza maps directly to the fabric implementation.
Verification commands
show ip bgp neighbors 10.0.0.2
show ip bgp 203.0.113.0/24
show ip bgp regexp .*
show ip bgp summaryConfirm the peer is Established, the neighbor is configured as a client where intended, and the received route's attributes show the expected originator/cluster metadata when reflected. Exact display commands and whether attributes are shown by default vary by OS. Check the advertised-routes view on the receiver and compare route counts before/after policy changes.
Troubleshooting checklist
- Is the session Established and in the correct address family?
- Is the intended neighbor marked as an RR client?
- Does the RR actually select the route as best, or is policy suppressing it?
- Is the next hop reachable at the receiving router?
- Does ORIGINATOR_ID equal the receiving router ID, or does CLUSTER_LIST contain its cluster ID?
- Are multiple reflectors using inconsistent client/cluster design?
- Are add-path or diverse-path requirements being mistaken for ordinary reflection?
Interview answer
A route reflector reduces iBGP full-mesh requirements by reflecting selected iBGP routes to clients. ORIGINATOR_ID identifies the route's original speaker and CLUSTER_LIST records reflector clusters traversed; routers use them to reject reflected loops. Reflection scales control-plane distribution, but its best-path behavior can hide alternatives, so next-hop reachability and path diversity still need checking.
Related reading
See our RD vs RT guide and upcoming BGP best-path deep dive.
Sources: RFC 4456 defines route reflection and loop-prevention attributes.[1] Cisco and FRRouting documentation provide platform configuration context.[2][3]
Post a Comment