Hi,
What configs are you using towards client and between route servers on
both sides?
On Fri, Dec 14, 2018 at 7:02 PM Noémie Clémençon
<[email protected]> wrote:
>
> 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.
>
> protocol bgp RS1 {
> local as 65001;
> neighbor 192.168.2.1 as 65001;
> ...
> direct;
> ipv4 {
> import ...;
> gateway direct;
> export ...;
> };
> }
>
> Since we never noticed this problem for bird 1.6.3, is this a different
> behavior for Bird 2.0.2 ?
> Or is there a better way to have the intended announcements on both RS ?
> I-BGP sessions between RS are really handy in case of failure, and we would
> like to keep this topology.
>
>
> Kind regards,
> Noémie
