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) <santi...@crfreenet.org>
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)
