Following on from part 1, where we covered the basics of BGP, including iBGP and eBGP peering, we are going to look at some more advanced features, such as route reflectors, next-hop-self, peer groups and confederations, before looking at BGP attributes and summarization in part 3.
Within an iBGP, there is a requirement that all peers be fully meshed (router A connects to router B and to router C, router B has another connection to router C, and we would need neighbor statements for each router on each other router). This can result in higher bandwidth and CPU usage than is necessary. Thankfully there is a way around this, routers can act as a route reflectors. One can be a server, and the others can act as route reflector clients.
Here we are going to use R1 as a route-reflector server.
So, on R1 we set the following config:
Here we set R2 (10.2.1.2) and R3 (10.3.1.2) as route-reflector-clients. Notice that we need to advertise the networks, including the loopbacks.
The configurations on R2 and R3 look like this:
Notice that on R2 I have advertised the main network, and the loopback network, whilst on R3 I have only advertised the loopback network. Despite this we still have full reachability between R2 and R3 – shown here with the outputs from “sh ip route”
Once we add in AS 200 and configure it with the relevant IP addresses as below
We can start joining the two AS’s together. The configs are very similar to how we did it in part one.
R2 and R3’s routing table looks good:
And both can ping the 220.127.116.11/24 IP addresses.
But what about R1?
Well, it’s not seeing the 11, 14 or 15 networks…
We can see from R2 and R3 that they are being advertised:
And we can confirm that R1 is receiving them:
But here we can also see that the routes are pointing to the far side of the network for reachability.
What we need to do is change how R2 advertises its connected networks.
We can change the routing table on R1 so that it sees R2 as the next hop for the 11 and 15 networks by adding a line in to the bgp process on R2:
Notice that we have added the line “neighbor 10.2.1.1 next-hop-self”, and now the routing table of R1 looks like this:
You can see that the preferred route (marked “*>”) for the 11 and 15 networks now pass through the interface on R2 that is closest to R1. A ping confirms that it is working.
Similar changes were then made on R3 for network 18.104.22.168/24. It is interesting though that after making the changes to R3, that R1 prefers the router to 22.214.171.124 through R2
This is clearly sub-optimal, but we’ll save how to fix this in part 3 of this series.
Say we have a number of BGP peers that have identical settings, we can set up a peer-group for simplicity. the bonus here is that updates to a peer-group get sent simultaneously, rather than individually.
Keeping with our current set up we can move R2 and R3 into a peer-group on R1. so on R1 we configure the following:
Then using the “no neighbor <ip address> remote-as 100” command we remove the two neighbors (R2 and R3).
We can then add them back, this time assigning them to the peer group “PeerGroup1”
This is very useful if you have a large number of peers with identical settings. Note that you can’t mix and match iBGP and eBGP peers in a peer-group. But you can have one peer-group for internal, and one for external peers.
The final topic in this post is BGP confederations. Confederations are another method (similar to route-reflectors) that alleviate the necessity for fully-meshed routers within an iBGP environment.
Confederations are really an AS within an AS and are often referred to as sub-AS’s.
In the above example, we have R1 in AS 100, R2 in AS 200 and R3 in AS 500. Both R1 and R2 are members of AS 300.
The configuration is not very complex. R2 would look like this:
R2(config)# router bgp 200 R2(config-router)# bgp confederation identifier 400 R2(config-router)# bgp confederation peer 100 R2(config-router)# neighbor 10.1.1.1 remote-as 100 R2(config-router)# neighbor 126.96.36.199 remote-as 500
On R3 we would set the config as follows:
R3(config)# router bgp 500 R3(config-router)# neighbor 188.8.131.52 remote-as 400
So R3 will peer with the parent-as (the confederation identifier) and not with the sub-AS of 200.
So that wraps up part 2, in which we have covered route reflectors, confederations, peer groups and the next-hop-self. In part 3 we will look at BGP attributes, summarization, dampening, and backdoors.