BGP Route Reflectors (RRs) defined in RFC 1966 reduces the need for iBGP peers to be in a full mesh, by relaxing the standard rule where iBGP routes are not sent to iBGP peers.

A designated Route Reflector router treats all neighbour routers as one of 3 types, clients, non-clients and eBGP. The relaxed rules for Route Reflectors are;

• Updates received from a client are sent to all clients & non-clients
• Updates received from a non-client are sent only to clients
• Updates received from eBGP peers are sent to all clients & non-clients

A Route Reflector and its clients combine to form a Route Reflector cluster, a BGP design could have multiple clusters or a cluster with multiple Route Reflectors. If muliple clusters exist then one Route Reflector per cluster must be peered directly with a Route Reflector in another cluster, although usually the Route Reflectors from all clusters peer directly.

As one of the loop prevention rules of BGP has been removed (never send iBGP learned routes to iBGP peers) it is possible that loops could form. To prevent this BGP route reflectors only reflect the best routes, also there are 2 optional non-transitive BGP attributes which further prevent looping these are;

ORIGINATOR_ID, this is a 4 byte attribute which contains the Router ID of the first iBGP peer which originated the route into the AS. Route Reflectors never send an update to the router specified in the ORIGINATOR_ID

CLUSTER_LIST, is list of the cluster IDs which the update has been passed through, each Route Reflector will add its own cluster ID to the list before sending an update. If a Route Reflector sees its own cluster ID in the list it ignores the update.