How Route Reflector Prevent Loops

As we all know, Route reflector always receives the routes from clients (iBGP) and non-clients (eBGP), and it reflects these routes to clients and non-clients.

Note: RR will reflect the routes to both clients and non-clients, if best route was received from clients. If route was received from non-client then it will be reflect to only clients.

As well as a router not receive the routes from a peer (neighbor) which peer received these routes from this router.

For example, Router A advertising X routes to router B and router B advertising same routes to router C and now router C adverting same routes back to router A. in this case router A will not receive these routes. This was example of indirect advertising. If router B will advertise the same routes to router A, it will be direct route advertising. In this case, Router A will behave the same and it will not accept the routes.

The most important things are cluster-list and originator-id which are used for loop prevention in RR environment.

Below is the topology which will be use to explain this topic:

RouterA#sh 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

Now RouterB, we can see first case of origintaor-id as set by RouterA. we can also see the beginning of the cluster-list:

RouterB#sh 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

RouterB appends itself to cluster-list before advertising it to RouterE:

RouterE#sh 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

Below are the messages we get on RouterF and RouterB.

RouterF#
*Jan 4 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;

RouterB#
*Jan 4 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;

RouterF is generating this message and rejecting the route because RouterE is advertising route to RouterF which was originated by RouterF itself.