What in this task tells us to use RR feature? Is it just to save in on peerings or does it have an actual function in this task?
I believe it is for full propogation of prefixes
Restriction: Do not enable iBGP peering between R3 and R6
R4 will propagate AS200 learned prefixes to R3 and R6
R3 is a RR client of R4 so R4 can reflect routes learned from BB1 via R6
R6 is a RR client of R4 so R4 can reflect routes learned from BB3 via R3
Restriction: Do not enable BGP on SW1 or SW4 but ensure that they can reach all BGP routes by using the default route advertised via OSPF by R1.
I would surmise then that all BGP prefixes have to be on R1, so it would be an ideal candidate to be a RR. So all devices would ideally peer with R1 accept for SW1 and SW4 whom should not run BGP.
R5 is a RR client of R1 so R1 can reflect routes learned from BB2 via SW2 and R2 routes.
R2 is a RR client of R1 so R1 can reflect routes learned from BB2 via SW2 and R5 routes.
Just my guess from first glance.
I read through the instructions too sloppy, got tired at end of session. It is clear to me now why R4 must be a RR. It also makes sense to make R1 a RR even though we could also have configured a full mesh.
Yes, the R1 scenario seems to be open to interpretation. Full Mesh seems to be viable alternative. I am studying BGP/MPLS test for CCIP, so BGP is fresh in my mind.
Thats true, full mesh is also an option for this task but to same good time, configuring RR is a better option.