Route server on a Bird2.0.2

2018-12-14 Thread Noémie Clémençon

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



Re: Route server on a Bird2.0.2

2018-12-14 Thread Alexander Zubkov
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
 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



Re: Route server on a Bird2.0.2

2018-12-14 Thread Noémie Clémençon

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
 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




Re: Route server on a Bird2.0.2

2018-12-14 Thread Alarig Le Lay
Hi,

Why are you doing iBGP between your RS in an IXP context?

-- 
Alarig


Re: Route server on a Bird2.0.2

2018-12-14 Thread Alexander Zubkov
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
 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
>  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 rega