BGP Route Reflector

What Is a Route Reflector?

A route reflector (RR) relaxes the iBGP full-mesh requirement and is defined in RFC 4456. iBGP has a split-horizon rule - a route learned from an iBGP peer is not advertised to another iBGP peer (iBGP and eBGP) - so every BGP router inside an AS has to peer with every other one (n × (n - 1) ÷ 2 sessions for n routers). An RR is granted an exception: it may reflect routes learned over iBGP to its other iBGP peers, so each router only needs a session with the RR (n - 1 sessions).

Terminology

Term	Meaning
Route reflector (RR)	The router that reflects routes. It carries the `route-reflector-client` configuration.
Client	An iBGP peer designated as a `route-reflector-client` by the RR. It only needs a session with the RR.
Non-client	An ordinary iBGP peer of the RR, not designated as a client. Non-clients must still be fully meshed with each other (RFC 4456 section 5).
Cluster	An RR together with its clients. It is identified by a cluster ID, which defaults to the BGP Router ID of the RR (RFC 4456 section 7).

Nothing is configured on the client side; only the RR designates its clients.

Reflection Rules

Whether the RR reflects a route to its other iBGP peers depends on where it received the route from (RFC 4456 section 6). Advertisements to eBGP peers are unchanged.

Received from	Reflected to other iBGP peers	Advertised to eBGP peers
Client	Reflected to both the other clients and the non-clients	Yes
Non-client	Reflected to the clients only (non-clients are expected to be fully meshed)	Yes
eBGP peer	Advertised to both clients and non-clients (the same as ordinary iBGP)	Yes

It follows that as long as at least one client remains, routes originated by that client keep reaching the non-clients.

Only the best path is reflected. RFC 4456 section 6 says the RR acts “after the best path is selected”, so even when a prefix has several paths, a client receives only one. To let clients learn about another exit inside the AS, use ADD-PATH, Best External or Diverse Path.

Some attributes must be left alone while reflecting. An RR SHOULD NOT modify NEXT_HOP, AS_PATH, LOCAL_PREF or MED (RFC 4456 section 10), so the contents of the route reach the client unchanged. An RR may also have other RRs as its own clients, which allows nested clusters, that is a hierarchy (RFC 4456 section 6). Redundant and hierarchical designs are covered in a separate article.

Two Attributes That Prevent Loops

Relaxing split horizon makes it possible for a route to circulate inside a cluster, so RFC 4456 section 8 adds two path attributes. Both are optional non-transitive and never leave the AS.

Attribute	Type code	Contents
`ORIGINATOR_ID`	9	The BGP Router ID of the router that originated the route in the local AS. The RR creates it when reflecting, and does not create a new one if the attribute already exists. A router that receives a route carrying its own Router ID SHOULD ignore that route.
`CLUSTER_LIST`	10	The list of cluster IDs the route has passed through. A reflecting RR MUST prepend its own cluster ID. An RR that finds its own cluster ID in the list SHOULD ignore the advertisement.

The two attributes also affect best-path selection (RFC 4456 section 9). For a route carrying ORIGINATOR_ID, that value is treated as the Router ID of the advertising speaker in the tie-breaking step, and a route with a shorter CLUSTER_LIST is preferred (a route without the attribute has length zero).

Configuration

On IOS XR, route-reflector-client goes under the address family of the neighbor that becomes a client.

IOS XR route reflector configuration (on the RR)
router bgp <AS number>
 neighbor <client address>
  address-family ipv4 unicast
   route-reflector-client

The cluster ID defaults to the BGP Router ID. When several RRs share one cluster for redundancy, bgp cluster-id makes them match.

IOS XR cluster ID configuration
router bgp <AS number>
 bgp cluster-id <cluster ID>

Verification on Real Devices

Five XRd 26.1.1 routers: R2 in AS 65001 becomes the RR, with R1 and R3 as its clients. There is no iBGP session between R1 and R3.

Router	AS	Role	Advertised network
R1	65001	RR client	192.168.1.0/24
R2	65001	Route reflector	192.168.2.0/24
R3	65001	RR client (eBGP with AS 65002)	192.168.3.0/24
R4	65002	-	192.168.4.0/24
R5	65003	-	192.168.5.0/24

AS 65001 runs OSPF area 0 and the iBGP sessions are between Loopback0s. R3 advertises 10.3.4.0/24 as an OSPF passive interface so that R1 can reach the NEXT_HOP of the reflected routes. The inbound and outbound route policies are named per neighbor (each containing only pass), so the two clients land in separate update groups. Only R2 is changed.

STEP	Change on R2	What to check
0	None (no RR)	Split horizon keeps R3’s routes from reaching R1
1	Designate R1 and R3 as `route-reflector-client`	Reflection starts and `ORIGINATOR_ID` / `CLUSTER_LIST` are attached
2	`bgp cluster-id 10.100.100.1`	`CLUSTER_LIST` follows the cluster ID
3	Apply the same policy names to both clients	The update groups merge, so the originating client receives the same UPDATE. The receiver does not accept it, because of `ORIGINATOR_ID`
4	Restore the per-neighbor policy names	The update groups split again and the advertisement back to the originator stops
5	Remove `route-reflector-client` from R1 only	Even with R1 as a non-client, routes from the client keep arriving
6	Remove `route-reflector-client` from R3 as well (final state)	Reflection stops; a cluster ID alone reflects nothing

In every STEP R1 sends 50 pings each to 192.168.3.1, 192.168.4.1 and 192.168.5.1, and R3 and R5 send 50 pings to 192.168.1.0/24.

STEP 0: No Route Reflector

R1’s BGP table holds only its own 192.168.1.0/24 and R2’s own 192.168.2.0/24. The three routes R3 has are not there.

R1 show bgp (STEP 0)
RP/0/RP0/CPU0:R1#show bgp
Wed Sep 23 03:07:50.544 UTC
BGP router identifier 10.0.0.1, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 4
BGP main routing table version 4
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     0.0.0.0                  0         32768 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i

Processed 2 prefixes, 2 paths

R2 holds all five routes, but the ones received from R3 show Not advertised to any peer, and the only route advertised to R1 is R2’s own 192.168.2.0/24.

R2 show bgp 192.168.3.0/24 (STEP 0)
RP/0/RP0/CPU0:R2#show bgp 192.168.3.0/24
Wed Sep 23 03:08:36.914 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  9            9
Last Modified: Sep 23 02:58:15.023 for 00:10:22
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received & used)
    10.0.0.3 (metric 2) from 10.0.0.3 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 9

R2 show bgp neighbors 10.0.0.1 advertised-routes (STEP 0)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.0.1 advertised-routes
Wed Sep 23 03:08:39.145 UTC
Network            Next Hop        From            AS Path
192.168.2.0/24     10.0.0.2        Local           i

Processed 1 prefixes, 1 paths

R1 cannot forward to the external destinations, and R3 and R5 cannot reach 192.168.1.0/24. This is iBGP split horizon.

R1 ping 192.168.3.1 / 192.168.5.1 (STEP 0)
RP/0/RP0/CPU0:R1#ping 192.168.3.1 source 192.168.1.1 count 50 timeout 1
Wed Sep 23 03:05:08.376 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.3.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)
RP/0/RP0/CPU0:R1#ping 192.168.5.1 source 192.168.1.1 count 50 timeout 1
Wed Sep 23 03:06:51.266 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.5.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

R3 ping 192.168.1.1 (STEP 0)
RP/0/RP0/CPU0:R3#ping 192.168.1.1 source 192.168.3.1 count 50 timeout 1
Wed Sep 23 03:09:17.697 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.1.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

STEP 1: Making R2 a Route Reflector

Both R1 and R3 are designated as route-reflector-client. The commit tears down and re-establishes both sessions, and the reason is logged as RR client configuration changed.

R2 route reflector configuration (STEP 1, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 23 03:13:14.389 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 neighbor 10.0.0.1
  address-family ipv4 unicast
   route-reflector-client
  !
 !
 neighbor 10.0.0.3
  address-family ipv4 unicast
   route-reflector-client
  !
 !
!
end

R2 show logging (STEP 1, ADJCHANGE only)
RP/0/RP0/CPU0:R2#show logging start Sep 23 03:08:59
<snip>
RP/0/RP0/CPU0:Sep 23 03:13:15.502 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.1 Down - RR client configuration changed (VRF: default) (AS: 65001) 
RP/0/RP0/CPU0:Sep 23 03:13:15.502 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.3 Down - RR client configuration changed (VRF: default) (AS: 65001) 
RP/0/RP0/CPU0:Sep 23 03:13:20.185 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.3 Up (VRF: default) (AS: 65001) 
RP/0/RP0/CPU0:Sep 23 03:13:20.361 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.1 Up (VRF: default) (AS: 65001) 

Adding or removing route-reflector-client resets the session, so on a production network do it in a maintenance window.

R1’s BGP table grows to five routes, and the reflected routes carry Originator and Cluster list. Against from 10.0.0.2 (received from R2), the Router ID in parentheses is 10.0.0.3 (R3), and Cluster list is R2’s Router ID 10.0.0.2.

R1 show bgp (STEP 1)
RP/0/RP0/CPU0:R1#show bgp
Wed Sep 23 03:15:32.621 UTC
BGP router identifier 10.0.0.1, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 9
BGP main routing table version 9
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     0.0.0.0                  0         32768 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
*>i192.168.4.0/24     10.3.4.4                 0    100      0 65002 i
*>i192.168.5.0/24     10.3.4.4                      100      0 65002 65003 i

Processed 5 prefixes, 5 paths

R1 show bgp 192.168.3.0/24 (STEP 1)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
Wed Sep 23 03:15:33.871 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  6            6
Last Modified: Sep 23 03:13:20.023 for 00:02:13
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received & used)
    10.0.0.3 (metric 3) from 10.0.0.2 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 6
      Originator: 10.0.0.3, Cluster list: 10.0.0.2

On R2 the route received from a client is marked (Received from a RR-client) and R1 appears as an advertisement target. The neighbor detail shows Cluster ID (the Router ID 10.0.0.2, since none is configured) and Route-Reflector Client.

R2 show bgp 192.168.3.0/24 (STEP 1)
RP/0/RP0/CPU0:R2#show bgp 192.168.3.0/24
Wed Sep 23 03:16:17.520 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 16           16
Last Modified: Sep 23 03:13:20.023 for 00:02:57
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.0.0.1        
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.0.0.1        
  Local, (Received from a RR-client), (received & used)
    10.0.0.3 (metric 2) from 10.0.0.3 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 16

R2 show bgp neighbors (STEP 1, the 10.0.0.1 part)
BGP neighbor is 10.0.0.1
 Remote AS 65001, local AS 65001, internal link
<snip>
 Cluster ID 10.0.0.2
  BGP state = Established, up for 00:02:58
<snip>
  Update group: 0.2 Filter-group: 0.4  No Refresh request being processed
  Route-Reflector Client
<snip>
  Prefix advertised 4, suppressed 0, withdrawn 0

No.22 of the R1 - R2 capture is a TCP segment carrying the UPDATEs for the four reflected routes. The one for 192.168.3.0/24 carries CLUSTER_LIST and ORIGINATOR_ID, and Next hop is still R3’s 10.0.0.3.

STEP 1 R1 - R2 No.22 UPDATE (R2 to R1, 192.168.3.0/24) tshark -V (excerpt)
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.0.0.3
                IPv4 Address: 10.0.0.3
<snip>
                192.168.3.0/24
<snip>
        Path Attribute - ORIGIN: IGP
<snip>
        Path Attribute - AS_PATH: empty
<snip>
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
        Path Attribute - LOCAL_PREF: 100
<snip>
        Path Attribute - CLUSTER_LIST: 10.0.0.2
<snip>
                Cluster ID: 10.0.0.2
        Path Attribute - ORIGINATOR_ID: 10.0.0.3 
<snip>
            Originator identifier: 10.0.0.3

Download the pcap of the packet in the tshark output above (STEP 1 No.22 UPDATE)

In the extracted file this packet appears as No.1. All pings from R1, R3 and R5 now succeed.

STEP 2: Setting an Explicit Cluster ID

A cluster ID other than the default (the Router ID) is configured. This change also resets the sessions, with the reason Neighbor moved to a new cluster.

R2 cluster ID configuration (STEP 2, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 23 03:19:20.194 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 bgp cluster-id 10.100.100.1
!
end

R2 show logging (STEP 2, ADJCHANGE only)
RP/0/RP0/CPU0:R2#show logging start Sep 23 03:16:40
<snip>
RP/0/RP0/CPU0:Sep 23 03:19:21.474 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.3 Down - Neighbor moved to a new cluster (VRF: default) (AS: 65001) 
RP/0/RP0/CPU0:Sep 23 03:19:21.474 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.1 Down - Neighbor moved to a new cluster (VRF: default) (AS: 65001) 
RP/0/RP0/CPU0:Sep 23 03:19:26.180 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.1 Up (VRF: default) (AS: 65001) 
RP/0/RP0/CPU0:Sep 23 03:19:26.438 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.3 Up (VRF: default) (AS: 65001) 

The Cluster list of the route R1 receives changes to 10.100.100.1, while Originator stays the same.

R1 show bgp 192.168.3.0/24 (STEP 2)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
Wed Sep 23 03:21:39.805 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 15           15
Last Modified: Sep 23 03:19:26.023 for 00:02:13
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received & used)
    10.0.0.3 (metric 3) from 10.0.0.2 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 15
      Originator: 10.0.0.3, Cluster list: 10.100.100.1

STEP 3: Merging the Update Groups

How an implementation handles “reflect to the client peers as well” from RFC 4456 section 6 is decided on IOS XR by the update group layout. Here the same policy names are applied to both clients so that they share one update group.

R2 the same policy on both clients (STEP 3, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 23 03:25:26.301 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-BOTH
  pass
end-policy
!
route-policy FROM-BOTH
  pass
end-policy
!
router bgp 65001
 neighbor 10.0.0.1
  address-family ipv4 unicast
   route-policy FROM-BOTH in
   route-policy TO-BOTH out
  !
 !
 neighbor 10.0.0.3
  address-family ipv4 unicast
   route-policy FROM-BOTH in
   route-policy TO-BOTH out
  !
 !
!
end

R1 and R3 end up in the same group (index 0.1), and the number of routes R2 advertises to R1 grows to five. The extra one is From 10.0.0.1, that is 192.168.1.0/24 advertised by R1 itself. Only policy names changed, so the sessions were not reset.

R2 show bgp update-group (STEP 3, excerpt)
Update group for IPv4 Unicast, index 0.1:
<snip>
    Route Reflector Client
<snip>
      10.0.0.1                  10.0.0.3                  

R2 show bgp neighbors 10.0.0.1 advertised-routes (STEP 3)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.0.1 advertised-routes
Wed Sep 23 03:28:32.918 UTC
Network            Next Hop        From            AS Path
192.168.1.0/24     10.0.0.2        10.0.0.1        i
192.168.2.0/24     10.0.0.2        Local           i
192.168.3.0/24     10.0.0.3        10.0.0.3        i
192.168.4.0/24     10.3.4.4        10.0.0.3        65002i
192.168.5.0/24     10.3.4.4        10.0.0.3        65002 65003i

Processed 5 prefixes, 5 paths

No.7 of the capture holds that UPDATE. Its ORIGINATOR_ID is 10.0.0.1, the Router ID of the receiving router R1 itself.

STEP 3 R1 - R2 No.7 UPDATE (R2 to R1, 192.168.1.0/24) tshark -V (excerpt)
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.0.0.1
                IPv4 Address: 10.0.0.1
<snip>
                192.168.1.0/24
<snip>
        Path Attribute - ORIGIN: IGP
<snip>
        Path Attribute - AS_PATH: empty
<snip>
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
        Path Attribute - LOCAL_PREF: 100
<snip>
        Path Attribute - CLUSTER_LIST: 10.100.100.1
<snip>
                Cluster ID: 10.100.100.1
        Path Attribute - ORIGINATOR_ID: 10.0.0.1 
<snip>
            Originator identifier: 10.0.0.1

Download the pcap of the packet in the tshark output above (STEP 3 No.7 UPDATE)

R1’s BGP table still shows 1 available with only the local path. The rule that a route whose ORIGINATOR_ID matches the receiver’s own Router ID is ignored (RFC 4456 section 8) is at work.

R1 show bgp 192.168.1.0/24 (STEP 3)
RP/0/RP0/CPU0:R1#show bgp 192.168.1.0/24
Wed Sep 23 03:27:44.660 UTC
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  3            3
Last Modified: Sep 23 02:58:09.023 for 00:29:35
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.0.0.2        
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.0.0.2        
  Local
    0.0.0.0 from 0.0.0.0 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, local, best, group-best
      Received Path ID 0, Local Path ID 1, version 3

STEP 4: Restoring the Per-Neighbor Policy Names

With the policy names separated again, the update groups split and R2 advertises four routes to R1. Whether the originating client receives the same UPDATE is decided by the update group layout, not by the reflection rules.

R2 back to per-neighbor policies (STEP 4, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 23 03:31:27.008 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 neighbor 10.0.0.1
  address-family ipv4 unicast
   route-policy FROM-R1 in
   route-policy TO-R1 out
  !
 !
 neighbor 10.0.0.3
  address-family ipv4 unicast
   route-policy FROM-R3 in
   route-policy TO-R3 out
  !
 !
!
end

R2 show bgp neighbors 10.0.0.1 advertised-routes (STEP 4)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.0.1 advertised-routes
Wed Sep 23 03:34:33.166 UTC
Network            Next Hop        From            AS Path
192.168.2.0/24     10.0.0.2        Local           i
192.168.3.0/24     10.0.0.3        10.0.0.3        i
192.168.4.0/24     10.3.4.4        10.0.0.3        65002i
192.168.5.0/24     10.3.4.4        10.0.0.3        65002 65003i

Processed 4 prefixes, 4 paths

STEP 5: Turning R1 into a Non-Client

Only R1’s route-reflector-client is removed. R1 becomes an ordinary iBGP peer of the RR (a non-client), and Route-Reflector Client disappears from the neighbor detail.

R2 removing R1 as a client (STEP 5, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 23 03:37:31.176 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 neighbor 10.0.0.1
  address-family ipv4 unicast
   no route-reflector-client
  !
 !
!
end

R2 show bgp neighbors (STEP 5, the 10.0.0.1 part)
BGP neighbor is 10.0.0.1
 Remote AS 65001, local AS 65001, internal link
<snip>
  BGP state = Established, up for 00:03:00
<snip>
  Update group: 0.1 Filter-group: 0.3  No Refresh request being processed
<snip>
  Prefix advertised 4, suppressed 0, withdrawn 0

Routes originated by the client R3 keep being reflected to the non-client R1, and the route originated by the non-client R1 still reaches the client R3. Both carry Originator and Cluster list.

R1 show bgp 192.168.3.0/24 (STEP 5)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
Wed Sep 23 03:39:51.264 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 22           22
Last Modified: Sep 23 03:37:37.023 for 00:02:14
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received & used)
    10.0.0.3 (metric 3) from 10.0.0.2 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 22
      Originator: 10.0.0.3, Cluster list: 10.100.100.1

R3 show bgp 192.168.1.0/24 (STEP 5)
RP/0/RP0/CPU0:R3#show bgp 192.168.1.0/24
Wed Sep 23 03:41:26.354 UTC
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 15           15
Last Modified: Sep 23 03:37:37.023 for 00:03:49
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.3.4.4        
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.3.4.4        
  Local, (received & used)
    10.0.0.1 (metric 3) from 10.0.0.2 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 15
      Originator: 10.0.0.1, Cluster list: 10.100.100.1

The pings keep getting through.

R3 ping / traceroute 192.168.1.1 (STEP 5)
RP/0/RP0/CPU0:R3#ping 192.168.1.1 source 192.168.3.1 count 50 timeout 1
Wed Sep 23 03:41:16.418 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.1.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 6/9/59 ms
RP/0/RP0/CPU0:R3#traceroute 192.168.1.1 source 192.168.3.1 probe 3 timeout 1 maxttl 6
Wed Sep 23 03:41:18.058 UTC

Type escape sequence to abort.
Tracing the route to 192.168.1.1

 1  10.2.3.2 52 msec  5 msec  5 msec 
 2  10.1.2.1 9 msec  *  10 msec 

STEP 6: Removing Every Client Designation (Final State)

Removing route-reflector-client from R3 as well stops the reflection, and R1’s BGP table is back to two routes. bgp cluster-id is left in place: with no clients at all, a cluster ID alone reflects nothing.

R2 removing R3 as a client (STEP 6, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 23 03:43:35.519 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 neighbor 10.0.0.3
  address-family ipv4 unicast
   no route-reflector-client
  !
 !
!
end

R1 show bgp (STEP 6)
RP/0/RP0/CPU0:R1#show bgp
Wed Sep 23 03:48:21.902 UTC
BGP router identifier 10.0.0.1, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 28
BGP main routing table version 28
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     0.0.0.0                  0         32768 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i

Processed 2 prefixes, 2 paths

R1 ping 192.168.5.1 (STEP 6)
RP/0/RP0/CPU0:R1#ping 192.168.5.1 source 192.168.1.1 count 50 timeout 1
Wed Sep 23 03:47:22.970 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.5.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

Verification Configs and show Output

Each STEP captures the following files from all five routers, one file per router and kind. The verification config is the ..._run.txt (final state: STEP 6).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show bgp` / `show bgp summary` / `show route bgp` / `show bgp <prefix>` (five prefixes) / `show bgp neighbors` / per-peer `advertised-routes`, `routes` and `received routes` / `show bgp update-group` / `show bgp process` / `show rpl route-policy`. R1 to R3 also include `show ospf neighbor` / `show route ospf`
`..._log.txt`	`show logging` limited to that STEP: a `logmsg` marker was placed at the start of each STEP and its time passed to `show logging start`
`..._run.txt`	`show running-config` at that STEP (the verification config for that STEP)
`..._ping.txt`	`ping` (50 packets) and `traceroute`: R1 to `192.168.3.1`, `192.168.4.1` and `192.168.5.1`, R3 and R5 to `192.168.1.1`
`..._trace.txt`	`show bgp trace neighbor` and `show bgp trace error` (events inside the BGP process)
`..._commit.cfg`	The configuration actually committed in that STEP (R2 only)

STEP 0: no route reflector

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	—	trace	—
R5	show	log	run	ping	trace	—

STEP 1: designate R1 and R3 as route-reflector-client

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	—	trace	—
R5	show	log	run	ping	trace	—

STEP 2: add bgp cluster-id 10.100.100.1

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	—	trace	—
R5	show	log	run	ping	trace	—

STEP 3: apply the same policy names to both clients

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	—	trace	—
R5	show	log	run	ping	trace	—

STEP 4: restore the per-neighbor policy names

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	—	trace	—
R5	show	log	run	ping	trace	—

STEP 5: remove route-reflector-client from R1

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	—	trace	—
R5	show	log	run	ping	trace	—

STEP 6: remove route-reflector-client from R3 (final state)

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	—	trace	—
R5	show	log	run	ping	trace	—

Packet captures were taken per STEP.

STEP	R1 - R2	R2 - R3
0	pcap	pcap
1	pcap	pcap
2	pcap	pcap
3	pcap	pcap
4	pcap	pcap
5	pcap	pcap
6	pcap	pcap

References

Source	Title	Summary
RFC 4456	BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)	Defines the route reflector: section 5 the terminology, 6 the reflection rules, 7 redundant RRs and cluster IDs, 8 `ORIGINATOR_ID` / `CLUSTER_LIST`, 9 the impact on route selection and 10 the attributes an RR leaves alone.
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	The BGP-4 base specification. Section 9.2 defines iBGP split horizon.
IANA	Border Gateway Protocol (BGP) Parameters	Registry of numbers used in BGP, including path attribute type codes.