In my setup everything is ok. I made 4 namespaces for peera, peerb, rs1 and rs2 and joined them with one bridge network. Here is route views on client networks. As you can see - the next hop is ok on them.
peera:
bird> show route all
Table master4:
192.168.2.0/24 unicast [direct1 00:49:56.054] * (240)
dev veth0
Type: device univ
10.0.2.0/24 unicast [bgp1 01:26:25.953 from 192.168.2.1] *
(100) [AS65124i]
via 192.168.2.47 on veth0
Type: BGP univ
BGP.origin: IGP
BGP.as_path: 65001 65124
BGP.next_hop: 192.168.2.47
BGP.local_pref: 100
10.0.1.0/24 unicast [s1 01:06:02.606] * (200)
dev lo
Type: static univ
peerb:
bird> show route all
Table master4:
192.168.2.0/24 unicast [direct1 00:51:01.757] * (240)
dev veth0
Type: device univ
10.0.2.0/24 unicast [s1 01:11:43.140] * (200)
dev lo
Type: static univ
10.0.1.0/24 unicast [bgp1 01:27:14.489 from 192.168.2.2] *
(100) [AS65123i]
via 192.168.2.45 on veth0
Type: BGP univ
BGP.origin: IGP
BGP.as_path: 65123
BGP.next_hop: 192.168.2.45
BGP.local_pref: 100
The only issue here is that bird2 will prepend as on the path peerb ->
rs2 -> rs1 -> peera. That logic I have already asked to fix in this
mailing list.
On Fri, Dec 14, 2018 at 10:15 PM Noémie Clémençon
<[email protected]> wrote:
>
> Configuration toward client :
>
> protocol bgp PeerA {
> local as 65001;
> passive on;
> neighbor 192.168.2.45 as 65123;
> default bgp_local_pref 1000;
> ipv4 {
> import keep filtered on;
> import limit 1001 action disable;
> receive limit 1001 action disable;
> export filter {ix_out_rs(id,65123);};
> import filter
> {clear_no_export();community_in();pfx65123_v4_in();reject;};
> };
> rs client;
> }
>
>
> Configuration between RS (on bird 2.0.2)
>
> protocol bgp RS2 {
> local as 65001;
> neighbor 192.168.2.2 as 65001;
> direct;
> ipv4 {
> import filter rs_in;
> import keep filtered;
> gateway direct;
> export filter rs_out;
> };
> }
>
>
> Configuration between RS (on bird 1.6.3)
>
> protocol bgp RS1 {
> local as 65001;
> neighbor 192.168.2.1 as 65001;
> import filter rs_in;
> export filter rs_out;
> }
>
> I didn't include the filters, since they are only used to add/remove
> community or exclude prefixes.
>
> Thanks for the help,
> Noémie
>
> On 14/12/2018 20:17, Alexander Zubkov wrote:
>
> 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
>
>
peera.conf
Description: Binary data
rs1.conf
Description: Binary data
peerb.conf
Description: Binary data
rs2.conf
Description: Binary data
