To achieve a full mesh of iBGP peerings between more than a few devices becomes quite an administrative challenge. To overcome this you have two tools at your disposal. BGP Confederation and Route Reflectors. For the purpose of this tutorial I will be using the simple topology below. For the first configuration I will be setting up a BGP Confederation and then I will setup a Route Reflector. They both achieve the same goal and that is to reduce the number of peerings within an iBGP mesh.
BGP Confederation vs Route Reflector – which is best?
As this post is quite large I have divided it up into sections which you can jump to with the links below
BGP Confederation Configuration
Route Reflector Configuration
What is the difference?
BGP Confederation Configuration
The trick of a BGP Confederation is to divide an AS into multiple AS’s and assign the whole group to a single confederation. Each AS alone has iBGP fully meshed. To the outside world, the confederation appears to be a single AS.
For this bgp confederation vs route reflector tutorial we are going to start simple with one router in each sub AS. The first step in the configuration is to configure IP reachability to all the devices. I will also be running OSPF area 0 between R1, R2 & R3. Each router will also have a /32 loopback configured.
I will start the configuration from the left on Router 4. First we need to configure BGP 65500 and then add a neighbor statement to AS 64512
R4#sh run | sec router bgp router bgp 65500 no synchronization bgp log-neighbor-changes network 4.4.4.4 mask 255.255.255.255 network 10.1.41.0 mask 255.255.255.0 neighbor 10.1.41.1 remote-as 64512
Ok now moving onto R1 – this router will run BGP AS 2 but it will also be in the confederation of AS64512, it will peer to R4 and R1 both with eBGP peerings, the peering from R1 to R4 however will be from the confederation AS of 64512 and this is all R4 will see.
R1#sh run | sec router bgp router bgp 2 no synchronization bgp log-neighbor-changes bgp confederation identifier 64512 bgp confederation peers 1 network 10.1.12.0 mask 255.255.255.0 network 10.1.41.0 mask 255.255.255.0 neighbor 10.1.12.2 remote-as 1 neighbor 10.1.41.4 remote-as 65500 no auto-summary
So on R1 you have to specify that the router is in a confederation and this is done with the bgp confederation identifier, you also need to specify your bgp confederation peers. If there were more than one router in the sub-AS you would only need to specify the bgp confederation peers on the external facing routers.
Lets verify what the BGP looks like now
From the perspective of R4 it should see a standard eBGP peering to AS64512
R4#sh ip bgp sum BGP router identifier 10.1.41.4, local AS number 65500 BGP table version is 9, main routing table version 9 8 network entries using 960 bytes of memory 9 path entries using 468 bytes of memory 5/4 BGP path/bestpath attribute entries using 620 bytes of memory 2 BGP AS-PATH entries using 48 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory BGP using 2128 total bytes of memory BGP activity 8/0 prefixes, 9/0 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.41.1 4 64512 280 276 9 0 0 04:30:43 7
So you can see that from the perspective of R4 it just sees R1 as an eBGP neighbor in AS64512, lets continue to build the confederation. R1 is already configured to peer to R2 so we need to configure R2 to peer to R1 in AS2 and R3 in AS3 – remember to specify the bgp confederation identifier and bgp confederation peer.
R2#sh run | sec router bgp router bgp 1 no synchronization bgp log-neighbor-changes bgp confederation identifier 64512 bgp confederation peers 2 3 network 2.2.2.2 mask 255.255.255.255 network 10.1.12.0 mask 255.255.255.0 network 10.1.23.0 mask 255.255.255.0 neighbor 10.1.12.1 remote-as 2 neighbor 10.1.23.3 remote-as 3 no auto-summary
You can see that we need to specify the BGP confederation identifier and the bgp confederation peers to be 2 & 3. Lets review the config on R3 which is peering to R2 and R5 – Remember I have configured a loopback on each router on R3 the loopback address is 3.3.3.3/32 we will use that in a bit to verify that the confederation is working.
R3#sh run | sec router bgp router bgp 3 no synchronization bgp log-neighbor-changes bgp confederation identifier 64512 bgp confederation peers 1 network 3.3.3.3 mask 255.255.255.255 network 10.1.13.0 mask 255.255.255.0 neighbor 10.1.13.5 remote-as 65501 neighbor 10.1.23.2 remote-as 1 no auto-summary
Now remember the rules of iBGP. Any route received by an iBGP peer will not be passed onto another iBGP peer (unless you have a full mesh) This is the reason we are doing the confederation to overcome the requirement for a full mesh. However in this tutorial it is a very small topology. What we are missing for a full mesh is the link between R1 & R3. So if R1, R2, R3 were all peered using just iBGP you would not expect to see the route 3.3.3.3 on R1. Lets check if it is there now we are in a confederation.
R1#sh ip bgp
BGP table version is 9, local router ID is 10.1.41.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 10.1.12.2 0 100 0 (1) i
*> 3.3.3.3/32 10.1.23.3 0 100 0 (1 3) i
*> 4.4.4.4/32 10.1.41.4 0 0 65500 i
*> 5.5.5.5/32 10.1.13.5 0 100 0 (1 3) 65501 i
* 10.1.12.0/24 10.1.12.2 0 100 0 (1) i
*> 0.0.0.0 0 32768 i
*> 10.1.13.0/24 10.1.23.3 0 100 0 (1 3) i
*> 10.1.23.0/24 10.1.12.2 0 100 0 (1) i
*> 10.1.41.0/24 0.0.0.0 0 32768 i
* 10.1.41.4 0 0 65500 i
You can see the route 3.3.3.3 with a next hop of 10.1.23.3 as you know iBGP will pass the next hop value on but here the next hop value is still R3 – so some behaviours of confederation are as iBGP and some are as eBGP. You can also see some of the AS paths are in brackets – this is showing the confederation.
The final peering is from R3 to R5
R3#sh run | sec router bgp router bgp 3 no synchronization bgp log-neighbor-changes bgp confederation identifier 64512 bgp confederation peers 1 network 3.3.3.3 mask 255.255.255.255 network 10.1.13.0 mask 255.255.255.0 neighbor 10.1.13.5 remote-as 65501 neighbor 10.1.23.2 remote-as 1 no auto-summary
And then R5 peers to R3 but remember it needs to peer to AS64512 and is just a straightforward BGP peering.
R5#sh run | sec router bgp router bgp 65501 no synchronization bgp log-neighbor-changes network 5.5.5.5 mask 255.255.255.255 network 10.1.13.0 mask 255.255.255.0 neighbor 10.1.13.3 remote-as 64512 no auto-summary
So we now have a fully working confederation – do we have connectivity? Lets ping R5 from R4
R4#ping 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/140/240 ms
Success! – if we look at the BGP table you can see that the next hop for 5.5.5.5 is R1
R4#sh ip bgp
BGP table version is 9, local router ID is 10.1.41.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 10.1.41.1 0 64512 i
*> 3.3.3.3/32 10.1.41.1 0 64512 i
*> 4.4.4.4/32 0.0.0.0 0 32768 i
*> 5.5.5.5/32 10.1.41.1 0 64512 65501 i
*> 10.1.12.0/24 10.1.41.1 0 0 64512 i
*> 10.1.13.0/24 10.1.41.1 0 64512 i
*> 10.1.23.0/24 10.1.41.1 0 64512 i
* 10.1.41.0/24 10.1.41.1 0 0 64512 i
*> 0.0.0.0 0 32768 i
For more information on BGP Confederations – you can read more about them in the excellent document BGP Case Studies from Cisco
Ok now we will move onto Route Reflectors, I will use the same topology and re-configure R2 to be a Route Reflector. All devices will be in AS64512 but due to the rules of iBGP you will require a full mesh in order for routes learned by R1 to be passed to R3 – if R2 is configured as a Route Reflector it will reflect the routes learned from R1 onto R3.
Route Reflector Configuration
First remove all the BGP confederation configuration.
To configure a Route Reflector is very simple, you simply use the command route-reflector-client in the neighbor statement to each device, in our case it will be configured on R2 pointing to R1 and R3. The peerings on R4 & R5 can remain as they will still be pointing to AS64512. I will simply issue the command no router bgp 2 on R1 – the new config is as below.
R1#sh run | sec router bgp router bgp 64512 no synchronization bgp log-neighbor-changes network 1.1.1.1 mask 255.255.255.255 network 10.1.12.0 mask 255.255.255.0 network 10.1.41.0 mask 255.255.255.0 neighbor 10.1.12.2 remote-as 64512 neighbor 10.1.41.4 remote-as 65500 no auto-summary
I will do the same on R3 – no router bgp 3 and the new config is as below
R3#sh run | sec router bgp router bgp 64512 no synchronization bgp log-neighbor-changes network 3.3.3.3 mask 255.255.255.255 network 10.1.13.0 mask 255.255.255.0 network 10.1.23.0 mask 255.255.255.0 neighbor 10.1.13.5 remote-as 65501 neighbor 10.1.23.2 remote-as 64512 no auto-summary
Now the final piece in the jigsaw is R2 this will have the route-reflector configuration. Before I implement the route reflector configuration this is the topology we are now working with.
R1, R2, R3 are all peered using iBGP there is no full mesh so any routes learnt by R3 e.g 5.5.5.5/32 from R5 will not be passed to R1 – lets check that.
R1#sh ip bgp
BGP table version is 7, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*>i2.2.2.2/32 10.1.12.2 0 100 0 i
*> 4.4.4.4/32 10.1.41.4 0 0 65500 i
* i10.1.12.0/24 10.1.12.2 0 100 0 i
*> 0.0.0.0 0 32768 i
*>i10.1.23.0/24 10.1.12.2 0 100 0 i
* 10.1.41.0/24 10.1.41.4 0 0 65500 i
*> 0.0.0.0 0 32768 i
As expected R1 does not have any knowledge of that route because R2 is not advertising it. Let’s make R2 a route reflector and see if it changes.
R2(config)#router bgp 64512 R2(config-router)#neighbor 10.1.12.1 route-reflector-client *Mar 1 07:58:30.842: %BGP-5-ADJCHANGE: neighbor 10.1.12.1 Down RR client config change *Mar 1 07:58:35.062: %BGP-5-ADJCHANGE: neighbor 10.1.12.1 Up R2(config-router)#neighbor 10.1.23.3 route-reflector-client *Mar 1 07:58:47.538: %BGP-5-ADJCHANGE: neighbor 10.1.23.3 Down RR client config change *Mar 1 07:59:09.974: %BGP-5-ADJCHANGE: neighbor 10.1.23.3 Up
You can see that once you apply the command the neighbor goes down. The BGP neighbor is re-established and R2 will now reflect the routes.
I enabled debug ip routing on R1 to see any changes happen and you can see that the 5.5.5.5/32 network has been received.
R1#debug ip routing IP routing debugging is on R1# *Mar 1 07:59:34.702: RT: add 5.5.5.5/32 via 10.1.13.5, bgp metric [200/0] *Mar 1 07:59:34.706: RT: NET-RED 5.5.5.5/32
So the final test is can R4 still ping R5?
R4#ping 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/137/184 ms
Yes!
So what is the difference?
So in conclusion BGP Confederation vs Route Reflector – these are two different methods for solving the same problem. They were both developed at the same time when BGP was written by two different development teams and both methods were kept in BGP. Which one is better? Well route reflectors are much easier to configure and it is a lot easier to mess up a config for confederation. Everyone has their favourite, but for the CCIE lab exam you just need to be aware of them both and when asked to configure one or the other you should know how.
Hello sir ,
Nice explanation today after going through your example i have cleared my lots of doubts .
Thank you.
Glad it helped –
Roger
what a smart explanation.
Thanks and GOD BLESS YOU!
Thank you Roger! You are by far one of the best out there. God bless you.
Thanks glad it helped