Hello Joseph
You can configure each non-RR router to become neighbors with more than one RR. For example, you can configure R3 to be neighbors with RR2 and RR1, and configure both RR2 and RR1 to be RRs for that router. Routes will be shared among all those routers, and if one of the RRs fails, the other continues to share those routes.
It is always best practice to have more than one RR serving a subset of iBGP routers especially in larger AS’es, however, it should be implemented with care. One of the complications involved here is the use of the originator ID. You can find out a little more information about what this is in the Verification section of this lesson. When it comes to multiple RRs however, there are two approaches as far as the originator ID goes.
One is to set both RRs with the same originator ID. All RR’s will receive updates from clients and will reflect them to other RR’s. RR’s with the same cluster-ID will discard these updates, as the cluster-ID matches their own. This is a simple design but may result in sub-optimal routing in some cases.
The other option is to allocate a different cluster-ID to each route reflector. Each RR is in a different cluster, but this still mitigates the single point of failure. Rene writes a bit more about this detail here:
If you want to get really deep into this subject, take a look at this as well:
I hope this has been helpful!
Laz