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 [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 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 should be configured in order to provide redundancy.
RR servers propagate routes inside the AS based on the following rules:
- If a route is received from nonclient peer, reflect to clients only.
- If a route is received from a client peer, reflect to all nonclient peers and also to client peers, except the originator of the route.
- If a route is received from an EBGP peer, reflect to all client and nonclient peers.
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.
- Juniper tech note on differences between BGP route reflectors and confederations (log in required)
- BGP Route Reflector Basics
|This computer networking article is a stub. You can help Wikipedia by expanding it.|