Re: Route server on a Bird2.0.2
Hi, Next hop should not be altered on iBGP session. Perhaps you have some issues that causes it. You can see my previous e-mail where I demonstrated that in simple setup there are no such problem. Can you take some problematic prefix and show how it looks on different directions? Like: on RS2: show route all show route all export RS2 on RS1: show route all protocol RS1 show route all export peerA On Sat, Dec 15, 2018 at 4:10 PM Noémie Clémençon wrote: > > Hi, > > We are using I-BGP between our RS for redundancy. > Not every peer has a session with both RS, or some of them choose > to keep only one session open at a time, so if we want to make sure > every prefixes are propagated to every peer, we need to exchange route > between the 2 RS. > > Regards, > Noémie > > On 14/12/2018 23:16, Alarig Le Lay wrote: > > Hi, > > Why are you doing iBGP between your RS in an IXP context? > >
Re: Route server on a Bird2.0.2
Hi, We are using I-BGP between our RS for redundancy. Not every peer has a session with both RS, or some of them choose to keep only one session open at a time, so if we want to make sure every prefixes are propagated to every peer, we need to exchange route between the 2 RS. Regards, Noémie On 14/12/2018 23:16, Alarig Le Lay wrote: Hi, Why are you doing iBGP between your RS in an IXP context?
Re: Route server on a Bird2.0.2
On 15/12/2018 14:16, Ondrej Zajicek wrote: On Fri, Dec 14, 2018 at 06:54:41PM +0100, 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. 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. 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
Re: Route server on a Bird2.0.2
On Fri, Dec 14, 2018 at 06:54:41PM +0100, 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. 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. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." commit 532116e7e33d80a79e176f043defffbfc2b8d06e Author: Ondrej Zajicek (work) Date: Wed Dec 12 17:36:54 2018 +0100 BGP: Do not prepend ASN in export from non-RS EBGP to RS EBGP When route is exported to regular EBGP, local ASN should be prepended to AS_PATH. When route is propagated by route server (between RS-marked EBGP peers), it should not change AS_PATH. Question is what to do in other cases (from non-RS EBGP, IBGP, or locally originated to RS EBGP). In 1.6.x, we did not prepend ASN in non-RS EBGP or IBGP to RS EBGP, but we prepended in local to RS EBGP. In 2.0.x, we changed that so only RS-EBGP to RS-EBGP is not prepended. We received some negative responses (thanks to heisenbug and Alexander Zubkov), we decided to change it back. One reason is that it is simple to modify the AS_PATH by filters, but not possible to un-modify changes done by BGP itself. Also, as 1.6.x behavior was not really consistent, the final behavior is that ASN is never prepended when exported to RS EBGP, like to IBGP. Note that i do not express an opinion about whether such configurations are even reasonable. diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index 572adff8..868caca5 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -1454,8 +1454,7 @@ bgp_update_attrs(struct bgp_proto *p, struct bgp_channel *c, rte *e, ea_list *at ad = as_path_strip_confed(pool, ad); /* AS_PATH attribute - keep or prepend ASN */ - if (p->is_internal || - (p->rs_client && src && src->rs_client)) + if (p->is_internal || p->rs_client) { /* IBGP or route server -> just ensure there is one */ if (!a)
Re: Route server on a Bird2.0.2
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
Re: Route server on a Bird2.0.2
Hi, Why are you doing iBGP between your RS in an IXP context? -- Alarig
Re: Route server on a Bird2.0.2
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
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