But you wrote that for scaling there are load balancers to balance sessions among different bird instances. So VRRP + Load Balancer will give you what you want. You can also try to bind several birds to a single address in linux (probably little patchin is required to set socket options) and linux will balance sessions between them. You may also want to exchange routing information somehow between your bird instances, but I think it also can be solved somehow, a couple of route reflectors for example. I still do not understand what you want to see in Bird itself. I haven't run large IXPs, so I may be not aware of something and would be glad if you explained it in more detail.
On Tue, Jan 19, 2021 at 3:22 PM Douglas Fischer <fischerdoug...@gmail.com> wrote: > > 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
