Hello Rajeev,
yes
a RRS server when it receives an advertisement from one ot its client will:
reflect it to all other clients
propagate it to all non clients (normal iBGP neighbors)
this is the job of RRS: they help to reduce the complexity of iBGP.
RRS need to be fully meshed but each of them represent all its cluster :
cluster = RRS(s) + clients
Now that I can open the ppt:
be aware that ISP1 and ISP2 have the capability to advertise DC site routes to DR site even without the iBGP session between the two RRS.
You can verify this on your border routers with sh ip bgp
Usually in a L3 MPLS VPN provider the SP will change your private AS in its own to let you accept routes in another site
if you see net 10.10.10.0/24 with AS path
100 100 i
200 200 i
the PE node changes your private AS to the SP AS (so you see it twice).
if the service provider isn't overriding your AS you can use on all border routers:
neigh sp.ipaddr allowas-in 1
to accept the prefixes with AS path that contain your own AS (once)
the rib failure could be caused by this iBGP session over the tunnel that actually is not needed as I explained above.
From the point of view of each site the border routers have eBGP sessions with the SP routers and the RRS allows to reflect them.
On the eBGP sessions knowledge of the remote site subnets is received/can be received.
So I think that iBGP session over a tunnel RRS to RRS is not needed.
Hope to help
Giuseppe
