Purpose

1. The purpose is to reduce the number of iBGP peers
2. Advantage over confederation is route reflector can be implemented in stages, where else confederation is an all or no.
3. only the router reflector needs to be configured, the other BGP routers remain the same, no changes are needed
4. route reflector essentially breaks the regular rule of BGP or not to re-advertise prefixes that are received from an iBGP peer to another iBGP peer. A route reflector’s job is to reflect iBGP prefixes to another iBGP peers
5. It is best to follow the physical topology when placing route reflector on the network. it is common for route reflectors to be the aggregation routers in a network, or on the core router in a POP. This is to avoid suboptimal routing black holing and routing loops. The reason is because having the RR follow the physcial topology guarantee that the packet forwarding won’t be affected. However if you run MPLS, RR should be out of the packet forwarding path.
6. To increase fault tolerant, implement two route reflectors per cluster
7. To reduce the total number of iBGP sessions, we can use a RR. So instead of n*(n-1)/2 sessions, we will have only n session. However the RR becomes a single point of failure. So we always want at lease two RR on a network. So at minimum, the total number of iBGP sessions are 2n.
8. Any Router can peer eBGP in a RR network. RR clients, non-client and the RR can peer eBGP with another AS

Hierarchical RR

1. You can have hierarchical model where a route reflector is a client for another route reflector, however remember each RR introuduce delay in route update, and thus increase convergence time

Cluster

1. A cluster is defined a its RR and the RR clients
2. Client can peer with RRs in multiple clusters
3. It is highly recommended to have only ONE RR per cluster. RR client get redundancy by peering with two clusters.
4. Use same cluster ID to reduce memory and processing on RR (RR does not send updates to another RR with the same cluster ID)
5. Use different cluster ID to have more redundant paths on the RR

In MPLS network

1. it is best to have RR outside of the packet forwarding path, to improve packet forwarding performance, for better scalability, and troubleshooting.
2. PE rejects vpnv4 prefixes when there is not VRF that needs to import the prefixes. RR however accepts all vpnv4 prefixes, and reflect them.
3. Normally, full meshed among all PE are required in a MPLS L3 VPN network. That means the total peer sessions are n*(n-1)/2.
4. We should distribute load on RRs by configuring the RRs to reflect selected vpnv4 prefixes only using RT. For example one RR only reflects odd RT, and the second RR only reflects even RT.
5. Outbound Route FIlter (ORF) is a feature that allow a iBGP peer to inform its peer NOT to selected prefixes. It can be used on PE as well as RR to reduce prefixes update.

Multipath

1. When RR is used, only the best path is sent it its client, as a result, only one path is kept for each prefix at the PE.

Why do we need multipath?

1. we need multiple path on PE for Fast Convergence
2. multipath also enable load balancing (ECMP)
3. since RR hide some paths, it could cause Prefix Oscillation due to comparison of paths based on MED
4. Host Potato Routing means Optimal Exit route. Optimal route is not always known on the PE in a RR environment (because the best path is from the RR perspective, not from the PE perspective)

Solutions to enable multipath

1. Use unique RD per VRF per PE in VPNv4 network
2. Shadow Route Reflector:
   1. add a RR and tell the RR to advertise the SECOND best path instead of the Best Path.
   2. Only the shadow RR needs to support this feature. (make sure the shadow RR select the same BEST and SECOND BEST PATH as the primary RR).
   3. There is an option to create another iBGP session on the primary RR and configure 2nd best path on the new iBGP peer
3. BGP Add-Path Feature (http://tools.ietf.org/html/draft-ietf-idr-add-paths-09)
   1. Robert Raszuk from Cisco has an excellent Nanog presentation when to use or not to use Add-Path