BGP Route Reflectors

A route reflector is a BGP router configured to forward routing updates to peers within the same AS. Route reflectors reduce the problems that are caused by fully meshed IBGP topologies. This is accomplished by lowering the number of IBGP neighbor relationships needed in an AS. BGP route reflectors alleviate the scalability problem of internal BGP (IBGP) full mesh topologies by reducing the number of IBGP sessions that must be configured between routers. They serve to tweak the BGP split horizon rule by permitting a BGP router, configured as a route reflector, to send out IBGP-learned routes to other IBGP neighbors. This change in behavior can be seen in Figure 9.2.

Figure 9.2. RouterB is configured as a route reflector to propagate routes from RouterA to RouterC.

Not only does a route reflector alter the split horizon rule by allowing IBGP-learned routes to be flooded to other IBGP peers, but the number of BGP TCP sessions is lessened considerably and BGP routing traffic is reduced. Because the route reflector propagates any IBGP routes learned from its configured clients , client-to-client peering is not necessary. Table 9.1 shows the main terminology needed to understand Route Reflectors.

Table 9.1. Route Reflector Terminology

Route Reflector Term	Description
Route reflector	A router that is set up to reflect or advertise IBGP-learned routes to other IBGP neighbors.
Client	Routers that have neighbor relationships with the route reflector. The number of clients that a reflector can have is limited only by memory.
Cluster	A grouping of the route reflector and its respective clients.
Cluster ID	An identifier that enables a route reflector to see updates from other routers in the same cluster.
Non-clients	IBGP peers of the route reflector that are not configured as clients.
Originator ID	An optional and non-transitive BGP attribute that is generated by a route reflector. The attribute is the Router ID of the originating route reflector of the route in the local AS.
Cluster-list	An optional and non-transitive attribute that represents a sequence of cluster IDs that are passed along with the route. The local cluster ID is appended to the cluster list when a route reflector advertises a route from its clients to non-clients outside the cluster.

The following list demonstrates the many benefits and advantages of implementing route reflectors:

• You do not need to implement a full mesh topology.

• The route reflector propagates routes to IBGP peers.

• The number of BGP peer relationships is reduced.

• You can employ multiple route reflectors for redundancy and session reduction.

• Route reflectors need minimal configuration.

• Regular BGP routers can coexist with route reflectors.

A route reflector client is an IBGP router specifically set up to be given routing updates from a reflecting router. The term that describes the collective unit of a route reflector and the clients it communicates with is called a cluster . An AS can be separated into multiple clusters containing a route reflector and its clients. The route reflectors have to be configured in a full mesh topology with IBGP. You still utilize an IGP, for example EIGRP or OSPF, to transport local route and next -hop address information. A broad example of this concept is demonstrated in Figure 9.3.

Figure 9.3. A sample router topology showing the main route reflector concepts.

You should know that multiple route reflectors can be deployed within a large autonomous system for purposes of redundancy.

If an update packet comes from a client peer, the route reflector will forward the update to all client and non-client peers, except for the peer that sent the original route. (The route reflector and its clients will still adhere to the normal split horizon rule.) If an IBGP route reflector receives a routing update from a non-client IBGP peer, it forwards the update to all IBGP clients in the cluster. If the update comes from an EBGP peer from outside the AS, then the route reflector forwards the update to all client and non-client peers within the AS. Figure 9.4 shows an example of a route reflector with three clients in a cluster.

Figure 9.4. A route reflector with three client routers in a cluster.

To establish a route reflector, you would configure RouterA normally and then configure a neighbor statement on RouterA for each BGP neighbor with which it is to communicate. In this case, the BGP neighbors are RouterB, RouterC, and RouterD. Route reflector configuration is done only on the route reflector and the clients are set up as normal IBGP neighbors. Updates are sent from the route reflector directly to all clients, and the clients receive only updates from the reflector. All the updates have the originator-ID attribute included. This is to assure a loop-free environment as the route reflector disregards an update with itself as the originator. There must be at least one route reflector per cluster, and the routers that are not part of the cluster (non-clients) still need to be in a full mesh topology for full connectivity. You should configure the route reflector in Figure 9.4 by using the following command:

  neighbor   ip address   route-reflector-client  

Refer to Figure 9.4 and notice that RouterA is the central distribution point for the BGP route updates. RouterB, RouterC, and RouterD are route reflector client peers that send all route updates that they learn to RouterA. RouterA then propagates the route to all its client peers, as well as to any non-client peers to which it is connected. This combination of a route reflector and its client peers is what we call a cluster . Route reflectors, clients, and non-clients all send and receive updates strictly with IBGP.

Listings 9.1 and 9.2 show the actual configuration for RouterA in Figure 9.4.

Listing 9.1 Configuring IBGP Peers for RouterA

 RouterA> enable RouterA# config t Enter configuration commands, one per line.  End with CNTL/Z RouterA(config)# router bgp 65410 RouterA(config-router)# neighbor 172.16.1.2 remote-as 65410 RouterA(config-router)# neighbor 172.16.255.6 remote-as 65410 RouterA(config-router)# neighbor 172.16.255.2 remote-as 65410 

Listing 9.2 Configuring RouterA As a Route Reflector

 RouterA> enable RouterA# config t Enter configuration commands, one per line.  End with CNTL/Z RouterA(config-router)# neighbor 172.16.1.2 route-reflector-client RouterA(config-router)# neighbor 172.16.255.6 route-reflector-client RouterA(config-router)# neighbor 172.16.255.2 route-reflector-client RouterA(config-router)# exit RouterA(config)# 

On the BSCI exam you may see a simulator question that demands that you perform all the steps to configure a route reflector in the proper order and with the correct syntax, shown in Listings 9.1 and 9.2. Also remember that in the simulator sections of the test, the question mark (?) is available to assist you with the syntax of the commands.

The router configuration command bgp cluster-id is used to assign a cluster ID when a cluster contains more than one route reflector for purposes of redundancy. The correct syntax for the bgp cluster-id command is as follows :

 RouterA(config-router)# bgp cluster-id cluster-id 

The cluster-id parameter is a four-byte integer value. You cannot change the cluster ID after you have configured the route reflector clients. Route reflector clients are also incompatible with peer groups because a peer group router has to send out policy updates to each and every member of its peer group .

The following router configuration command is used to selectively disable route reflection between clients:

 RouterA(config-router)# no bgp client-to-client reflection 

The show ip bgp ? command offers a number of parameters for viewing information about your cluster. Listing 9.3 shows the output of this powerful command.

Listing 9.3 The show ip bgp ? Command

 RouterA# show ip bgp ?   A.B.C.D           IP prefix <network>/<length>, e.g., 35.0.0.0/8   A.B.C.D           Network in the BGP routing table to display   cidr-only         Display only routes with non-natural netmasks   community         Display routes matching the communities   community-list    Display routes matching the community-list   dampened-paths    Display paths suppressed due to dampening   filter-list       Display routes conforming to the filter-list   flap-statistics   Display flap statistics of routes   inconsistent-as   Display only routes with inconsistent origin ASs   neighbors         Detailed information on TCP and BGP neighbor connections   paths             Path information   peer-group        Display information on peer-groups   regexp            Display routes matching the AS path regular expression   summary           Summary of BGP neighbor status   <cr> 

For example, the show ip bgp neighbors command can be used to display the status of TCP connections to BGP neighbors, including which neighbors are configured as route reflector client routers. The abbreviated command sh ip bgp nei displays the same information. Also, the show ip bgp summary command displays the three peer routers from Listing 9.1 and Listing 9.2 in a table format with statistics for data such as the AS number, messages received, messages sent, and so on.

BGP Confederations

A BGP confederation is a BGP configuration in which a single AS is divided into multiple logical ASs that run EBGP between them. It is another way of handling the sudden and rapid growth of an IBGP network. A confederation reduces the number of IBGP peers in an AS by dividing the AS into multiple smaller ASs (sub-autonomous systems), each with its own logical AS number. Each sub-AS sends and receives route updates internally with IBGP and communicates with other sub-ASs in the confederation by using EBGP. The BGP confederation looks like a single AS to the outside world.