<div dir="ltr">From what I could see from your questions, the issues you have been facing are more related to the good use of IGP (eg OSPF, ISIS) and redistribution of routes through BGP than with the use or not of route-reflector.<br><br><br><br>If you don't have an IGP "to call your own", something you REALLY trust, that's the first thing you have to address.<br><br>Comment: I don't know why, but in the last few months I've seen a lot of colleagues coming up with ideas like:<br> - "I'm not going to use anything other than BGP. I don't need IGP for anything... I use next-hop-self everywhere.".<br>And it scares me so much. If this is not your case, disregard!<br><br><br><br>Next step is to decide what you are going to redistribute via IGP(OSPF or ISIS) and what you are going to redistribute via iBGP.<br>Each case is different... <br>But for ISPs and ITPs scenarios I usually suggest that OSPF redistribute EXCLUSIVELY the Loopacks subnets and the PTP subnets between the routers themselves (directly connected of internal networks).<br>And in iBGP I recommend redistributing static routes (for specific cases) and external PTP Subnets (Customers, Providers, IXPs).<br>Use, abuse, and trust on your own marking of BGP-Communities and OSPF tags to properly control the filtering and redistribution of these routes.<br><br><br><br>After all this is well defined, here comes the intelligence part in filtering the routes that will or will not be redistributed to each RR-Client, and maybe some aggregation/summarization strategy.<br><br><br><br>I apologize if I sounded too complacent or verbose.<br>I wish your efforts bring good results.<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 20 de jun. de 2023 às 09:05, Oliver Seufer via Bird-users <<a href="mailto:bird-users@network.cz">bird-users@network.cz</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I would like to gather some thoughts on whether I should use a Route Reflector<br>
or not, and if I do need one, what would be the best practice.<br>
<br>
Let's begin with the setup. I have four BGP routers located in two different data centers:<br>
* Each router (r1, r2, r3, r4) has an iBGP session established with the other BGP routers.<br>
* Two routers (r1 and r2) receive a full table from transit providers.<br>
* The other two routers (r3 and r4) receive the best routes (full table) from r1 and r2.<br>
* Additionally, r3 and r4 have peering connections with external parties and<br>
provide a default route via iBGP to other systems.<br>
<br>
Schematic representation of the setup<br>
<br>
data center 1 data center 2<br>
r1 ------------------ r2<br>
\ /<br>
------------------<br>
/ \<br>
r3 r4<br>
<br>
Under normal conditions, I do not require a Route Reflector in this setup.<br>
<br>
However, there are situations where r3 can still reach r1 but not r2 and r4.<br>
Additionally, r1 can still reach r2. In this specific situation, r3 only<br>
receives the best route from r1 and not the learned routes from r2.<br>
<br>
I am aware that I can use a Route Reflector to address this issue, but I am not<br>
entirely certain if it is a suitable solution for my setup. Currently, my plan<br>
is to use r1 and r2 as the Route Reflector Cluster (with next hop self), while<br>
r3 and r4 would connect as non-Route Reflector clients to r1 and r2.<br>
<br>
So, the requirement is for r3 and r4 to always receive a full table.<br>
<br>
Regarding the approach, using a Route Reflector seems like a reasonable<br>
solution in this case. However, there might be alternative and potentially<br>
better solutions available.<br>
<br>
Thanks,<br>
<br>
Oliver<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>