BIRD is not prepending ASN on EBGP export.

[Alexander Zubkov]

Most vendors do not allow multiple local AS numbers, I think. The fact you
receive the route over iBGP tells nothing about its origin, because
external routes are passed over iBGP as well. Could you imagine a
straightforward universal algorithm for guessing that the route is
originated by your iBGP AS number?

On Wed, Oct 9, 2024 at 4:13 PM Ochalski, Radoslaw <rochalsk at akamai.com>
wrote:

> We receive this route via IBGP on IBPG session and then exporting it to
> EBGP, I am pretty sure most vendor implementations will automatically
> prepend IBGP ASN. Otherwise, we are missing one ASN in ASPATH and
> attracting more traffic.
>
> Yes, I am aware we can prepend it, though it seems strange this is not
> default behavior.
>
>
>
> *Kind Regards,*
>
>
>
> Radek
>
>
>
>
>
> *From: *Alexander Zubkov <green at qrator.net>
> *Date: *Wednesday, October 9, 2024 at 3:30 PM
> *To: *"Ochalski, Radoslaw" <rochalsk at akamai.com>
> *Cc: *Ondrej Zajicek <santiago at crfreenet.org>, Bird-users <
> bird-users at network.cz>
> *Subject: *Re: BIRD is not prepending ASN on EBGP export.
>
>
>
> Hi Radoslaw, In your case, how should BIRD know in what ASN the routes are
> originating? The AS number appears when you do export via eBGP session. And
> it uses local ASN for that. If you need your routes to pretend to be
> originated in AS20940,
>
> ZjQcmQRYFpfptBannerStart
>
> *This Message Is From an External Sender *
>
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
>
> Hi Radoslaw,
>
>
>
> In your case, how should BIRD know in what ASN the routes are originating?
> The AS number appears when you do export via eBGP session. And it uses
> local ASN for that. If you need your routes to pretend to be originated in
> AS20940, you need to prepend AS20940 in some filter to your routes.
>
>
>
> On Wed, Oct 9, 2024 at 11:09 AM Ochalski, Radoslaw <rochalsk at akamai.com>
> wrote:
>
> Thanks Ondrej,
>
> So for the routes originating in AS20940, downstream will not be aware of
> AS20940 in the as-path it will only know private AS4290006033.
>
> Kind Regards,
>
> Radek
>
>
> On 10/8/24, 5:18 PM, "Ondrej Zajicek" <santiago at crfreenet.org <mailto:
> santiago at crfreenet.org>> wrote:
>
>
> !-------------------------------------------------------------------|
> This Message Is From an External Sender
> This message came from outside your organization.
> |-------------------------------------------------------------------!
>
>
> On Tue, Oct 08, 2024 at 04:46:07PM +0200, Alexander Zubkov via Bird-users
> wrote:
> > Hi Radoslaw,
> >
> > Do I get it right, that you have 2 bgp peerings here. First your route
> > passes this peering:
> > AS8075 <-> AS20940
> > then it passes other peering:
> > AS4290006033 <-> AS4290006002
> >
> > Then it is an expected behaviour. Because the ASN is prepended when
> > route is exported over eBGP session. And the local ASN is prepended.
> > So you see that when you receive the route over the first peering, it
> > is prepended with AS8075. Then it goes over the second peering, where
> > it is prepended with AS4290006033.
>
>
> Yes, that is true. I would add that one is not supposed to have different
> local ASNs for different BGP instances that form coherent BGP router,
> unless it is configured as BGP confederation or manually patched by
> filters.
>
>
> --
> Elen sila lumenn' omentielvo
>
>
> Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org <mailto:
> santiago at crfreenet.org>)
> "To err is human -- to blame it on a computer is even more so."
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20241009/14512566/attachment.htm>