<div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>And here is my concerns:<br></div><div><br></div><div>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.<br></div><div><br></div><div>2) It the other thread someone mentioned that other verndors behave differently with similar option and that could be confusing.</div><div><br></div><div>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.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 6, 2018 at 3:32 PM, Ondrej Zajicek <span dir="ltr"><<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Nov 06, 2018 at 01:19:19PM +0100, Alexander Zubkov wrote:<br>
> Can this be considered a bug and fixed so any "rs client" session would not<br>
> receive prepend? Or current behaviour is relied on by some production<br>
> systems?<br>
<br>
</span>Hi<br>
<br>
The change was intentional (to be consistent with route reflector<br>
behavior), but it is hard to say what is expected behavior and which one<br>
makes more sense. AFAIK it is not specified anywhere and it rarely makes<br>
sense to mix RS sessions with other sessions. This is not a first<br>
complain (see [*]) for the new behavior, so we may roll it back, but<br>
there are also cases where it makes sense - e.g. where IXP/RS is mixed<br>
with upstream provider, so in the RS there are routes received from other<br>
RS peers, which should not be prepended, and IBGP routes representing<br>
upstream, which should be prepended.<br>
<br>
IMHO the old behavior was inconsistent w.r.t. local routes - BIRD should<br>
handle in the same way local routes and routes local to the AS received<br>
from IBGP.<br>
<br>
Could you make a case for either prepend or not-prepend behavior?<br>
Should it be different for non-RS EBGP to RS EBGP vs IBGP to RS EBGP?<br>
<br>
[*] <a href="https://www.mail-archive.com/bird-users@network.cz/msg03424.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/<wbr>bird-users@network.cz/<wbr>msg03424.html</a><br>
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" rel="noreferrer" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</font></span></blockquote></div><br></div>