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

[Ondrej Zajicek]

On Tue, Jan 19, 2021 at 09:17:57AM -0300, Douglas Fischer 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.

Hi

That is an interesting idea. Seems like it is something that could be
done outside of BIRD, just by firewall tricks with ARP (at least with
static balancing). Perhaps something as simple as dropping ARP requests
(on each route server) from clients outside of allowed subset of clients.

But personally, if i had to run multiple multi-BIRD  setup on multiple
servers, i would just assign them different IPs and announce the
appropriate server IP to each group of users (instead of trying to
pretend it is one IP / one server). It can be even done preemptively -
have one RS IP for each say 64 clients, and then assign multiple IPs
to real route servers according to needs and resources.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."