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

[Douglas Fischer]

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


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210119/642c3482/attachment.htm>