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

[Kees Meijs | Nefos]

And what about multiple peering sessions with multipath routing?

Cheers,
Kees

On 19-01-2021 15:17, Douglas Fischer 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 
> <green at qrator.net <mailto: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 <mailto: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/5c2b720b/attachment.htm>