<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-signature">
      <pre>On 15/12/2018 14:16, Ondrej Zajicek wrote:</pre>
    </div>
    <blockquote type="cite"
      cite="mid:20181215131617.lzamrh4ijyzimv56@feanor.crfreenet.org">
      <pre class="moz-quote-pre" wrap="">On Fri, Dec 14, 2018 at 06:54:41PM +0100, Noémie Clémençon wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Hi all,

We are using Bird v2.0.2 as a route-server, and I have a question about the use of i-BGP sessions on a Bird RS.

We have the following topology : 2 RS (RS1 and RS2) are connected to several peers, and some of those peers are connected to only one RS.
In order to get the same amount of prefixes on both RS, a i-BGP session was created between RS1 and RS2.

                          i-BGP
               RS1  -----------------  RS2
                |                       |
                |                       |
              Peer1                   Peer2



This topology was working really well between a Bird 1.6.3 and a Cisco ASR, and we were able to announce the prefixes without the RS AS
in the AS-Path and with the proper next-hop regardless of from where the prefixes were learnt (RS1 or RS2).
To clarify, if Peer1 was peering with RS1, and learning the prefixes of someone, Peer2, who was peering exclusively with RS2, Peer1 would get the prefixes
with the as path starting with the AS of peer2 and the next-hop would be peer2 router IP.

We wanted to use the same topology with a Bird 2.0.2 in place of a ASR, but it seems to be treating i-BGP prefixes differently. With a bird 2.0.2, Peer1 is receiving
the prefixes from Peer2 however the prefixes are announced with the RS AS in the AS path and the next hop is the RS1 IP, hence the prefixes were unusable by Peer1.

We are using the following tweak to correct the next hop : the use of 'direct' and 'gateway direct' has corrected the next hop IP.
Below an example of the configuration we used.
We still haven't found a solution for the AS path.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Hi

These are two separate issues. The first one (ASN), was originally an
intentional change, will be reverted in the next release, you can use
attached patch.

The second one seems like an unintentional change, you can workaround it
either by 'direct' ('gateway direct' is not necessary as that is default
when 'direct' is set), or just with 'next hop keep' that prevent any
changes to bgp_next_hop. In the next release, 'next hop keep' will be
default for route reflectors and route servers.

</pre>
    </blockquote>
    <pre>Hi, 

Thank you for the explanation, we will try with the patch to see if 
it solves our problem. 

We did try adding 'next hop keep' on the I-BGP sessions to force the next hop 
but the RS kept sending the route with the RS IP as a next hop. Maybe we got the 
configuration wrong somewhere.

Do you have an idea of the date for the next release of bird 2 ? 

Kind regards,
Noémie
</pre>
  </body>
</html>