Using BGP Route Reflectors

Problem

You want to simplify your iBGP peer relationships by using route reflectors.

Solution

There are three types of configurations to consider when working with BGP Route Reflectors: the Route Reflector itself, the Client Peer, and the Nonclient Peer. In this example, which follows Figure 9-4, the Route Reflector is Router2, and it has two Client PeersRouter1 and Router3. It also has a Nonclient Peer, Router4.

The configurations for Client and Nonclient Peers contain no special commands. Router1 is the Client Peer:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Ethernet0/0
Router1(config-if)#ip address 172.18.5.2 255.255.255.0
Router1(config-if)#exit
Router1(config)#interface Serial0/0
Router1(config-if)#ip address 192.168.1.6 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Loopback0
Router1(config-if)#ip address 172.18.6.1 255.255.255.255
Router1(config-if)#exit
Router1(config)#router bgp 65500
Router1(config-router)#no synchronization
Router1(config-router)#neighbor 172.18.6.2 remote-as 65500
Router1(config-router)#neighbor 172.18.6.2 next-hop-self
Router1(config-router)#neighbor 172.18.6.2 update-source Loopback0
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#exit
Router1(config)#ip route 172.18.6.2 255.255.255.255 172.18.5.3
Router1(config)#ip route 172.18.6.3 255.255.255.255 172.18.5.4
Router1(config)#ip route 172.18.6.4 255.255.255.255 172.18.5.10
Router1(config)#end
Router1#

Router4 is the Nonclient Peer:

Router4#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router4(config)#interface Ethernet0
Router4(config-if)#ip address 172.18.5.10 255.255.255.0
Router4(config-if)#exit
Router4(config)#interface Loopback0
Router4(config-if)#ip address 172.18.6.4 255.255.255.255
Router4(config-if)#exit
Router4(config)#router bgp 65500
Router4(config-router)#no synchronization
Router4(config-router)#neighbor 172.18.6.2 remote-as 65500
Router4(config-router)#neighbor 172.18.6.2 update-source Loopback0
Router4(config-router)#exit
Router4(config)#ip route 172.18.6.1 255.255.255.255 172.18.5.2
Router4(config)#ip route 172.18.6.2 255.255.255.255 172.18.5.3
Router4(config)#ip route 172.18.6.3 255.255.255.255 172.18.5.4
Router4(config)#end
Router4#

The only special configuration required is on the Route Reflector itself:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#interface FastEthernet0/0
Router2(config-if)#ip address 172.18.5.3 255.255.255.0
Router2(config-if)#exit
Router2(config)#interface Loopback0
Router2(config-if)#ip address 172.18.6.2 255.255.255.255
Router2(config-if)#exit
Router2(config)#router bgp 65500
Router2(config-router)#no synchronization
Router2(config-router)#neighbor 172.18.6.1 remote-as 65500
Router2(config-router)#neighbor 172.18.6.1 route-reflector-client
Router2(config-router)#neighbor 172.18.6.1 update-source Loopback0
Router2(config-router)#neighbor 172.18.6.3 remote-as 65500
Router2(config-router)#neighbor 172.18.6.3 route-reflector-client
Router2(config-router)#neighbor 172.18.6.3 update-source Loopback0
Router2(config-router)#neighbor 172.18.6.4 remote-as 65500
Router2(config-router)#neighbor 172.18.6.4 update-source Loopback0
Router2(config-router)#no auto-summary
Router2(config-router)#exit
Router2(config)#ip route 172.18.6.1 255.255.255.255 172.18.5.2
Router2(config)#ip route 172.18.6.3 255.255.255.255 172.18.5.4
Router2(config)#ip route 172.18.6.4 255.255.255.255 172.18.5.10
Router2(config)#end
Router2#

Discussion

In the standard BGP peering model that prevailed in every other recipe in this chapter, there is a strict rule that any external route learned by one of the BGP routers in an AS must be advertised to any other BGP routers in the same AS by the router that used the original route. To see what this means, consider Figure 9-4.

Figure 9-4. BGP route reflection

In this diagram, Router1 receives a routing update from external Router4. So Router1 must readvertise this information to Router2 and Router3, the other routers in the AS. When Router2 receives this update, it may pass the information along to external peers, but it must not relay it to another router in the same AS, such as Router3. The reason for this is simply to prevent routing loops.

This is a sensible rule, in most cases, but it means that every router in an AS must have an iBGP peer relationship with every other router in that AS. This full mesh of iBGP peers doesn't scale very well when you have a lot of BGP routers in one AS. So RFC 2796 provides a way to relax this rule. We can configure Router2 as a Route Reflector, and Router1 and Router3 as its Client Peers.

Note that there could be other routers in this AS as well, which may or may not also be client peers of the same route reflector. Router4 is a Nonclient Peer of Router2. The Nonclient Peers must have the usual full mesh peering relationship among one another, although they do not have to peer with any of the Client peers of the route reflector. They can get all of the information for all of the route reflector's client peers at once by simply peering with the route reflector.

You could have more complicated systems of route reflectors in an AS. For example, you might want to divide up your AS into several different regions, each represented by a pair of redundant route reflectors. The peers of each route reflector would then establish iBGP peering relationships with their own reflectors, but not with any other routers in the AS. The route reflectors would then peer with one another in a full mesh to ensure full connectivity within the AS.

It's also important to remember that the route reflectors do not have to pass all of the traffic for their respective clients. Their only special function is in making sure that all of their clients have good BGP routing information.

To configure one router as a Route Reflector, you simply configure a neighbor command with the route-reflector-client keyword for those neighbor devices that will be Client Peers:

Router2(config)#router bgp 65500
Router2(config)#router bgp 65500
Router2(config-router)#no synchronization
Router2(config-router)#neighbor 172.18.6.1 remote-as 65500
Router2(config-router)#neighbor 172.18.6.1 route-reflector-client
Router2(config-router)#neighbor 172.18.6.1 update-source Loopback0
Router2(config-router)#neighbor 172.18.6.3 remote-as 65500
Router2(config-router)#neighbor 172.18.6.3 route-reflector-client
Router2(config-router)#neighbor 172.18.6.3 update-source Loopback0
Router2(config-router)#neighbor 172.18.6.4 remote-as 65500
Router2(config-router)#neighbor 172.18.6.4 update-source Loopback0
Router2(config-router)#no auto-summary
Router2(config-router)#exit

This specifies that the two peers, 172.18.6.1 and 172.18.6.3, are Client Peers. We have not included a neighbor route-reflector-client command for the other neighbor, 172.18.6.4, making it a Nonclient Peer of this route reflector. There is no special configuration required on either Client or Nonclient Peer routers and, indeed, these devices don't even know or care about the difference. The only router that needs to do anything special is the Route Reflector itself.

When configuring two or more redundant BGP Route Reflectors, though, another little trick is required. In the current example, if we were to just turn on Route Reflection on Router4 with the same clients as Router2, this would cause some problems, as the two Route Reflectors hear about every reflected routing prefix both from the original source and from the other Route Reflector. This could cause strange behavior if the real source of the route becomes unavailable. The two Route Reflectors will both believe that the route is reachable through one another.

To prevent this problem, we need to specify a cluster ID on each Route Reflector to identify a particular group of Client Peers:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#router bgp 65500
Router2(config-router)#bgp cluster-id 1234

And you need to configure the same cluster ID on the other Route Reflector:

Router4#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router4(config)#router bgp 65500
Router4(config-router)#bgp cluster-id 1234

There is one important caveat about implementing cluster IDs, however. In a case like this one, where we had one router acting as a Route Reflector, and we wanted to either implement a new cluster ID, or to change an existing one, we had to manually remove the Client Peer configuration from the Route Reflector first. Then we configured the cluster-id command and replaced the Client Peer neighbor configuration statements.

When working with Route Reflectors, we strongly recommend implementing two or more redundant reflectors. If you have a single reflector for a large network, then this becomes a dangerous single point of failure for your entire BGP routing infrastructure.