What is the point of having the command <no bgp client-to-client reflection> and route reflection at all when ibgp clients in a cluster are fully meshed? If the RR is supposed to minimize the need for full mesh and the clients are fully meshed anyway why would route reflection be there in a fully meshed client setup? It is mentioned that the no client to client reflection is necessary if you want IBGP peering etc. so why not just turn off the rr functionality if the clients are already fully meshed?
It appears that there was a limitation in old IOS versions that affected combining peer groups and route reflector clients:
After scrolling a few pages down, you'll find this statement:
Important Note: This configuration does not use peer groups. Do not use peer groups if the clients inside a cluster do not have direct iBGP peers among one another and the clients exchange updates through the RR. If you configure peer groups, a potential withdrawal to the source of a route on the RR transmits to all clients inside the cluster. This transmission can cause problems.
The router subcommand bgp client-to-client reflection is enabled by default on the RR. If you turn off BGP client-to-client reflection on the RR and you make redundant BGP peering between the clients, you can safely use peer groups. Refer to Limitations of Peer Groups for more information.
Information about which versions were affected can be found here:
So the presence of the bgp client-to-client reflection appears to primarily address the issues when several RR clients are covered in a single peer group that should be solved in recent IOSes anyway.
Also, with RRs, there is a client-to-nonclient reflection performed by RRs that would not be affected by this command, but to be honest, I have not yet seen any persuasive scenario in which it would beneficial to deactivate the client-to-client reflection and still gain advantages of client-to-nonclient reflection.