I feel what you are looking for is something close to the Anycast concept. I already made some study efforts to put Route-Reflectors in Anycast mode. All RR instances with at least one "equal" Loopback being advertised by the IGP, and the cost of the IGP defining who will reach which RR instance. Yes, it can be something good! It has advantages and the main ones are scenario resiliency combined with simplified configuration on Route-Reflector Clients. But it also has downsides! And what I found most evident was the need to keep the configuration all identical in all RR instances, and also the difficulty of differentiating when a Peer is Down in an RR because it is not in the active Anycast node for that Peer or because he really is Down. Anyway, if you intend to go that route, one thing is for sure... Design your Route-Reflector scenario to be completely Off-Path. This might sound something like, "aaahhh... that's one more piece to complicate the picture." But by implementing your IGP well and trusting it, taking the RR out of the Path will be a relief later on. Em sex., 16 de jun. de 2023 às 04:31, Benoit Chesneau < benoitc@enki-multimedia.eu> escreveu:
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@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@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
-- Douglas Fernando Fischer Engº de Controle e Automação