In the last article, we discussed the requirement that IBGP peers must be fully meshed and also mentioned two technologies that can be used to relax that requirement. In this article, we will be configuring one of those technologies.
CCNA Training – Resources (Intense)
For our route reflection configuration, we will be using the network diagram below:
In the network above, R2 will act as the route reflector while R1 and R3 will be client peers; therefore, R1, R2, and R3 form a cluster. R4 is a non-client peer of R2 while R5 is a normal EBGP peer. The configuration on the devices is as follows:
hostname R1 ! interface Loopback11 ip address 192.168.11.1 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.12.1 255.255.255.0 ! router ospf 1 network 192.168.12.0 0.0.0.255 area 0 ! router bgp 1 no synchronization bgp router-id 22.214.171.124 network 192.168.11.0 neighbor 192.168.12.2 remote-as 1 no auto-summary !
hostname R2 ! interface FastEthernet0/0 ip address 192.168.12.2 255.255.255.0 ! interface FastEthernet0/1 ip address 192.168.23.2 255.255.255.0 ! interface FastEthernet1/0 ip address 192.168.24.2 255.255.255.0 ! interface FastEthernet2/0 ip address 192.168.25.2 255.255.255.0 ! router ospf 1 network 192.168.12.0 0.0.0.255 area 0 network 192.168.23.0 0.0.0.255 area 0 network 192.168.24.0 0.0.0.255 area 0 ! router bgp 1 no synchronization bgp router-id 126.96.36.199 neighbor 192.168.12.1 remote-as 1 neighbor 192.168.12.1 route-reflector-client neighbor 192.168.12.1 next-hop-self neighbor 192.168.23.3 remote-as 1 neighbor 192.168.23.3 route-reflector-client neighbor 192.168.23.3 next-hop-self neighbor 192.168.24.4 remote-as 1 neighbor 192.168.24.4 next-hop-self neighbor 192.168.25.5 remote-as 5 no auto-summary !
hostname R3 ! interface FastEthernet0/0 ip address 192.168.23.3 255.255.255.0 ! router ospf 1 network 192.168.23.0 0.0.0.255 area 0 ! router bgp 1 no synchronization bgp router-id 188.8.131.52 neighbor 192.168.23.2 remote-as 1 no auto-summary !
hostname R4 ! interface Loopback44 ip address 192.168.44.4 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.24.4 255.255.255.0 ! router ospf 1 network 192.168.24.0 0.0.0.255 area 0 ! router bgp 1 no synchronization bgp router-id 184.108.40.206 network 192.168.44.0 neighbor 192.168.24.2 remote-as 1 no auto-summary !
hostname R5 ! interface Loopback55 ip address 192.168.55.1 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.25.5 255.255.255.0 ! router bgp 5 no synchronization bgp router-id 220.127.116.11 network 192.168.55.0 neighbor 192.168.25.2 remote-as 1 no auto-summary !
As you will notice from the configuration, R1, R3, R4, and R5 have pretty standard configurations that we are familiar with. However, R2, being the route reflector, has an extra configuration—the neighbor route-reflector-client command. That command is used to designate R1 and R3 as client peers. R2 designates R4 as a normal IBGP peer (non-client peer) and R5 as a normal EBGP peer. You will also notice that I have used the next-hop-self command for all the IBGP peers so that R2 will change the next-hop for all EBGP routes to its own IP address.
Note: Without the next-hop-self command, R2 will send EBGP routes (e.g. 192.168.55.0/24) with the next-hop of the external peer. If the external peer’s address is not known via IGP on the internal routers, the route will not be installed in their routing tables.
Hint: Another way to do this without using the next-hop-self command is to advertise the 192.168.25.0/24 network into OSPF from R2 and make the interface connected to the external peer (Fa2/0) passive-interface so that it doesn’t send OSPF Hello packets on that interface.
Let’s look at the BGP table to confirm route reflection. You can refer to the last article for what routes are reflected/advertised to the different peers. First, I expect R2 to reflect the 192.168.11.0/24 prefix received from a client peer (R1) to both client and non-client peers i.e. R3 and R4.
Notice that the output includes the ORIGINATOR_ID and CLUSTER_LIST attributes. The packet capture of the UPDATE message sent by R2 to R3 for the 192.168.11.0/24 prefix is shown below:
For every route reflected by a route reflector, the RR will create the ORIGINATOR_ID attribute and that attribute will contain the BGP Identifier of the BGP speaker that originated the route. In this case, R1 is the originator of that route and its BGP ID is 18.104.22.168.
For every router reflector that reflects this route, it will prepend its CLUSTER_ID to the CLUSTER_LIST attribute. Therefore, if by any chance the update gets sent back to the cluster which it has passed through, the router reflector will drop it.
Normal BGP operation will also cause R2 to advertise the IBGP route to its EBGP peers; therefore R5 will get the advertisement for the 192.168.11.0/24 prefix. However, the route on R5 does not contain the ORIGINATOR_ID and CLUSTER_LIST attributes because these attributes are non-transitive, meaning they are not advertised between different ASs.
The next thing I expect to see is that R2 should reflect the 192.168.44.0/24 received from the non-client peer (R4) to its client peers, i.e., R1 and R3.
Notice that the ORIGINATOR_ID attribute contains the BGP identifier of R4 i.e. 22.214.171.124.
Finally, I expect R2 to advertise the route received from its EBGP peer (192.168.55.0/24) to both client and non-client peers. This is default BGP behavior that EBGP routes are advertised to IBGP peers. Notice that there are no ORIGINATOR_ID and CLUSTER_LIST attributes.
Multiple Route Reflectors
Even though route reflectors help reduce the number of IBGP peering sessions required in an AS, a route reflector can be a single point of failure. Therefore, it may be beneficial to have multiple RRs even in one cluster.
In the diagram below, R2 and R4 would act as route reflectors for the cluster consisting of all the routers. R1 and R3 are client peers of both RRs. Notice that there is a physical connection between each client peer and the RRs. It will not make sense for it to be a logical connection because we will still have the issue of single point of failure. For example, if R1 forms a logical IBGP session with R4 through R2, if R2 goes down, so does the IBGP session between R1 and R4.
To get this to work, we need extra neighbor statements on R1 and R3 to peer with R4. R4 also needs to designate R1 and R3 as RR client peers. The normal IBGP peering session between R2 and R4 remains the same. Finally, we need to configure the same cluster ID on both RRs since they belong to the same cluster. The configuration change is as follows:
interface FastEthernet0/1 ip address 192.168.14.1 255.255.255.0 ! router ospf 1 network 192.168.14.0 0.0.0.255 area 0 ! router bgp 1 neighbor 192.168.14.4 remote-as 1
router bgp 1 bgp cluster-id 24
interface FastEthernet0/1 ip address 192.168.34.3 255.255.255.0 ! router ospf 1 network 192.168.34.0 0.0.0.255 area 0 ! router bgp 1 neighbor 192.168.34.4 remote-as 1
interface FastEthernet0/1 ip address 192.168.14.4 255.255.255.0 ! interface FastEthernet1/0 ip address 192.168.34.4 255.255.255.0 ! router ospf 1 network 192.168.14.0 0.0.0.255 area 0 network 192.168.34.0 0.0.0.255 area 0 ! router bgp 1 bgp cluster-id 24 neighbor 192.168.14.1 remote-as 1 neighbor 192.168.14.1 route-reflector-client neighbor 192.168.34.3 remote-as 1 neighbor 192.168.34.3 route-reflector-client
As you can see from the configuration, I’m using a CLUSTER_ID of 24 on both RRs. If we check the 192.168.11.0/24 on R3, we should see that it has two paths through both RRs (although only one will be used as the best path by default).
In this article, we have discussed how to use route reflectors to reduce the number of peering sessions between IBGP peers in an AS. In the case where you have 100 IBGP peers in an AS, we can now have 197 IBGP sessions in total (assuming 2 of the peers are acting as RRs and the remaining 98 peer with both RRs) instead of a full mesh of 4950 IBGP sessions. We have also seen how the ORIGINATOR_ID and CLUSTER_LIST attributes are used to prevent routing loops. We then looked at how to configure multiple route reflectors in the same cluster by setting the same CLUSTER_ID.
In the next article, we will look at the second feature that can help reduce the number of IBGP peering sessions in an AS – Confederations. I hope you have found this article insightful and I look forward to the next one in the series.
References and Further Reading
Internet Routing Architectures 2nd Edition by Sam Halabi and Danny McPheron.
Routing TCP/IP, Volume II, by Jeff Doyle.
BGP Case Studies: Route Reflectors: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#routereflectors