MultiBird on L2 - A crazy idea for Fail Over y and Load Balancing

Alexander Zubkov green at qrator.net
Tue Jan 19 14:48:04 CET 2021


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
<fischerdouglas at 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



More information about the Bird-users mailing list