Reflect according to the source peer’s role

Select the best path before applying the reflection rules.

• An RR divides internal peers into client and non-client groups. The RR and its clients form a cluster. Clients need not be fully meshed. In the simple depicted setup, the non-client speakers and RR retain the necessary full-mesh peering among that group (§§5–6). A client is a BGP role, not a web browser or an application user.
• After selecting its best path, an RR reflects a route learned from a non-client IBGP peer to the clients. It does not use that rule to reflect from one non-client to another. The diagram shows N1’s selected route reaching C1 and C2, with the N2 branch stopped; N1 and N2 have their own session (§6).
• A best path learned from a client is reflected to non-client peers and client peers. The worked picture shows C1’s route reaching C2, N1 and N2. A same-session return to the source is omitted from the picture/model; this omission is not a new MUST NOT rule or a substitute for the loop attributes (§§6,8).
• Only the RR’s selected best path is reflected in this base mechanism. Receiving an alternative path is not enough to advertise every alternative. The selected local-preference example assumes other relevant eligibility conditions equal; the RR prefers 200 over 100, so the lower-preference route is not reflected (§§6,11; RFC 4271 §§5.1.5,9.1).
• Another RR can be configured as a client or non-client; “is a reflector” does not alone decide its role relative to this RR. Conventional BGP speakers can participate as clients without understanding a special client-identification message (§6).