BGP Route Reflectors (GNS3 lab)

One problem of having a large number of routers running IBGP with each other in a full mesh is the volume of IBGP connections needed. The formula to see the number of connections needed for a full IBGP mesh is n(n-1)/2 so  with 20 routers we would end up needing 190 connections. One of the solutions to ease the admin and config burden of this requirement is the use of route reflectors.

We’ll see how the route reflector acts as a concentration point for “client” routers. How they share information with the route reflector and how the route reflector shares (reflects) information from other neighbours and clients back. This makes the route reflector solution highly scalable in a large AS.

In the example below we have two route reflectors (RRS1 & RRS2) each forming a cluster with at least one client. RRS1 and RRS2 still have to follow the normal rules of IBGP between themselves ie. all route reflectors (not clients) still have to form a full IBGP mesh.

Grab the initial configs [HERE]. All addressing done and complete config of SmileyISP.

Lets configure RRS1

RRS1#conf t
RRS1(config-router)#router bgp 200
RRS1(config-router)# bgp log-neighbor-changes
RRS1(config-router)# network 10.1.13.0 mask 255.255.255.0
RRS1(config-router)# network 10.1.14.0 mask 255.255.255.0
RRS1(config-router)# network 10.1.15.0 mask 255.255.255.0
RRS1(config-router)# neighbor RouteReflectors peer-group
RRS1(config-router)# neighbor RouteReflectors remote-as 200
RRS1(config-router)# neighbor RRClients peer-group
RRS1(config-router)# neighbor RRClients remote-as 200
RRS1(config-router)# neighbor RRClients route-reflector-client
RRS1(config-router)# neighbor 10.1.12.2 peer-group RouteReflectors
RRS1(config-router)# neighbor 10.1.13.3 peer-group RRClients
RRS1(config-router)# neighbor 10.1.14.4 peer-group RRClients
RRS1(config-router)# neighbor 10.1.15.5 remote-as 100

Enter BGP config mode and configure the networks to advertise. Then we define two peer groups, RRClients and RouteReflectors. These just provide a way to apply polices across a number of neighbours making admin/config easier. Notice the “neighbor RRClients route-reflector-client” command, this tell the route reflector all neighbours in the RRClients peer group are clients. Then we put the other route reflector in AS200 into the RouteReflector peer group. RRc2 & RRc3 are put into the RRClients peer group. Finally a regualar EBGP neighbour is defined for the connection to SmileyISP.

Now the config for a client router, RRc3

RRc3(config-router)#router bgp 200
RRc3(config-router)# no synchronization
RRc3(config-router)# bgp log-neighbor-changes
RRc3(config-router)# network 10.1.14.0 mask 255.255.255.0
RRc3(config-router)# network 172.16.3.0 mask 255.255.255.0
RRc3(config-router)# neighbor 10.1.14.1 remote-as 200

Configuring a route reflector client doesn’t require any extra config than is usually required for IBGP! Route reflectors we designed to not require extra config 🙂 Now we have connectivity from the loopback on RRc3 to the loopback on SmileyISP. The config for RRc2 is the same as RRc3 apart from the addresses so lets look at the config for RRS2

RRS2(config-router)#router bgp 200
RRS2(config-router)# bgp log-neighbor-changes
RRS2(config-router)# network 10.1.12.0 mask 255.255.255.0
RRS2(config-router)# network 10.1.25.0 mask 255.255.255.0
RRS2(config-router)# network 10.1.26.0 mask 255.255.255.0
RRS2(config-router)# neighbor RouteReflectors peer-group
RRS2(config-router)# neighbor RouteReflectors remote-as 200
RRS2(config-router)# neighbor RRClients peer-group
RRS2(config-router)# neighbor RRClients remote-as 200
RRS2(config-router)# neighbor RRClients route-reflector-client
RRS2(config-router)# neighbor 10.1.12.1 peer-group RouteReflectors
RRS2(config-router)# neighbor 10.1.25.5 remote-as 100
RRS2(config-router)# neighbor 10.1.26.6 peer-group RRClients

The config is very similar to RRS1. We advertise the connected networks, setup two peer groups to allow easy management and ease scalability. Notice the important line again for the RRclients peer group, “neighbour RRClients route-reflector-client”. Just assign the neighbours to the appropriate peer group. Configure RRc1 similar to RRc2&3 (no special route reflector config required/i.e. clients dont need to know they are clients!). Once done all loopback should be able to ping to/from the loopback on SmileyISP. One problem still persists though because we didn’t configure an IGP like ospf the next hop for the loopback subnets will be unreachable for the 3 client routers. Either configure and IGP accross the whole AS or the following config on RRs1 & 2 (replace addresses for RRs1).

RRS2(config)#route-map NEXTHOP permit 10
RRS2(config-route-map)# set ip next-hop 10.1.12.2
RRS2(config-route-map)#exit
RRS2(config-router)#router bgp 200
RRS2(config-router)# neighbor 10.1.12.1 route-map NEXTHOP out

Clear the bgp session between the two RR routers and you now have full connectivity.

moonie 🙂

Comments

  • Great write up… one issue I’m having is when I issue the “neighbor 10.1.12.1 route-map NEXTHOP out” I get %Invalid command for a peer-group member.

  • well why don’t just advertise 10.1.12.0/24 network from RRS1 as well instead of changing next-hop – it seems to me cleaner i’d say

  • Hi Peter 🙂

    You can do it if you want to it was just meant to show in the lab that the next-hops being announced should be available in the “IGP” of each router
    Cheers

    m00nie