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: santi...@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."
