Route reflector
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
A route reflector (RR) is a network routing component. It offers an alternative to the logical full-mesh requirement of internal border gateway protocol (IBGP). A RR acts as a focal point[clarify] for IBGP sessions. The purpose of the RR is concentration. Multiple BGP routers can peer with a central point, the RR - acting as a route reflector server - rather than peer with every other router in a full mesh. All the other IBGP routers become route reflector clients.
This approach, similar to OSPF's DR/BDR feature, provides large networks with added IBGP scalability. In a fully meshed IBGP network of 10 routers, 90 individual CLI statements (spread throughout all routers in the topology) are needed just to define the remote-AS of each peer: this quickly becomes a headache to administer. A RR topology could cut these 90 statements down to 18, offering a viable solution for the larger networks administered by ISPs.
A route reflector is a single point of failure, therefore (at least) a second route reflector may be configured in order to provide redundancy. As it is an additional peer for the other 10 routers, it comes with the additional statement count to double that minus 2 of the single Route Reflector setup. An additional 11*2-2=20 statements in this case due to adding the additional Router. Additionally, in a BGP multipath Environment this also can benefit by adding local switching/Routing throughput if the RRs are acting as traditional Routers instead of just a dedicated Route Reflector Server role.
Rules
RR servers propagate routes inside the AS based on the following rules:
- If a route is received from a non-client peer, reflect to clients only and EBGP peers.
- If a route is received from a client peer, reflect to all non-client peers and also to client peers, except the originator of the route and reflect to EBGP peers.
- If a route is received from an EBGP peer, reflect to all client and non-client peers and other EBGP peers.
Cluster
RR and its clients form a "Cluster". The "Cluster-ID" is then attached to every route advertised by RR to its client or nonclient peers. Cluster-ID is an accumulative, non-transitive BGP attribute and every RR MUST prepend the local CLUSTER_ID to the CLUSTER_LIST in order to avoid routing loops.
See also
 | This computer networking article is a stub. You can help Wikipedia by expanding it. |