peering between route reflectors

[Benoit Chesneau]

Hi Douglas,

That's good advices, I have considered also using specific rr for customers connections, that's a good idea to use distinct nodes for it with 2 per regions...

However, my description of the issue was lacking some clarity. The purpose of the route reflectors there was to share the routing providing by the local transit to other pops as a backup. 

I have the following infra: 3 POPS linked each others by 1 or more L2 links. Each POP has one or more transit links and different peers:

                R1
              /    \
             /      \
            R2 ---- R3

Each POP share its loopback using OSPF. The problem I

What I would like to do is the following:  when one POP has no more direct route (transit link down, route disabled, ...), it fallback to another pop to get the route

I was thinking to do it by having each node acting as  a route reflector to only share the current pop route to the others. Each nodes would reflect their route to each others.  Is there another pattern to do it? I think I found a way to fix possible conflicts by ensureing the backup has a lower pref. Are there any other consideration or patterns I could use?


Benoît

------- Original Message -------
On Thursday, June 15th, 2023 at 22:24, Douglas Fischer <fischerdouglas at gmail.com> wrote:


> Hello Benoit!
> 
> From what you described, I imagine that there may be a confusion between redundancy and load distribution.
> 
> You mentioned having a route-reflector per pop.
> This is load distribution. Each such route-reflector will process route exchanges with local peers.
> And that is indeed a good thing!
> Because it has positives like the fact that if you have 15-20 Peers in this pop, even if this pop is isolated, the routes between these peers will still be exchanged.
> But it's also something that can be bad!
> Because it will require that you have equipment that is chosen to perform this Route-Reflector function.
> It will also have different configurations to be applied on the routers in the BGP peer part with the Route-Reflector. Each POP a configuration.
> 
> You also talked about establishing neighborhoods between Route-Reflectors.
> This is also part of the concept of load sharing, and this is what will make all POPs aware of all networks.
> 
> But putting a single Route-Reflector on each POP IS NOT redundancy!
> 
> From what I could understand from what you described, if one of these route-reflectors in these POPs becomes inoperative, the rest of the network will continue operating... But during this inoperative time, the exchange of routes between the Peers of the same POP (and with the other POPs on the network) will not occur.
> 
> For you to have REDUNDANCE you would have to have 2 (or more) Route-Reflectors DOING THE SAME ROLE. In your scenario, 2 in each POP.
> 
> And going a little further, and getting into a controversial topic, these 2 sets of Route-Reflectors COULD NOT exchange routes with each other! Precisely to prevent, for example, a malformed route that affects the functioning of one of the Route-Reflectors from being propagated to the other and affecting that other route-reflector as well.
> 
> 
> The recipe that I most often see being used for this type of scenario is to have 2 Route-Reflectors in different geographic positions, positioned in such a way as to be OFF-Path, thus trusting the IGP, and each one of them peering with each network neighbor.
> 
> Em qua., 14 de jun. de 2023 às 17:04, Benoit Chesneau <benoitc at enki-multimedia.eu> escreveu:
> 
> > For redundancy I am thinking to have a router reflector per pop . Each route reflector would peer with each others. The issue is that since each POP has a transit, i have duplicate route and sometimes a loop is created. How can it be prevented?? I tried to put them in the same cluster but it doesn't seem to be enough.
> > 
> > Any idea is welcome :)
> > 
> > 
> > Benoît
> 
> 
> 
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação