Understanding BGP Route Reflection headers

Introduction

In BGP, more specifically eBGP, the AS_PATH is the main loop prevention mechanism. When an AS sees its own AS in the AS_PATH, it knows it's a potential loop and discards the UPDATE message.

However, there's no such thing for iBGP so we had to come up with something else called split horizon rule. This rule states that a route learnt by an iBGP neighbour is not advertised to another iBGP neighbour with the idea that iBGP neighbours should be in full mesh and if it's not, because things may be unpredictable, it's better to be on the safe side and not let such route propagate.

Nevertheless, there are circumstances where the engineer knows it's safe for the route to be advertised to an iBGP peer and the mechanism to "disable" split-horizon rule for specific routers is known as route reflection.

In this article, I already assume, you understand the basics of BGP and route reflectors and will go a little bit more in-depth into BGP headers.

F5 Routing module supports BGP and Route Reflection described in this article with similar commands.

However, I'm using Cisco routers here because they're already integrated with GNS3 emulation tool I used for this test.

Topology and Initial Config

In case you want to follow along and test yourself, here's the topology I used:

Initially, our test prefix (150.165.250.0/24) coming from AS 8888 will be our guinea pig here.

As shown in the red arrows above, I configured a loopback interface (Loopback1) to emulate a real prefix advertised from another router.

Test 1: Advertising prefix from AS 8888 to 65000 with no Route Reflectors

I'm now advertising 150.165.250.0/24 from R1 to R2 (AS 65000):

Prefix is advertised from R1 (1.1.1.1) to R2 (2.2.2.2):

And indeed we see the prefix in R2's route table:

Because R2 received route from an eBGP peer, R2 (2.2.2.2) is still allowed to advertise it to R3 (3.3.3.3):

For this reason, we also see prefix in R3's route table:

However, due to split horizon rule, because R3 received a route from an iBGP peer (R2) as opposed to eBGP, it will not pass it on to R4:

If R4 didn't receive it, R5 doesn't have the prefix too.

Test 2: R3 as Route Reflector

For this test, I configured R4 as route reflector client of R3:

Notice that now the adjacency restarting with TCP connection being closed:

And then re-established:

There are even a couple of keep-alive message but then the UPDATE message with 150.165.250.0/24 to R4 finally comes through:

The other 2 empty UPDATE messages are just end-of-rib markers to confirm there will be no further prefix update messages and are described in RFC2734.

We can now confirm R4 now has the BGP prefix:

However, I want to highlight 2 new PATH attributes in the last UPDATE picture above that were introduced and that are different from previous UPDATE messages from Test 1: CLUSTER_LIST and ORIGINATOR_ID.

ORIGINATOR_ID contains the Router ID (RID) of the owner of the route reflector cluster, i.e. where route reflection was first configured (R2 in this case).

CLUSTER_ID is the list of all the clients in the route reflector cluster where this update went through, i.e. only R3 (3.3.3.3) in this case.

Test 3: Adding R5 as Route Reflector Client

Notice that R5 still doesn't have the prefix:

We now need to make R5 as route reflector client of R4:

ORIGINATOR_ID remains the same as the owner of this cluster didn't change (R2), but CLUSTER_LIST now has R4 listed as another client where update passed through:

And we can confirm that R5 now has the prefix:

We can then conclude that ORIGINATOR_ID and CLUSTER_LIST are loop prevention mechanisms that can be used to identify if the prefix is being looped back to the same cluster. If local RID is found in CLUSTER_LIST, UPDATE message can be safely discarded as loop.

BGP route reflection is described in RFC2796.