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