Introduction to Route Reflection
Route reflection reduces the full‑mesh IBGP requirement by allowing a router (the route reflector, or RR) to redistribute IBGP‑learned routes to its clients. Two transitive BGP attributes—Originator ID and Cluster List—provide loop prevention in this hierarchy.
Originator ID Attribute
- Type: 9, length 4 octets
- Value: BGP Router ID of the router that originally injected the route into the AS
- Behavior: Copied by the RR from the peer that advertised the route (or the RR’s own Router ID if it originated the route).
- Purpose: If a router sees its own Router ID in the Originator ID field, it discards the update as a loop.
Cluster List Attribute
- Type: 10, variable length (4‑octet entries)
- Behavior: When an RR reflects a route, it prepends its own Cluster ID to the Cluster List. If the attribute already exists, the RR adds its ID to the front.
- Purpose: A router discards any reflected update whose Cluster List contains its own Cluster ID, preventing loops within or between clusters.
Route Reflection Behavior
Originator ID Impact
- Upon receipt of an IBGP update, the router checks the Originator ID.
- If it matches the local BGP Router ID, the update is ignored (treated as never received).
- Otherwise, the route proceeds to the normal BGP best‑path evaluation (weight, local‑pref, AS‑path, etc.).
Thus, a seemingly valid alternate path can be suppressed when the local router has already originated the route (e.g., a client mistakenly re‑advertises an RR‑learned route back to the RR).
Cluster List Impact
- After the Originator ID test, the router scans the Cluster List for an entry matching its own Cluster ID (configured via
bgp cluster-idor defaulted to the router‑ID). - A match causes the update to be discarded as a potential loop.
- If no match exists, the route is eligible for insertion into the BGP RIB and subsequent best‑path calculation.
Because each RR prepends its ID, a route that has traversed multiple RRs accumulates a list; any RR seeing its own ID anywhere in the list knows the route has already been reflected and must ignore it.
Interaction
- Originator ID and Cluster List are evaluated independently.
- Either a match results in immediate discard.
- Originator ID catches loops where a router re‑originates its own route.
- Cluster List catches loops involving multiple RRs within the same cluster or across clusters when Cluster IDs are not unique.
Troubleshooting Route Reflection Issues
Identifying Mismatches
Symptoms that often point to Originator ID or Cluster List problems:
- A route appears in the RIB of a non‑client router but is absent from the FIB of a client router, despite an active IBGP session to the RR.
show ip bgpshows the route with a*(not best) or>(best) flag, yet the client displays it as not installed due to a loop‑prevention drop.- RR logs may contain messages like
%BGP-5-ADJCHANGE: neighbor <ip> Downfollowed by%BGP-3-NOTIFICATION: sent to neighbor <ip> 3/0 (update malformed)when malformed Cluster Lists are detected (rare).
To confirm, inspect the attribute fields of the received update:
- Cisco IOS/XR:
show ip bgp <prefix> detail - Juniper Junos:
show route receive-protocol bgp <neighbor> <prefix> extensive
Look for originator-id: and cluster-list: entries.
Debugging with CLI Commands
| Vendor | Command | Purpose |
|---|---|---|
| Cisco IOS/XR | show ip bgp neighbors <ip> advertised-routes | See what the RR is advertising to a specific client (includes Originator ID and Cluster List). |
| Cisco IOS/XR | show ip bgp neighbors <ip> received-routes | View routes received from a client; useful to spot missing Originator ID or unexpected Cluster List. |
| Cisco IOS/XR | debug ip bgp updates | Real‑time view of BGP update generation; observe when Originator ID is set and when Cluster List is prepended. |
| Cisco IOS/XR | show ip bgp | Check overall BGP table; note routes marked * (not best) due to loop‑prevention. |
| Juniper Junos | show route advertising-protocol bgp <neighbor> | Displays routes the RR is sending to a neighbor, with attribute details. |
| Juniper Junos | show route receive-protocol bgp <neighbor> | Shows routes received from a neighbor; includes originator-id and cluster-list. |
| Juniper Junos | monitor traffic interface <if> matching "bgp" | Capture BGP packets to verify Cluster List length and content on the wire. |
| Juniper Junos | show bgp neighbor <ip> | Provides summary of session state and configured cluster-id. |
When debugging, capture a single update that is being dropped and compare its attribute fields against the local router’s Router ID and Cluster ID. A match indicates expected loop prevention; otherwise, investigate mis‑configuration (duplicate cluster IDs, incorrect router‑ID assignment, etc.).
Configuration Examples
Note: Originator ID is not directly configurable; it mirrors the BGP Router ID. To influence it, set the router‑ID appropriately. Cluster ID can be set explicitly or defaults to the router‑ID.
Cisco IOS/XR
Set Router ID (affects Originator ID)
router bgp 65000
bgp router-id 1.1.1.1
Configure Cluster ID
router bgp 65000
bgp cluster-id 10.0.0.1 ! Explicit 4‑byte Cluster ID
neighbor 10.0.0.2 route-reflector-client
neighbor 10.0.0.3 route-reflector-client
Juniper Junos
Set Router ID (affects Originator ID)
set routing-options router-id 1.1.1.1
set protocols bgp group internal type internal
set protocols bgp group internal local-address 10.0.0.1
set protocols bgp group internal neighbor 10.0.0.2
set protocols bgp group internal neighbor 10.0.0.3
Configure Cluster ID
set protocols bgp group internal cluster 10.0.0.1 ! 4‑byte Cluster ID
set protocols bgp group internal neighbor 10.0.0.2
set protocols bgp group internal neighbor 10.0.0.3
Scaling Limitations
Originator ID and Cluster List Limits
- Originator ID: Fixed 4‑octet size; no scaling impact beyond the router‑ID itself.
- Cluster List: Variable length; each entry consumes 4 octets. The BGP UPDATE message caps attribute length at 4096 octets (RFC 4271). In practice, a cluster list longer than ~100 entries (~400 bytes) is uncommon and may cause fragmentation or rejection by stricter implementations.
- Processing Overhead: Each RR must scan the entire Cluster List on every inbound update. With thousands of clients and deep hierarchies, this can become a CPU hotspot.
Scalability Considerations
- Cluster ID Uniqueness: Duplicate cluster IDs across different RRs cause false loop detection, leading to unnecessary path suppression.
- Client Fan‑out: A single RR serving hundreds of clients can become a bottleneck; consider a two‑tier route‑reflection design (cluster of RRs) to distribute load.
- Add‑Path Interaction: When using BGP Add‑Path, each path carries its own Originator ID and Cluster List; the RR must replicate the list for each path, increasing update size.
- Route‑Flap Dampening: Frequent changes in Originator ID (due to router‑ID changes) can trigger unnecessary withdrawals and re‑advertisements, amplifying churn.
- Memory: Storing multiple copies of the same route with different Cluster Lists (e.g., in a multi‑cluster design) increases RIB size proportionally to the number of distinct cluster‑list variations observed.
Advanced Route Reflection Scenarios
Multiple Originator IDs
When several routers within the same AS originate the same prefix (e.g., dual‑homed edge routers advertising a summary), each update carries a different Originator ID. The RR treats them as separate routes in the BGP table. The BGP best‑path algorithm selects among them using the usual criteria (weight, local‑pref, etc.). Originator ID does not influence selection; it serves only as a loop‑prevention token.
If the RR reflects both updates to a client, the client sees two IBGP entries for the same prefix, each with a distinct Originator ID. The client installs the best one per the standard decision process; the other remains as a non‑best (*) route.
Complex Cluster List Configurations
In designs employing confederations or multiple clustering tiers, a route may traverse several RRs, each belonging to a different confederation sub‑AS or cluster. The Cluster List becomes a stack:
[RR3-ClusterID][RR2-ClusterID][RR1-ClusterID] (most recent RR prepended)
A router discards the update if any entry matches its own Cluster ID, regardless of position. This enables hierarchical loop prevention: a route already reflected by a parent cluster will be rejected by a child cluster if the child’s ID appears anywhere in the list.
Cisco IOS/XR – Two‑Tier Route Reflection with Distinct Cluster IDs
! Top‑level RR (cluster-id 100.0.0.1)
router bgp 65000
bgp router-id 10.0.0.1
bgp cluster-id 100.0.0.1
neighbor 10.0.0.2 route-reflector-client ! client RR1
neighbor 10.0.0.3 route-reflector-client ! client RR2
! RR1 (cluster-id 100.0.0.2)
router bgp 65000
bgp router-id 10.0.0.2
bgp cluster-id 100.0.0.2
neighbor 10.0.0.4 route-reflector-client ! edge client
neighbor 10.0.0.1 route-reflector-client ! uplink to top‑level RR
! RR2 (cluster-id 100.0.0.3)
router bgp 65000
bgp router-id 10.0.0.3
bgp cluster-id 100.0.0.3
neighbor 10.0.0.5 route-reflector-client ! edge client
neighbor 10.0.0.1 route-reflector-client ! uplink to top‑level RR
Juniper Junos – Confederation with Multiple Clusters
set routing-options autonomous-system 65000 confederation members 65001 65002
set routing-options router-id 10.0.0.10
! Sub‑AS 65001 – RR with cluster-id 10.0.0.1
set protocols bgp group internal type internal
set protocols bgp group internal local-address 10.0.0.11
set protocols bgp group internal cluster 10.0.0.1
set protocols bgp group internal neighbor 10.0.0.12
set protocols bgp group internal neighbor 10.0.0.13
! Sub‑AS 65002 – RR with cluster-id 10.0.0.2
set protocols bgp group internal type internal
set protocols bgp group internal local-address 10.0.0.21
set protocols bgp group internal cluster 10.0.0.2
set protocols bgp group internal neighbor 10.0.0.22
set protocols bgp group internal neighbor 10.0.