BGP Route Reflector

[lagapidis (Lazarus Agapidis)]

Hello Tanmoy

R2 is the route reflector, so if you issue this command in R2, you will get a slightly different output. I labbed it up and got the following:

R2#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  Local, (Received from a RR-client)
    192.168.12.1 from 192.168.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
R2#

You see that you don’t get the “Originator” and the “Cluster ID” information because this is an RR. You will see that information however, on the RR clients. For example, the output for the same command on R3 is the following:

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)
Flag: 0x4100
  Not advertised to any peer
  Refresh Epoch 2
  Local
    192.168.12.1 (inaccessible) from 192.168.23.2 (192.168.23.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.1, Cluster list: 192.168.23.2
      rx pathid: 0, tx pathid: 0
R3#

So you see here that R3 gives an originator of 1.1.1.1 which is the ID of R1. Similarly, the cluster ID shown is that of the RR.

To summarize, you will only see the Originator and the Cluster ID information on an RR client and not on the RR itself.

I hope this has been helpful! Stay healthy and safe!

Laz

[pradyumnayadavgla (Pradyumna Y)]

Hi Rene/Laz,

Q1 Actually i could not understand concept of non-client and if i have a topology and
configuration then how would i recognize that this one is non-client?

[lagapidis (Lazarus Agapidis)]

Hello Pradyumna

A non-client is simply a BGP router with which an RR will create a BGP peering. This peering functions the same way as any other normal BGP peering. However, the way that updates are “reflected” is affected by the role (client or non-client) that a particular router has.

In order to make this clearer, take a look at the following diagram of a single BGP AS:

These routers are all in the same AS, so iBGP is functioning. The RR router is the route reflector, and C1 and C2 are clients of this RR. N1 and N2 are non-clients, but have normal BGP peerings configured with the RR.

Note the following:

• if an update comes from C1, the RR will forward this update to C2, N1, and N2.
• if an update comes from C2, the RR will forward this update to C1, N1, and N2.
• if an update comes from N1, the RR will forward this update to C1, C2, but not N2
• if an update comes from N2, the RR will forward this update to C1, C2, but not N1

The above description abides by the “rules” for sharing routes that are laid out in the lesson.

How would you know that a particular router is a client or non-client? Based on the configuration. Within the RR itself, the following BGP commands would make a particular neighbor a client:

R2(config)#router bgp 123
R2(config-router)#neighbor 192.168.12.1 remote-as 123
R2(config-router)#neighbor 192.168.12.1 route-reflector-client

Alternatively, if the “route-reflector-client” command is absent, then that particular neighor is a non-client. Another term for non-client is simply an iBGP peer. The term non-client is only used in order to distinguish between RR clients and those that are regular iBGP peers.

I hope this has been helpful!

Laz

[pradyumnayadavgla (Pradyumna Y)]

Thanks Laz for this clear and well explanation.

[anvesh199 (sai anvesh u)]

Hi Rene

Its nice topic for starters but it would have been great if there were a bit more in-depth discussion on different types of RR scenarios and clusters

Regards
Sai

[lagapidis (Lazarus Agapidis)]

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.

Member Ideas | NetworkLessons.com

Thanks again!

Laz

[monsterunni835 (Unni P)]

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

[lagapidis (Lazarus Agapidis)]

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:

MPLS Labels and Devices

Hello Tanmoy The Route Reflector (RR) used in MP-BGP within an ISP’s MPLS network is used in a similar way to it’s purpose within a regular BGP AS. Within an AS, iBGP requires that all iBGP routers have full mesh neighbor adjacencies. This means that in an AS with, say, 10 iBGP speakers, we’ll need N(N-1)/2 or 10*(10-1)/2 = 45 adjacencies. As AS networks increase, these adjacencies increase in number almost exponentially, which is a problem for scalability. The solution for this is an RR. …

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

[saihtam1993 (Mathias H)]

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.

[lagapidis (Lazarus Agapidis)]

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:

BGP Route Reflector

Hello Pradyumna A non-client is simply a BGP router with which an RR will create a BGP peering. This peering functions the same way as any other normal BGP peering. However, the way that updates are “reflected” is affected by the role (client or non-client) that a particular router has. In order to make this clearer, take a look at the following diagram of a single BGP AS: [image] These routers are all in the same AS, so iBGP is functioning. The RR router is the route reflector, and C1 an…

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

[saihtam1993 (Mathias H)]

Hi Laz,

I understand it now, thank you for your explanation.

[abhity150890 (Abhishek T)]

Hi Rene,

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

[lagapidis (Lazarus Agapidis)]

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

[joseph (Joseph E)]

Hi Guys,

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

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 ?

[lagapidis (Lazarus Agapidis)]

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:

Route Reflectors cluster ids

Hi Victor, It kinda depends on the design. Both options are possible…you could have two RRs in the same cluster so they’ll have the same cluster ID. You can also have two RRs, one for each cluster so they’ll have a different cluster ID. The second option is probably the most common one, there are some scenarios where you can have reachability issues when you have two RRs with the same cluster ID…maybe something for another lesson Rene

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

BGP Route Reflection and Multiple Cluster IDs

I hope this has been helpful!

Laz

[sims]

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

[lagapidis (Lazarus Agapidis)]

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

[pradyumnayadavgla (Pradyumna Y)]

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?

[lagapidis (Lazarus Agapidis)]

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

[shxmi1 (Bruce M)]

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