BGP Route Reflector

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

We need a lap for ibgp leaf-spine router reflector

Hello Duong

Can you clarify what it is that you are requesting? Can you give us a little more information about the architecture you are trying to create and for what purpose?

Also keep in mind that if you have a suggestion for a lesson, you can always go to the Member Ideas page shown below, and make a suggestion for a particular lesson you’d like to see. You may find that others have made similar suggestions and you can add your voice to theirs.

In the meantime, take a look at this Cisco documentation that describes BGP route reflectors and how they can be incorporated into an ACI Fabric in a data center.

I hope this has been helpful!

Laz

we need lap leaf-spine topology with 2 router reflectors

Hello Duong

I forgot to add the link to the Member Ideas page. Here it is:

You can make your suggestion there, and Rene will take a look…

I hope this has been helpful!

Laz

Hello,

In the last example if all the router in each cluster are connected with each other with IGP would that causes any problem ?

Thank you

Hello Chansaravuth

I believe you are talking about this topology, correct?

As with any BGP AS, all routers within an AS must be reachable in order for BGP to function correctly. Whether you use an RR or not, all routers within AS 123 must have routing established between them. This is typically achieved using an IGP like OSPF or EIGRP. So yes, an IGP should run in the AS to ensure reachability between all routers.

I hope this has been helpful!

Laz