Route Reflectors configuration on Cisco devices

Route reflectors became an essential part of any larger internet service provider’s environment. It would be hard to imagine multiple routers running BGP in full mesh topology these days when scalability is the key. The complete route reflector concept can be found in RFC4456, which dates back to 2006. It’s very important to be familiar with BGP protocol prior getting involved with route reflectors.

Why is route reflecting so helpful when it comes to scalability? First, we need to look at how routes are exchanging information via the BGP protocol. With external BGP (connection between different autonomous systems) there’s a simple solution to avoid routing loops, which is the autonomous system number that is added to each route and describes its origin. When a router sees the same AS number as its own in the route, it knows that it’s coming from its own autonomous system and doesn’t use it because it would generate a loop. This loop prevention mechanism is perfectly logical for Internet routes (eBGP), however it limits the scalability with internal BGP peerings (iBGP). The AS number for iBGP peers is the same so the BGP protocol needed to adopt a special rule. None of the routes received from one iBGP peer can be advertised or forwarded to another iBGP peer. Simply said, all iBGP peers need to form neighborship with all other iBGP routers. And that’s a lot of BGP sessions.

This is the formula for calculating the number of sessions needed for a full mesh:

N(N -1)/2 [where N represents number of routers]

For 20 routers for instance: 20(20-1)/2 = 190 BGP sessions

Route reflector explained

A Route reflector is a router that acts as a routing information exchange server for all other iBGP routers. It has the capability of advertising routes between internal BGP peers. Any new router in the network topology needs only to create a session with route reflector and it will get all routes from there.

That significantly ease the scalability of the BGP infrastructure. The very best practice is to have at least two cooperating route reflectors in case that one of them fails, which is called cluster. This is done to provide redundancy to a critical component such as the route reflector.

Route reflector configuration

We have created a very simple scenario with one route reflector and two route reflector clients. All routers are running Cisco IOS. All Ethernet links are configured with /30 networks within 10.0.0.0 private range and there are also loopback interfaces used for iBGP peerings:

R1 – 192.168.1.1

R2 – 192.168.2.1

RR – 192.168.0.3

We used the RIP protocol to exchange routes information about all IP prefixes and loopback interfaces,. The interface loopback-50 on R1 (IP 50.50.50.50), will be advertised only via BGP protocol to make sure that our topology works correctly. R1 will advertise its Loopback50 to the route reflector and the route reflector will re-advertise that one to R2.

Configuring route reflectors on Cisco devices

R1#show run int eth 0/1
interface Ethernet0/1
ip address 10.0.0.1 255.255.255.252
full-duplex
end

R1#show run int lo 0
interface Loopback0
ip address 192.168.1.1 255.255.255.255
end

R1#show run int lo 50
interface Loopback50
ip address 50.50.50.50 255.255.255.0
end

R1#show run | s rip
router rip
network 10.0.0.0
network 192.168.1.0
no auto-summary

R1#show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 50.50.50.0 mask 255.255.255.0
neighbor 192.168.0.3 remote-as 100
neighbor 192.168.0.3 update-source Loopback0
no auto-summary

R2#show run int e0/0
interface Ethernet0/0
ip address 10.0.0.6 255.255.255.255
full-duplex
end

R2#show run int lo0
interface Loopback0
ip address 192.168.2.1 255.255.255.255
end

R2#show run | s rip
router rip
network 10.0.0.0
network 192.168.2.0
no auto-summary

R2#show run | s bgp
router bgp 10
no synchronizatio
bgp log-neighbor-changes
neighbor 192.168.0.3 remote-as 100
neighbor 192.168.0.3 update-source Loopback0
no auto-summary

RR#show run int eth 0/1
interface Ethernet0/1
ip address 10.0.0.2 255.255.255.252
full-duplex
end

RR#show run int eth 0/0
interface Ethernet0/0
ip address 10.0.0.5 255.255.255.252
full-duplex
end

RR#show run int lo0
interface Loopback0
ip address 192.168.0.3 255.255.255.255
end

RR#show run | s rip
router rip
network 10.0.0.0
network 192.168.0.0
no auto-summary

RR#show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 192.168.1.1 remote-as 100
neighbor 192.168.1.1 update-source Loopback0
neighbor 192.168.1.1 route-reflector-client
neighbor 192.168.2.1 remote-as 100
neighbor 192.168.2.1 update-source Loopback0
neighbor 192.168.2.1 route-reflector-client
no auto-summary

Now we need to test that we can reach the Loopback 50 from R2, so let’s verify its routing table first:

R2#show ip route
***
     50.0.0.0/24 is subnetted, 1 subnets
B       50.50.50.0 [200/0] via 192.168.1.1, 00:14:12
     10.0.0.0/30 is subnetted, 2 subnets
R       10.0.0.0 [120/1] via 10.0.0.5, 00:00:07, Ethernet0/0
C       10.0.0.4 is directly connected, Ethernet0/0
R   192.168.0.0/24 [120/1] via 10.0.0.5, 00:00:07, Ethernet0/0
R   192.168.1.0/24 [120/1] via 10.0.0.5, 00:00:07, Ethernet0/0
     192.168.2.0/32 is subnetted, 1 subnets
C       192.168.2.1 is directly connected, Loopback0

R2#ping 50.50.50.50
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.50.50.50, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/56/76 ms

That’s perfect, we can see route to 50.50.50.0 network in R2’s routing table, along with proof of reachability. If we would need to add another iBGP router, we just need to create a session with the route reflector and get all the networks. We just shouldn’t forget to advertise one with network command in configuration on R1. Remember, Cisco routers do not advertise anything by default.