BGP Route Reflector

Hello Sai

Thanks for the feedback. You can also go to the Member Ideas section of the site where you can share your lesson-specific or future lessons ideas and feedback.

Thanks again!

Laz


Can any one please help to know more about this RR configiuration?

Hello Unni

This topology shows an MPLS network where two of the P routers found within the core MPLS network function as route reflectors. This is done for BGP scalability within the MPLS network.

RRs either in a conventional or an MPLS network, are there to allow BGP to be scalable within a large network. It reduces the number of peerings necessary within the network. More on this can be found at the following post:

Now there are various ways that you can implement RRs within the MPLS network and these depend upon various factors. In this topology, it looks like the RRs are actually P routers that act both as RRs and as routers forwarding traffic as well. It is possible to have dedicated RRs that only function as RRs and don’t actually forward traffic. Other options include using the RRs for both IPv4 and VPNv4, or using them only for VPNv4 traffic.

A very comprehensive explanation of these concepts and the options available can be found at this link.

I hope this has been helpful!

Laz

Hi,

The article says “The third rule makes sense, this is our normal IBGP split horizon behavior.” when talking about the 3rd rule, which states that routes don’t get reflected from non-Clients to other non-Clients. What does this have to do with split horizon? I don’t see the part that makes sense as the non-clients can be different devices.

Hello Mathias

When talking about split horizon in the context of BGP, the rule is that iBGP does not advertise prefixes from one iBGP neighbor to another iBGP neighbor. This particular behaviour is futher explained in the iBGP Protocol Explained lesson.

The purpose of this is to avoid routing loops. For eBGP, it is the AS_PATH attribute that is used to avoid routing loops. In such a case, a BGP router will not accept a prefix from another BGP router if it sees its own AS number in it. However, within an AS, the AS number doesn’t change, so we need another mechanism to do this.

The above lesson shows an example of how split-horizon achieves this.

Now because a route reflector kind of changes the whole idea of full mesh BGP neighbors within an AS, it also changes the way iBGP routers inform each other of prefixes. However, the third rule essentially upholds the split horizon rule for situations where the iBGP routers involved are not RR clients. In other words, if you have two non-clients, and an RR, what you essentially have is a normal BGP topology, so the split horizon rule is simply upheld.

Take a look at this post as well that might help clarify further:

Having said all of this, I believe that there is a slight error in rules 2 and 3. Where it says EBGP it should read IBGP. I will let Rene know so he can confirm, and if so, he can make the changes.

I hope this has been helpful!

Laz

1 Like

Hi Laz,

I understand it now, thank you for your explanation.

1 Like

Hi Rene,

Instead of changing the scenario why can we give next hop-self command in R2 router ?
why will not not work.

Hello Abhishek

You can issue the next-hop-self command for use with the RR in this scenario, but it will serve no purpose. Looking at the topology of this lesson once again:


If R2 was configured with next-hop-self for the 1.1.1.1/32 network, then R3 will send traffic to that destination to R2. If this command was not issued, then the next hop would be the Fa0/0 interface of R1 which is also reachable by R3 due to the IGP that is running. The result is that connectivity is still there for both scenarios.

Remember that the RR doesn’t change the way iBGP behaves, nor does it change the next hop. It only reduces the number of iBGP peerings.

I hope this has been helpful!

Laz

Hi Guys,

Just a quick question regarding the last diagram and multiple RR’s, (I’ve added some detail):

image

I’m just curious with regards to redundancy. Let’s imagine RR2 fails. How would say RR1 become a redundant RR for that cluster containing R3 and R4 ?

Hello Joseph

You can configure each non-RR router to become neighbors with more than one RR. For example, you can configure R3 to be neighbors with RR2 and RR1, and configure both RR2 and RR1 to be RRs for that router. Routes will be shared among all those routers, and if one of the RRs fails, the other continues to share those routes.

It is always best practice to have more than one RR serving a subset of iBGP routers especially in larger AS’es, however, it should be implemented with care. One of the complications involved here is the use of the originator ID. You can find out a little more information about what this is in the Verification section of this lesson. When it comes to multiple RRs however, there are two approaches as far as the originator ID goes.

One is to set both RRs with the same originator ID. All RR’s will receive updates from clients and will reflect them to other RR’s. RR’s with the same cluster-ID will discard these updates, as the cluster-ID matches their own. This is a simple design but may result in sub-optimal routing in some cases.

The other option is to allocate a different cluster-ID to each route reflector. Each RR is in a different cluster, but this still mitigates the single point of failure. Rene writes a bit more about this detail here:

If you want to get really deep into this subject, take a look at this as well:

I hope this has been helpful!

Laz

Hi,

R3#sh ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 * i  1.1.1.1/32       192.168.12.1             0    100      0 i

R3 cannot reach 1.1.1.1
How can I do it without changing next hop address

Thanks

Hello Sims

The reason that R3 cannot reach 1.1.1.1 is because the routing between the three routers within the AS has not been established. Remember, that within an AS, in a production network, all BGP routers must be able to reach each other for BGP to fuction. This is most often accomplished using an IGP but static routing can also be used.

BGP is not being employed here to provide routing capability internal to the AS. The purpose of BGP is not to deliver routing within the AS, but between AS’es. Although iBGP can be used for routing within an AS, it is not efficient nor best practice.

The purpose of this lesson is to understand how BGP shares routes using an RR. If you want to be able to reach 1.1.1.1 from R3, you will have to employ an IGP or static routing. But keep in mind that BGP plays no role in the establishment of such routing.

I hope this has been helpful!

Laz

Hi Laz,

I this topic we discussed two points one is RR client and RR non-client, We can see RR client but RR non-client is not seen so, please mention which would be non-client router if possible?

Hello Pradyumna

In this lesson, both R1 and R3 are clients of the route reflector. There is no non-client router in this configuration. However, non-clients are created simply by creating iBGP neighbors as normal. In other words, you use the neighbor command without the route-reflector-client keyword.

In the Rules section of the lesson, Rene clearly states how the non-clients behave compared to the clients.

I hope this has been helpful!

Laz

Hi Rene,
I have a quick question regarding the route reflector on Cisco router connecting to a third party routers/firewalls. Here is a scenario.
Cisco R1 ----- Cisco R2 ---- Palo Alto Firewall (or Juniper firewall)
It runs iBGP among R1, R2 and firewall. If I make Cisco R2 as route reflector, do I have to configure anything special on Palo Alto (or Juniper firewall) to make it act as client? Is route-reflector-client command line on R2 enough to make any third party router/firewall act as route reflector client?
Thank you
Bruce

Hello Bruce

When configuring route reflectors (RRs) in iBGP, the configuration necessary to make this BGP feature work takes place primarily on the device that will play the role of the RR. As shown in the lesson, the configuration of the iBGP peers is the same as always. So if you were to have a Cisco RR, and a Juniper or Palo Alto iBGP client, the only thing you would have to configure on that client is to specify the RR as the BGP neighbor. No other configuration is required.

I hope this has been helpful!

Laz

1 Like

do i need to make same cluster ID in both RR for same cluster, how do we peer the clients with both RR ??

Whats the recommendation design of multiple RR in same and different clusters ??

Does RR effects the data plane forwarding ??

Hello Narad

For more information about using multiple cluster IDs, take a look at this post:

For multiple RRs, take a look at this post:

RRs are used to share BGP routing information more efficiently than having a full mesh topology. Whether you use an RR or not should not affect the ultamate routing patterns of the data plane.

I hope this has been helpful!

Laz

Hi Rene,

Im not sure if this has been asked already but Im having problems re-advertising route.

R2 has learn’t the route completelym fine from R2 however it cannot pass it on.

Looking at R1, I can see that it has learnt the route from BGP but it has not installed it in the routing table. Please see the below (I’ve excluded part of the show output that we don’t need):

R3#show ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.1.1.1/32       192.168.12.1             0    100      0 1 i


R3#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  1
    192.168.12.1 (inaccessible) from 192.168.23.2 (192.168.12.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

Please can you advise on the above? I’ve got a different router images and tried this on a few of these but they get the same results.

Thanks

Samad Khan

Hello Samad

I’m not completely clear on which router can see which prefixes, and what you were expecting to see. However, keep the following in mind:

iBGP does not advertise prefixes from one iBGP neighbor to another iBGP neighbor. This is called the iBGP split-horizon rule. So in a topology like the one in the lesson, if you have a peering between R1 and R2 and a peering between R2 and R3, R2 will not advertise to R3 anything it learns from R1. There are two solutions to this:

  1. Create a full mesh of iBGP peerings within the AS. This is actually a requirement for iBGP.
  2. Alternatively, you can make use of a route reflector, which avoids the full mesh iBGP peering requirement. This is useful for VERY large ASes.

Thus, as shown in the lesson, the prefix 1.1.1.1/32 does appear in the BGP table of R3.

Now how do you get that into the routing table of R3? Well, one of the prerequisites is to ensure that the next hop IP is in the routing table of the local router. The next-hop IP that appears in the BGP table of R3 for the 1.1.1.1/32 prefix is 192.168.12.1, which is the IP address of Fa0/0 of R1. This next-hop IP address is correct because the specific prefix was learned from R1. However, in the lesson, we haven’t configured any other routing. So R3 has no route to 192.168.12.1, therefore it does not put it in the routing table.

Remember, the purpose of this lesson is to examine how the BGP table is affected by the use of an RR. In a production network, routing between all routers within the AS must be established, typically using an IGP.

I hope this has been helpful!

Laz