BGP Route Reflector

lagapidis · February 11, 2019, 10:30am

Hello Rafael

The following two links direct you to Cisco documentation that includes scenarios of multiple cluster IDs for BGP route reflectors that you might find helpful.

I hope this has been helpful!

Laz

syncope988 · July 26, 2019, 6:01am

Hi Rene and staff,
i lab eBGP and i BGP with the following topology

R1 advertise 172.16.0.0/16 (loopback 0) to PE-3 via eBGP

In AS 65000 RR4 is route reflector
PE-3 advertise 10.0.1.0/24 to RR4 (it is an internal route learned by PE-3; i create it by a static route to null0)

As route-reflector RR4 advertise 10.0.1.0/24 to PE-5 (PE-3 and PE-5 are route-reflector-client)

My question is about 172.16.0.0/16
In RR4 this prefix learned via eBGP between R1 and PE-3 is valid but not best: so RR4 does not advertise this prefix to PE-5
The question is: does PE-5 should have to know about prefix 172.16/16 in some designs ?
The answer is likely yes, is not it ?
So, if PE-5 has to know about this prefix what best configuration could solve this issue ?
Regards

madhu_g1985 · July 31, 2019, 12:12am

Hi Rene,
Very nice lectures!
A request, Is it possible to have some examples covering redundant RR in the same AS please.

Thanks,
M

madhu_g1985 · July 31, 2019, 12:19am

Hi Rene,

“In this topology we have 3 route reflectors, each serves 2 IBGP neighbors. Between the route reflectors we still have to configure full mesh IBGP. It’s possible that a route loops between these route reflectors so when a route reflector sees its own cluster ID, it will drop the route.”

I am trying to understand how a loop can occur between these RRs, as they are non-client to each other. Could you please explain .it.

Thanks,
/M

syncope988 · August 1, 2019, 10:35am

hi,
sorry, i found my issue
regards

lagapidis · August 5, 2019, 6:38am

Hello Madu

Without route reflectors, we have the iBGP split horizon rule which states:

“When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker shall not re-distribute the routing information contained in that UPDATE message to other internal peers. This is split horizon rule use within AS to prevent loops”

Now this rule was introduced because of the fact that in iBGP sessions, the AS path attribute is not modified when propagating an advertisement to another iBGP peer. This is done for obvious reasons, because an iBGP is in the same AS, so this does not change. This behaviour however has the potential for loops in the propagation of the advertisement that can travel among several iBGP peers and could be sent back to the original node that injected the route into the AS in the first place.

The problem can really be seen if the originator node (correctly) withdraws the BGP advertisement. The node may be fooled by a copy of an advertisement received by another node and re-advertised to the originator that just withdrew it, causing a loop.

Now when we use route reflectors, the split horizon rule is violated, which means the above loop scenario is possible. So another mechanism must be introduced which involves the originator ID. When an iBGP router receives a route with its own originator ID, it will not accept the route, and thus avoid receiving advertisements that it originally sent out that were re-advertised back to the originating node, and thus avoiding creating a loop. (whew, that was a mouthful…)

I hope this has been helpful!

Laz

madhu_g1985 · August 6, 2019, 11:02am

Hi Laz,
Thanks for the details on loop prevention in Route reflectors using originator ID. Can you please explain it in terms of cluster ID too , I mean how cluster id is used for loop prevention. I am focussing on the sentence here in the lecture “In this topology we have 3 route reflectors, each serves 2 IBGP neighbors. Between the route reflectors we still have to configure full mesh IBGP. It’s possible that a route loops between these route reflectors so when a route reflector sees its own cluster ID, it will drop the route” . How can a loop exist between route-reflectors? Since router-reflectors are not clients to each other, IBGP between them won’t advertise the prefixes it learns from its clients, or non-clients to other route-reflectors - So how come a loop arise there? If arises, how is cluster id used to prevent it ? Sorry so many questions

Thanks,
M

lagapidis · August 7, 2019, 10:34am

Hello Madhu

As you mention, each cluster ID is discrete, so you won’t have one client sending an update to an RR that it is not a neighbor with. In this case, you will not have an issue with loops. However, it is possible to set up two route reflectors with the same cluster ID. This allows for redundancy of RRs within a single cluster. This is the case where an RR will see its own cluster ID and will ignore the update.

For example, let’s say R1 and R2 are RRs in cluster 1.1.1.1. Both R1 and R2 receive routes from R3 and R4 which are clients in this cluster. (Note that clients don’t make use of cluster IDs, but it is only the RRs that do so.) R1 as an RR will share its info with R2 and R2 will share its info with R1. Both will share these routes and will append the cluster ID. In this case, the cluster ID of both routers is the same, so in order to avoid a loop, they will ignore the updates.

I hope this has been helpful!

Laz

madhu_g1985 · August 7, 2019, 10:50am

Excellent , Thanks Laz for making it clear.

Regards,
Madhu.

harshitha.gudur89 · August 16, 2019, 6:14pm

Can you explain route reflector between client cluster and non-client cluster ?

can a single cluster router connected to mulitple route reflectors ?

nitayp1 · October 16, 2019, 8:30am

Hi Rene,

If the RR (RR1) sets the Originator-ID for the client that advertised him some prefixes, and somehow those prefixes are learned again through different RR (RR2), how could the client know what is his Originator-ID that derived from RR1 so that he could ignore that loop advertisement?
(and the same for RR2 of course)

lagapidis · October 17, 2019, 5:00am

Hello Nitay

Take a look at the following two posts that deal with Originator ID and Cluster ID.

I hope this has been helpful!

Laz

nitayp1 · October 17, 2019, 5:41am

Thanks Laz,

I was asking about the Originator-ID and the answer I was looking for was that the Originator-ID is derived from the Router-ID of the RR’s neighbor (Client) and he knows it from the BGP Identifier field in the Open message of BGP.
That way the clients sees routes with the same Originator-ID as their Router-ID (by comparing them to each other) and that’s how they will prevent a routing loop.

that’s pretty same to the Cluster-ID’s mechanics for preventing routing loops but when I asked that question I coulnd’t figure out the details from where the Originator-ID was created and by which method the clients will use that value in the route to to detect a loop beacuse while the Cluster-ID is created on the RR himself, the Originator-ID doesn’t being created on the Clients themselves and I couldn’t figure out how the Originator-ID would detect a loop that way while the Cluster-ID mechanism was so simple to understand.

shahid.ikram · November 29, 2019, 4:04pm

Hi
I would if someone has done BGP RR design with shadow RR and Optimum RR Design for DC?
Would like to see the configuration working.

thanks
Muhammad

lagapidis · December 2, 2019, 7:57am

Hello Muhammad

Take a look at this post to get a better understanding of shadow RR.

You can also find some best practices designs for BGP route reflectors for service network architectures at this Cisco documentation.

I hope this has been helpful!

Laz

lugg15 · February 3, 2020, 5:08pm

Hi Team,

As we know, the RR is needed to get rid of the full-mesh iBGP peers - without a full-mesh, routes learned from an iBGP peer are not sent to another iBGP peers in order to avoid loops.

If we implement RR, we only need to peer with the route-reflector. When an iBGP client-peer advertises a route, the RR reflect the update to all iBGP routers.

My question is related to the Data Plane traffic, could you please explain to me why the route reflector is not in the data plane path and how it works? I think this is the desire case for the RR not being in the data plane path. Please advise.

Regards,

lagapidis · February 4, 2020, 6:52am

Hello Luis

What you are referring to is called “out-of-band rout reflectors”. These are BGP routers that function as route reflectors that are not actually in the data path. This allows them to have all of their resources dedicated to managing the sharing of iBGP information within an AS.

Out-of-band route reflectors are usually implemented in extensively large AS’es, with tens or even hundreds of iBGP peers. You wouldn’t normally find such a configuration within an enterprise network unless it belonged to an extensively large multinational corporation with multiple large sites, or on the Internet itself. This is not a requirement, but it is a good idea to implement in such large networks.

You can find out more about out-of-band route reflectors at this Cisco documentation.

I hope this has been helpful!

Laz

ajansmit · February 13, 2020, 1:57pm

Hi.
I created a topology and every router is peering with a route-reflector router only, it is working fine, with an exception, the route-refletor router is not reflecting the default-information originate received from the border router. The router-reflector router reflect the default route?
Thanks.

lagapidis · February 14, 2020, 7:05am

Hello Andre

In order to have a route reflector, or an iBGP neighbor receive originated default route information from another router, you must use the default-information originate command. But if the default route on that router is statically assigned, you must also include the redistribute static command.

Other than the default-information originate command, there are several other ways to redistribute default routes in BGP. These include:

the network 0.0.0.0 command, which will inject the default route into BGP if the default route is currently present in the routing table
redistribution, which will inject the default route into BGP again, only if it is found in the routing table, and if it has been learned by a specific source protocol that is being redistributed
by using the neighbor X.X.X.X default-originate command which has various other conditions that are further described in this Cisco Command Reference documentation.

I hope this has been helpful!

Laz

tanmoymm23 · March 29, 2020, 1:16pm

Hi Laz

if i put sh ip bgp 1.1.1.1 on R2 , in the output , the originator will be 192.168.12.1 and cluster list will be 192.168.12.2.

Please check and let me know if the above is correct or not.

Thanks a lot in advance.