<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    And what about multiple peering sessions with multipath routing?<br>
    <br>
    Cheers,<br>
    Kees<br>
    <br>
    <div class="moz-cite-prefix">On 19-01-2021 15:17, Douglas Fischer
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAKEr4RQx_v-OcSSkbn8u+QPPxaWaYT4SWG5mX_sULfssKsN8OQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_default" style="font-family:courier
          new,monospace;font-size:small">
          <div class="gmail_default">As I mentioned initially, my focus
            was on "large environments of IXPs".<br>
            Considering that, L3 anycast does not apply very well to
            that scenario.<br>
            (I don't know any IXPs that use Route-Servers outside of the
            MPLA-LAN of the IXP.)<br>
            <br>
          </div>
          <div class="gmail_default">Using VRRP is an excellent method
            to provide fail-over on L2.<br>
            (I used it a lot on several application scenarios).<br>
            But it does not provide load-balancing, just fail-over.<br>
            <br>
            Considering "large environments of IXPs", and the fact that
            even on Bird 2, the multi-thread limitation is not
            completely solved.</div>
          <div class="gmail_default">The solution for that is
            Load-Balance. MultiBird does it VERY WELL.<br>
            But until now we(at least me) have seen only "single-host"
            based solutions, using nat/forwarding connections.<br>
            <br>
            With this suggestion, using L2 load-balancing based on
            MAC-IP-Mapping manipulations, is possible to remove the
            "single-host" point of failure.</div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">Em ter., 19 de jan. de 2021 às
          10:48, Alexander Zubkov <<a href="mailto:green@qrator.net"
            moz-do-not-send="true">green@qrator.net</a>> escreveu:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
          <br>
          You can use VRRP or alike protocol on L2 or dynamic routing
          with<br>
          anycast on L3 for reliability. I do not see what you want in
          Bird.<br>
          Could you explain more?<br>
          <br>
          On Tue, Jan 19, 2021 at 1:26 PM Douglas Fischer<br>
          <<a href="mailto:fischerdouglas@gmail.com" target="_blank"
            moz-do-not-send="true">fischerdouglas@gmail.com</a>>
          wrote:<br>
          ><br>
          > I was studying the concepts of multi-bird for large
          environments of IXPs.<br>
          ><br>
          > 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...).<br>
          ><br>
          > A friend mentioned that some tests were made with a
          LoadBalancer redirecting the post-nated connections to other
          boxes.<br>
          > But even in that scenario, that load balancer would be a
          single-point-of-failure/bottleneck.<br>
          ><br>
          > So I was remembering Cisco GLBP and Heart-Beat protocol.<br>
          > Those protocols inform different Mac-Addresses to the
          same IPv4/IPv6 Address, based on the source of the ARP/ND
          query.<br>
          > Making a load-balance/fail-over based on the glue between
          layer2 and layer3.<br>
          > P.S.: Several scenarios uses that concept. Corosync,
          Windows Cluster, Orale RAC, etc...<br>
          ><br>
          > Considering that concept, and joining it with multibird:<br>
          >  Would be possible to create groups of sources and
          assigning different priorities to those groups on each
          instance of Bird.<br>
          >  In this case, each Bird instance could run on a
          different box, or even on a different site.<br>
          ><br>
          > 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.<br>
          ><br>
          > I have a feeling that this would be especially useful for
          remote peering scenarios.<br>
          ><br>
          ><br>
          > Just a crazy idea to share with colleagues.<br>
          > Maybe from here, some good thing could rise.<br>
          ><br>
          ><br>
          > --<br>
          > Douglas Fernando Fischer<br>
          > Engº de Controle e Automação<br>
        </blockquote>
      </div>
      <br clear="all">
      <div><br>
      </div>
      -- <br>
      <div dir="ltr" class="gmail_signature"><font size="2"><span
            style="font-family:"courier new",monospace">Douglas
            Fernando Fischer</span><br style="font-family:"courier
            new",monospace">
          <span style="font-family:"courier new",monospace">Engº
            de Controle e Automação</span></font></div>
    </blockquote>
    <br>
  </body>
</html>