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 <fischerdoug...@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
