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, before looking at BGP attributes and summarization in part 3.
In this post we are going to cover
Route reflectors
Next-hop-self
Peer groups
BGP confederations
Route-Reflectors
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, one router can act as a route-reflector 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 advetise the networks, including the loopbacks.
The configurations on R2 and R3 look like this:
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 15.1.1.0/24 IP addresses.
But what about R1?
Well, its 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 recieving 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.
Next-Hop-Self
We can change the routing table on R1 so that is 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 its working.
Similar changes were then made on R3 for network 14.1.1.0/24. It is interesting though that after making the changes to R3, that R1 prefers the router to 14.1.1.1 through R2
This is clearly sub-optimal, but we'll save how to fix this in part 3 of this series.
BGP Peer-groups
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 cant 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.
BGP confederations
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 12.1.1.2 remote-as 500
On R3 we would set the config as follows:
R3(config)# router bgp 500
R3(config-router)# neighbor 12.1.1.1 remote-as 400
So that wraps up part 2. Next in part 3 we will look at BGP attributes, summarization, dampening and backdoors.