BGP – Part 2: reflecting, confederating, grouping and self

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.

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, 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.

BGP route reflectors

So, on R1 we set the following config:

r1

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:

BGP neighbor statements

BGP neighbor statements

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”

sh ip route

sh ip route

Once we add in AS 200 and configure it with the relevant IP addresses as below

BGP eBGP peers

We can start joining the two AS’s together. The configs are very similar to how we did it in part one.

BGP configuration

R2 and R3’s routing table looks good:

BGP routing

BGP routing

And both can ping the 15.1.1.0/24 IP addresses.

But what about R1?

Well, it’s not seeing the 11, 14 or 15 networks…

BGP routing

We can see from R2 and R3 that they are being advertised:

BGP advertisements

And we can confirm that R1 is receiving them:

BGP advertisements

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 it sees R2 as the next hop for the 11 and 15 networks by adding a line in to the bgp process on R2:

BGP next-hop-self

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:

BGP next hop self

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.

bgp ping

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

bgp sub-optimal routing

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:

BGP peer-groups

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”

BGP peer group

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.

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.

BGP confederations
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 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.