What is an implication of using route reflectors in an iBGP topology?

Route reflection is specifically designed to scale iBGP to larger numbers of routers by eliminating the full-mesh peering requirement, so it imposes no limit on the total number of iBGP routers.

While BGP update propagation in an RR topology follows a hub-and-spoke model, actual traffic forwarding paths are determined by the routing table and are not constrained to flow hub-and-spoke.

BGP attribute manipulation via route-maps and policies is fully supported on all routers in an iBGP topology, not restricted to route reflectors.

Route reflectors include built-in loop-prevention mechanisms - the originator-id and cluster-list attributes - that prevent routing loops even when multiple route reflectors are deployed in the same topology.

A route reflector selects only the single best BGP path and reflects that one path to its clients, discarding all alternate equal-cost paths. Propagating multipath information across the topology requires enabling BGP Add-Path (RFC 7911) or similar extensions, which are not part of a standard RR deployment.