Route reflection

In a standard BGP configuration, all BGP speakers within an AS must have full BGP mesh to ensure that all externally learned routes are redistributed through the entire AS. iBGP speakers do not re-advertise routes learned from one iBGP peer to another iBGP peer. If a network grows, scaling issues could emerge because of the full mesh configuration requirement. Instead of peering with all other iBGP routers in the network, each iBGP router only peers with a router configured as a route reflector.

Route reflection circumvents the full mesh requirement but maintains the full distribution of external routing information within an AS. Route reflection is effective in large networks because it is manageable, scalable, and easy to implement. Route reflection is implemented in autonomous systems with a large internal BGP mesh to reduce the number of iBGP sessions required within an AS.

A route reflector (RR) provides route reflection services to iBGP peers called clients. Other iBGP peers of the RR are called non-clients. An RR and its client peers form a cluster. A large AS can be subdivided into multiple clusters, each identified by a unique 32-bit cluster ID. Each cluster contains at least one route reflector, which is responsible for redistributing route updates to all clients. Route reflector clients do not need to maintain a full peering mesh between each other. They only require peering to the route reflectors in their cluster. The route reflectors must maintain a full peering mesh between all non-clients within the AS.

Each route reflector must be assigned a cluster ID and specify which neighbors are clients and which are non-clients to determine which neighbors should receive reflected routes and which should be treated as a standard iBGP peer. Additional configuration is not required for the route reflector besides the typical BGP neighbor parameters.

The following figure shows a simple full-mesh configuration with several BGP routers. When SR-A receives a route from SR-1 (an external neighbor), it must advertise route information to all of its iBGP peers (SR-B, SR-C, SR-D, SR-E, SR-F). To prevent loops, iBGP learned routes are not re-advertised to other iBGP peers.

When route reflectors are configured, the routers within a cluster do not need to be fully meshed. The preceding figure shows a fully meshed network and Figure: BGP configuration with route reflectors shows the same network but with route reflectors configured to minimize the iBGP mesh between SR-A, SR-B, SR-C, and SR-D. SR-A, configured as the route reflector, is responsible for redistributing route updates to clients SR-B, SR-C, and SR-D. iBGP peering between SR-B, SR-C and SR-D is not necessary because even iBGP learned routes are reflected to the route reflector clients.

In the following figure, SR-E and SR-F are shown as non-clients of the route reflector. As a result, a full mesh of iBGP peerings must be maintained between SR-A, SR-E, and SR-F.

A route reflector enables communication between the clients and non-client peers. Clients of a route reflector do not need to be fully meshed but non-client peers need to be fully meshed within an AS.

A grouping (cluster) is composed of a route reflector (or a redundant pair of route reflectors configured with the same cluster ID) and its client peers. Each route reflector is assigned a cluster ID and this defines the cluster that it and its clients belong to. Multiple route reflectors can be configured within a cluster for redundancy. A router assumes the role as a route reflector by configuring the cluster cluster-id command. No other command is required unless the operator needs to disable reflection to specific clients.

When a route reflector receives an advertised route, it selects the best path. If the best path was received from an eBGP peer, then it is typically advertised, with next hop unchanged, to all clients and non-client peers of the route reflector. If the best path was received from a non-client peer, then it is advertised to all clients of the route reflector. If the best path was received from a client, then it is advertised to all clients and non-client peers.

A router becomes a route reflector whenever it has one or more client iBGP sessions. A client iBGP session is created with the cluster command, which also indicates the cluster ID of the client. The router ID is typically used as the cluster ID, but this is not necessary.

Basic route reflection operation (without add-path configured) can be summarized as follows:

• If the best and valid path for an NLRI is learned from a client and disable-client-reflect is not configured, then that route is advertised to all clients, non-clients, and eBGP peers (as allowed by policy). If the client that advertised the best and valid path is a neighbor to which the split-horizon command (at the bgp, group, or neighbor level) applies, then the route is not advertised back to the sending client. In the route that is reflected to clients and non-clients:

  • The route reflector adds an ORIGINATOR_ID attribute if it does not already exist; the ORIGINATOR_ID indicates the BGP identifier (router ID) of the client that originated the route.

  • The route reflector prepends the cluster ID of the client that advertised the route and then the cluster ID of the client receiving the route (if applicable) to the CLUSTER_LIST attribute, creating the attribute if it does not already exist.

• If the best and valid path for an NLRI is learned from a client and disable-client-reflect is configured, then that route is advertised to all clients in other clusters, non-clients, and eBGP peers (as allowed by policy). In the route that is reflected to clients in other clusters and non-clients:

  • The route reflector adds an ORIGINATOR_ID attribute if it does not already exist; the ORIGINATOR_ID indicates the BGP identifier (router ID) of the client that originated the route.

  • The route reflector prepends the cluster ID of the client that advertised the route and then the cluster ID of the client receiving the route (if applicable) to the CLUSTER_LIST attribute, creating the attribute if it does not already exist.

• If the best and valid path for an NLRI is learned from a non-client, then that route is advertised to all clients and eBGP peers (as allowed by policy). In the route that is reflected to clients:

  • The route reflector adds an ORIGINATOR_ID attribute if it does not already exist; the ORIGINATOR_ID indicates the BGP identifier (router ID) of the non-client that originated the route.

  • The route reflector prepends the cluster ID of the client receiving the route to the CLUSTER_LIST attribute, creating the attribute if it already exists.

• If the best and valid path for an NLRI is learned from an eBGP peer, then that route is advertised to all clients, non-clients, and other eBGP peers (as allowed by policy). The ORIGINATOR_ID and CLUSTER_LIST attributes are not added to the route.

• If the best and valid path for an NLRI is locally originated by the RR — that is, it was learned through means other than BGP — then that route is advertised to all clients, non-clients, and eBGP peers (as allowed by policy). The ORIGINATOR_ID and CLUSTER_LIST attributes are not added to the route.

The ORIGINATOR_ID and CLUSTER_LIST attributes allow BGP to detect the looping of a route within the AS. If any router receives a BGP route with an ORIGINATOR_ID attribute containing its own BGP identifier, the route is considered invalid. In addition, if a route reflector receives a BGP route with a CLUSTER_LIST attribute containing a locally configured cluster ID, the route is considered invalid. Invalid routes are not installed in the route table and are not advertised to other BGP peers.

If VPN-IPv4 and VPN-IPv6 routes are advertised by a 7210 SAS router, the BGP next-hop address is set as follows for a reflected route:

• When a route is reflected from one iBGP peer to another iBGP peer, the RR server does not modify the next hop by default; however, if the next-hop-self command is applied to the RR and enable-rr-vpn-forwarding is configured, then this combination of commands changes the next hop to the local address of the RR used with the peer.

• If BGP 3107 LU service optimization has been configured using the config>router>bgp>group>neighbor>advertise-label ipv4 use-svc-routes command along with the enable-rr-vpn-forwarding command, only those BGP 3107 LU routes for which the node installs a swap entry for a VPN label are installed in the FIB.