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 18.104.22.168), 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 22.214.171.124 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 126.96.36.199 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 *** 188.8.131.52/24 is subnetted, 1 subnets B 184.108.40.206 [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 220.127.116.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, 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 22.214.171.124 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.