Can this be considered a bug and fixed so any "rs client" session would not receive prepend? Or current behaviour is relied on by some production systems? On Fri, Nov 2, 2018 at 5:21 PM, Alexander Zubkov <green@qrator.net> wrote:

I have also looked further for routes not imported from bgp. In this case bird1 also adds prepend, because "rs client" condition is not checked here in bgp_create_attr: https://gitlab.labs.nic.cz/labs/bird/blob/fff79b1c1e0577f487b4fb67f79a74 b054d734b6/proto/bgp/attrs.c#L1029

if (p->is_internal) bgp_set_attr_wa(ea->attrs+1, pool, BA_AS_PATH, 0);

On Fri, Nov 2, 2018 at 12:43 PM, Alexander Zubkov <green@qrator.net> wrote:

...

Hello,

I found out that bird version 2 prepends its ASN when exporting to eBGP peer and "rs client" option enabled. I made some investigation and found out that bgp code was hardly redesigned and the logic of "rs client" was changed. Here is v1. https://gitlab.labs.nic.cz/labs/bird/blob/fff79b1c1e0577f487 b4fb67f79a74b054d734b6/proto/bgp/attrs.c#L1100

if (!p->is_internal && !p->rs_client) { bgp_path_prepend(e, attrs, pool, p->local_as);

And this is in v2 now. https://gitlab.labs.nic.cz/labs/bird/blob/e19d08055a4614f03e 51ee72617be10946ce7919/proto/bgp/attrs.c#L1451

if (p->is_internal || (p->rs_client && src && src->rs_client)) {

If I get it right, it does not prepend its ASN only in the case when route was received from BGP session too and that session is marked "rs client". So only prefixes from one "rs client" to another is not prepended.

It looks like it is impossible now to skip prepend for eBGP for some local routes, for example. I wish it was made an old style way - when "rs client" skips prepend unconditionally.

Hi, I agree that it simplifies configuration of some cases. And that is good. But I see two concerns here. May be it can be done by other means to keep simple configuration on the one side and make it more flexible on the other. For example make "rs client" option not boolean, but with some additional possibility, so boolean values work as they do now, but it is also would be possible to say, for example, "rs client always" and it that case it skips prepend no matter how and where the route was received. And here is my concerns: 1) There is no way to remove this prepend, becase it is done after the filters now and can not be affected in any way. On the other side if "rs client" never recieved prepend, we could add it ourselves with filters when needed (for other eBGP non-"rs client" sessions for example). And even if it were possible to do with filters - we can not remove exactly one element from the aspath. 2) It the other thread someone mentioned that other verndors behave differently with similar option and that could be confusing. We ourselves using BGP also for internal routing with routes originated from peers or internal sources (kernel, static). But those routes can be exported to peers too so we need to be precise with aspath there. Fortunately, in my case I have control on both sides of the session, so I can redo the configuration with iBGP and route reflection or maybe confederations. But eBGP in that place looks more logical and convenient. On Tue, Nov 6, 2018 at 3:32 PM, Ondrej Zajicek <santiago@crfreenet.org> wrote:

On Tue, Nov 06, 2018 at 01:19:19PM +0100, Alexander Zubkov wrote:

...

Can this be considered a bug and fixed so any "rs client" session would not receive prepend? Or current behaviour is relied on by some production systems?

Hi

The change was intentional (to be consistent with route reflector behavior), but it is hard to say what is expected behavior and which one makes more sense. AFAIK it is not specified anywhere and it rarely makes sense to mix RS sessions with other sessions. This is not a first complain (see [*]) for the new behavior, so we may roll it back, but there are also cases where it makes sense - e.g. where IXP/RS is mixed with upstream provider, so in the RS there are routes received from other RS peers, which should not be prepended, and IBGP routes representing upstream, which should be prepended.

IMHO the old behavior was inconsistent w.r.t. local routes - BIRD should handle in the same way local routes and routes local to the AS received from IBGP.

Could you make a case for either prepend or not-prepend behavior? Should it be different for non-RS EBGP to RS EBGP vs IBGP to RS EBGP?

[*] https://www.mail-archive.com/bird-users@network.cz/msg03424.html

-- Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago@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."