As I mentioned initially, my focus was on "large environments of IXPs". Considering that, L3 anycast does not apply very well to that scenario. (I don't know any IXPs that use Route-Servers outside of the MPLA-LAN of the IXP.)
Using VRRP is an excellent method to provide fail-over on L2. (I used it a lot on several application scenarios). But it does not provide load-balancing, just fail-over. Considering "large environments of IXPs", and the fact that even on Bird 2, the multi-thread limitation is not completely solved. The solution for that is Load-Balance. MultiBird does it VERY WELL. But until now we(at least me) have seen only "single-host" based solutions, using nat/forwarding connections. With this suggestion, using L2 load-balancing based on MAC-IP-Mapping manipulations, is possible to remove the "single-host" point of failure. Em ter., 19 de jan. de 2021 às 10:48, Alexander Zubkov <gr...@qrator.net> escreveu: > Hi, > > You can use VRRP or alike protocol on L2 or dynamic routing with > anycast on L3 for reliability. I do not see what you want in Bird. > Could you explain more? > > On Tue, Jan 19, 2021 at 1:26 PM Douglas Fischer > <fischerdoug...@gmail.com> wrote: > > > > I was studying the concepts of multi-bird for large environments of IXPs. > > > > And, beyond the extra complexity that it brings to the environment, one > of the weak points I saw was the fact that all the Bird instances are at > the same box(vm, container, etc...). > > > > A friend mentioned that some tests were made with a LoadBalancer > redirecting the post-nated connections to other boxes. > > But even in that scenario, that load balancer would be a > single-point-of-failure/bottleneck. > > > > So I was remembering Cisco GLBP and Heart-Beat protocol. > > Those protocols inform different Mac-Addresses to the same IPv4/IPv6 > Address, based on the source of the ARP/ND query. > > Making a load-balance/fail-over based on the glue between layer2 and > layer3. > > P.S.: Several scenarios uses that concept. Corosync, Windows Cluster, > Orale RAC, etc... > > > > Considering that concept, and joining it with multibird: > > Would be possible to create groups of sources and assigning different > priorities to those groups on each instance of Bird. > > In this case, each Bird instance could run on a different box, or even > on a different site. > > > > Further than that, on IXPs with a large number of participants, would be > possible to define some affinity between that group of priority based for > example on the facility where those participants are connected. > > > > I have a feeling that this would be especially useful for remote peering > scenarios. > > > > > > Just a crazy idea to share with colleagues. > > Maybe from here, some good thing could rise. > > > > > > -- > > Douglas Fernando Fischer > > Engº de Controle e Automação > -- Douglas Fernando Fischer Engº de Controle e Automação
