Day 38 — Route Reflectors: Clients, Non-Clients and Reflection Rules

1. Opening

Route reflection changes the iBGP propagation model so selected speakers can re-advertise iBGP-learned routes. That removes the universal full-mesh requirement, but it also means the engineer must understand client and non-client rules rather than treating the reflector as a transparent relay.

The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture.

Route Reflectors: Clients, Non-Clients and Reflection Rules

2. Concept and standards behavior

RFC 4456 defines route reflectors, clients, ORIGINATOR_ID and CLUSTER_LIST. In simplified terms, a route learned from an RR client may be reflected to other clients and non-clients; a route learned from a non-client is reflected to clients, but not to other non-clients. The RR still runs the BGP decision process—it does not blindly flood every path.

A recurring rule in this module is that configuration scale and routing-information scale are different problems. A design can be easy to configure but still create poor path visibility, slow convergence, or an oversized blast radius. Conversely, a topology can carry complete information but be operationally expensive to maintain.

3. Scenario

Use RR1 as route reflector with R1, R2 and R3 as clients, plus R4 as a non-client iBGP peer. Originate one prefix at R1 and another at R4, then trace which speakers receive each path.

Documentation-safe addressing is used. The common lab AS is 65010. Internal loopbacks use 192.0.2.0/24 host routes; external test prefixes use 203.0.113.0/24 and 198.51.100.0/24 where needed. All fictional failures are lab-only.

Success criteria

1. Every speaker learns the routes it is supposed to learn.
2. The propagation rule can be explained before commands are applied.
3. Loop-prevention attributes are visible where the feature uses them.
4. A negative test proves that an invalid or unintended propagation does not occur.
5. Rollback returns the topology to a known-good control-plane state.

4. Topology diagram

Route Reflectors: Clients, Non-Clients and Reflection Rules

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable IGP reachability among BGP loopbacks.
• Explicit update-source and appropriate neighbor reachability for loopback-based sessions.
• Authentication only if the lab image and design have been validated for it.
• Independent management access before changing route-reflection/confederation policy.
• Pre-change capture of BGP summary, selected paths and relevant neighbor state.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete device configuration.

router bgp 65010
 neighbor 192.0.2.11 remote-as 65010
 neighbor 192.0.2.12 remote-as 65010
 neighbor 192.0.2.13 remote-as 65010
 neighbor 192.0.2.14 remote-as 65010
 !
 address-family ipv4
  neighbor 192.0.2.11 route-reflector-client
  neighbor 192.0.2.12 route-reflector-client
  neighbor 192.0.2.13 route-reflector-client
 exit-address-family

Do not silently transfer this syntax to IOS XR or NX-OS. Those platforms must use their own policy/configuration model.

7. Verification before modification

Use a combination of topology, session and route evidence:

show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors
show ip route

For route-reflection topics also inspect the path detail for ORIGINATOR_ID and CLUSTER_LIST where present. The absence or presence of a route must be explained by the propagation rule, not guessed from neighbor state alone.

8. Controlled modification

Convert R3 from ordinary non-client to RR client and predict which reflected routes become newly visible to it. Verify path detail and reflected attributes.

Predict the exact peers whose Adj-RIB-In/Loc-RIB should change. Then apply one control-plane change, re-check path detail, and verify that no unrelated peer loses reachability.

9. Fault injection

Illustrative lab — not a real incident.

Misclassify two edge speakers as non-clients and assume the RR will reflect routes between them. Both sessions stay Established, yet route visibility is incomplete.

Capture the state before and after the fault. A useful fault must change one causal variable only.

10. Step-by-step troubleshooting

1. Confirm IGP reachability among BGP endpoints.
2. Confirm TCP/BGP sessions are Established.
3. Identify where the route originated.
4. Trace the route one BGP hop at a time.
5. Determine whether the receiving neighbor is eBGP, ordinary iBGP, RR client, RR non-client, or confederation peer.
6. Inspect best-path state before assuming propagation is broken.
7. Inspect ORIGINATOR_ID/CLUSTER_LIST for reflected routes.
8. Inspect policy and next-hop reachability.
9. Verify whether an alternative path was never learned, learned but not selected, or selected but not advertised.
10. Apply the smallest proven correction.
11. Re-run the same positive and negative tests.
12. Observe stability before closing the change.

11. Root cause and correction

The root cause is a wrong RR relationship, not a failed TCP/BGP session. Correct the intended client/non-client role and verify reflected route attributes.

The correction must address the architectural cause rather than adding random neighbor statements until the route appears.

12. Post-fix verification

Verify:

• all intended sessions remain Established;
• the expected prefix is learned by the intended speakers;
• reflected attributes are correct where applicable;
• next hop remains reachable;
• no routing loop is created;
• the negative propagation test still passes.

13. Rollback

Restore the previous neighbor relationship or policy, not an ad-hoc alternative. If the change affects route reflection, preserve enough connectivity that clients do not become isolated during rollback. Roll back for unexpected loss of route visibility, oscillation, unintended path change, or evidence that the design created a larger failure domain than approved.

14. Production lessons

Route reflectors reduce adjacency requirements by changing propagation semantics. Document client groups explicitly; an Established session alone does not prove the route will be reflected.

Deep-dive engineering notes

Reflection is selective propagation, not flooding

A route reflector still chooses BGP paths. It does not automatically copy every received path to every client. This distinction becomes crucial when several exits advertise the same NLRI. A client may receive only the reflector's selected view unless a separate path-diversity mechanism is used.

The client/non-client rules should be written into the design documentation. A route learned from a client can be reflected to clients and non-clients. A route learned from a non-client is reflected to clients but not to other non-clients. An engineer who treats all iBGP sessions attached to an RR as equivalent can create a topology where all sessions are Established yet some internal destinations disappear.

ORIGINATOR_ID and CLUSTER_LIST are diagnostic evidence

ORIGINATOR_ID identifies the BGP speaker that originally advertised a reflected route inside the AS. CLUSTER_LIST records clusters traversed by the reflected path and supports loop prevention. These fields are not decoration; they help prove that a route has been reflected and can explain why an RR rejects a path that appears to have returned through its own cluster.

When troubleshooting, compare two paths for the same prefix and explicitly inspect these attributes. If a path disappears after a cluster design change, the CLUSTER_LIST is often more useful than repeated show bgp summary output.

Next-hop behavior remains a separate problem

Route reflection changes iBGP advertisement rules but does not magically fix next-hop reachability. If a client receives a reflected route whose NEXT_HOP is unreachable, the control plane may show the route while the forwarding result remains broken or the path may not be usable. Maintain IGP reachability to relevant next hops and apply next-hop-self only where the design actually requires it.

Placement principle

Place reflectors for control-plane stability and topology awareness, not merely where configuration is convenient. A route reflector should not be forced through a fragile access failure domain just because it is physically near clients. Dedicated control-plane nodes, redundant transport, and consistent policy often matter more than raw hop count.

15. Knowledge check

1. Which problem in this post is a control-plane topology problem rather than a command-syntax problem?
2. What evidence distinguishes “route was never learned” from “route was learned but not selected”?
3. What negative test proves the scaling feature has not introduced unintended propagation?

Answers

1. The relationship among BGP speakers and the rules governing propagation.
2. Per-prefix BGP path detail and neighbor route evidence.
3. Verify a route that should remain hidden/unadvertised is absent from the relevant neighbor's learned/advertised state.

16. Sources

• RFC 4456 — BGP Route Reflection
• RFC 4271 — base BGP behavior
• Cisco IOS XE 17.18.x BGP configuration guide