How Route-Reflector clusters prevent loops

This is the topology I used to get familiar with the concept:


The idea is fairly easy to understand. You never want to learn routes from someone who learned them from you (directly or indirectly). I made the peers one by one to step through the process.

Here is the route on R1:

R1#sho ip bgp 200.0.0.0
BGP routing table entry for 200.0.0.0/8, version 12
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
3
100, (Received from a RR-client)
6.6.6.6 (metric 2) from 6.6.6.6 (6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

Now on R2, we see the first case of the origintaor-id as set by R1. And we also see the beginning of the cluster-list:

R2#sho ip bgp 200.0.0.0
BGP routing table entry for 200.0.0.0/8, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
100
6.6.6.6 (metric 3) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 6.6.6.6, Cluster list: 1.1.1.1
R2#

R2 appends itself to the cluster-list before advertising to R5:

R5#sho ip bgp 200.0.0.0
BGP routing table entry for 200.0.0.0/8, version 12
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
100
6.6.6.6 (metric 2) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 6.6.6.6, Cluster list: 2.2.2.2, 1.1.1.1
R5#

Eventually, these are the messages we get on R6 and R2, respectively.

R6#
*Mar 1 00:44:55.807: BGP(0): 5.5.5.5 rcv UPDATE about 201.0.0.0/8 -- DENIED due to: ORIGINATOR is us;
*Mar 1 00:44:55.811: BGP(0): 5.5.5.5 rcv UPDATE about 200.0.0.0/8 -- DENIED due to: ORIGINATOR is us;

R2#
*Mar 1 00:53:39.075: BGP(0): 3.3.3.3 rcv UPDATE about 201.0.0.0/8 -- DENIED due to: CLUSTERLIST contains our own cluster ID;
*Mar 1 00:53:39.083: BGP(0): 3.3.3.3 rcv UPDATE about 200.0.0.0/8 -- DENIED due to: CLUSTERLIST contains our own cluster ID;