BGP Route Reflectors

NB; All Route Reflectors must be clients of each other so they replicate

1) Routes from a nonclient peer—Reflects to all the clients within the cluster.
2) Routes from a client peer—Reflects to all the nonclient peers and also to the client peers.
3) Routes from an eBGP peer—Sends the update to all client and nonclient peers.

neighbor route-reflector-client

The router with this command is the RR, and the neighbors at which the command points are the clients of that RR. The combination of the RR and the clients is a "cluster".

An AS can have more than one RR (more than one cluster, e.g. large AS with RR's in different countries). In this situation, an RR treats other RRs just like any other iBGP speaker.

Other RRs can belong to the same cluster (client group) or to other clusters. In a simple configuration, you can divide the AS into multiple clusters. You configure each RR with other RRs as nonclient peers in a fully meshed topology (when each RR is in its own cluster). Clients should never peer with iBGP speakers outside the client cluster.


The RR scheme has a few methods to avoid loops:
1) 'originator-id' - This is an optional, nontransitive BGP attribute that is 4 bytes long. An RR creates this attribute. The attribute carries the router ID (RID) for the originator of the prefix in the local AS. If, due to poor configuration, the routing information comes back to the originator, the information is ignored.
2) 'cluster-list' - A single cluster can have more than one RR. You need to configure all RRs in the same cluster with a 4-byte cluster ID so that an RR can recognize updates from other RRs in the same cluster.

If a cluster of clients has a single RR. In this case, the router ID of the RR identifies the cluster.

A cluster list is a sequence of cluster IDs that the route has passed. When an RR reflects a route from the RR clients to nonclients outside of the cluster, the RR appends the local cluster ID to the cluster list. If this update has an empty cluster list, the RR creates one. With this attribute, an RR can identify if the routing information has looped back to the same cluster due to poor configuration. If the local cluster ID is found in the cluster list, the advertisement is ignored.


Important Note: This configuration does not use peer groups. Do not use peer groups if all the clients inside a do not have direct iBGP peers among one another, and the clients only  exchange updates through the RR. If you configure peer groups, a potential withdrawal of the source of a route on the RR transmits to all clients inside the cluster. This transmission can cause problems. I.e. withdrawals are tracked at the peer group level, and not per peer.

The router subcommand bgp client-to-client reflection is enabled by default on the RR. If you turn off BGP client-to-client reflection on the RR and you make redundant BGP peering between the clients, you can safely use peer groups. Refer to Limitations of Peer Groups for more information.

RR Node;

interface loop1

ip add 10.10.10.10 255.255.255.255

router bgp 60868

template peer-session RR

  remote-as 64512

  update-source loop1

template peer-policy RR

  route-reflector-client

neighbour 1.1.1.1 inherit peer-session RR

address-family ipv4

  neighbor 1.1.1.1 activate

  neighbor 1.1.1.1 inherit peer-policy

neighbour 10.10.10.12 inherit peer-session RR

address-family ipv4

  neighbor 10.10.10.12 activate

  neighbor 10.10.10.12 inherit peer-policy

The configuration on the BGP Client peer is exactly the same as if it was a normal full mesh peer. The Route-Reflector-Client command is all that is required to change the rules of operations and implement the Reflector function, and all that comes with it.

To be finished..