BGP Route Reflector

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

Hi Rene,

Would you be able to please explain more regarding the Originator and Cluster List ID?? Also I’ve noticed that my Originator ID is different from the one shown in the example as it used the loopback address 1.1.1.1 instead the physical address 192.168.12.1. Is this a normal occurrence or it supposed to match the IP address in the example??

Appreciate you prompt response.

Hello Joed

Take a look at these NetworkLessons notes on these topics:

According to RFC4456 which describes BGP Route Reflectors, the Originator ID is created by the route reflector itself. It will carry the BGP Identifier of the originator of the route in the local AS. In your particular case, the originator is indeed R1, and based on the method of choosing the BGP identifier or BGP router ID of R1, it should indeed be the loopback address…

I will let Rene know to take a look at the lesson and see if any changes are necessary to ensure that the correct router ID is displayed.

I hope this has been helpful!

Laz

Hi Joed,

I just changed this. It should show the loopback address of R1, as you saw. Thanks for letting us know!

Rene

Hi Rene,

There is no how the three (3) RRs on the topology below to exchange routes received between them to their router-reflector-clients?
image instead of making for example R3 a router-reflector-client of RR3 in case i want to see route from R5 and R6?

Hello Costa

I’m not sure I understand the question, can you rephrase it to clarify?

Thanks!

Laz

Hi,

My quaetion is: I have 3 RR, each RR has 3 RR clients with diferent netwoks, all are in the same ASN. How can I make the 3 RR exchange route so that all the RR client can talk?

A terça, 26/04/2022, 05:32, Lazaros Agapides via NetworkLessons.com Community Forum <forum@networklessons.com> escreveu:

Hello Costa

Thanks for the clarification! The full mesh iBGP adjacencies that we would normally have to have within an AS are no longer necessary when we use RRs. However, all the RRs within the AS must still adhere to this rule. So, by ensuring that the RRs are configured with full-mesh iBGP adjacencies, we ensure that all routes shared by the clients with their RRs will be correctly shared with other RRs within the AS.

I hope this has been helpful!

Laz

HI LAZ,

my lab not working. RRs are full meshed, client do not exchange routes.

Any help?

A quinta, 28/04/2022, 05:34, Lazaros Agapides via NetworkLessons.com Community Forum <forum@networklessons.com> escreveu:

Hello Costa

You’ll have to give us some more information about your topology and your configurations in order for us to help. However, you can start by examining the following:

  1. Is each RR successfully installing the BGP routes obtained from its clients within its own BGP table?
  2. Are the RRs successfully peered with each other as BGP neighbors?
  3. Are the RRs successfully exchanging their own routes with each other?
  4. Does one RR have the routes of the clients of the other RRs in their BGP table?

In other words, try to find out where in the route exchange the update is failing. Let us know some more information, as well as any additional info from your troubleshooting and we’ll be happy to help you further.

I hope this has been helpful!

Laz

Hi lagapides,

Well noted. I will test it.

By the way, is there any material in your website that talks about MPLS L3VPN Inter-AS Option A and B?

Thanks in advance for your return in this regard.

Lazaros Agapides via NetworkLessons.com Community Forum <forum@networklessons.com> escreveu no dia sábado, 30/04/2022 à(s) 07:26:

Hello Costa

When implementing MPLS L3VPNs, there are cases where you may have some remote customer sites in locations where the same service provider cannot serve both sites. The result is that the backbone network that interconnects the sites, has more than one AS, thus some sort of mechanism must be established to allow inter-AS communication to take place without disrupting the VPN.

There are three ways to do this, and they are called Options A, B and C:

  • Option A: Back-to-Back VRFs
  • Option B: MP-eBGP for VPNv4
  • Option C: Multihop MP-eBGP between RR + Labels

Because these topics are outside of the scope of current Cisco certifications at all levels, so a lesson on these is not found on the site. However, Cisco has some good content that may help you out. I’m adding a few links below:

https://learningnetwork.cisco.com/s/article/mpls-l3vpn-inter-as-option-a-part-1
You can also see this Youtube video from INE describing configurations in detail.

I hope this has been helpful!

Laz

Hi,

Should the RR provide a route to RR-clients to reach reflected routes?
E.g. In this lesson, we have this route on R3.

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

Why 192.168.12.1 should be inaccessible for a RR-client ?

Thank you

Ok I got it.

Because BGP RR carry information about BGP routes, and it doesn’t care about internal routing.

Hello Giovanni

The “inaccessible” indicates that the next hop IP, which for that specific prefix is 192.168.12.1 on R1, is not reachable from R3.

Typically, within an AS, you must ensure that you have routing configured between all iBGP routers. In order to do so, you must employ either an IGP like OSPF or EIGRP or static routing.

For the purposes of this lab, however, this was not necessary. We are only examining how BGP advertises networks using an RR. If you configure routing such that all routers can reach each other within the AS then that “inaccessible” indicator will disappear.

It is interesting here, however, that because we are using an RR, R3 is still able to learn about the routes advertised by R1, even though we don’t have routing within the AS configured. This is one of the advantages of the RR, which relays routes learned via iBGP to other iBGP routers.

Remember, however, that in a production network, even when you use RRs, it is necessary to ensure that routing is configured between all routers within the AS. Otherwise, you will have “inaccessibility” problems as you have correctly stated.

I hope this has been helpful!

Laz