Bug on route reflection with BIRD (no originator ID on withdrawals)

[Vasileios Kotronis]

Hello again,

so in add-path  scenarios the path IDs are propagated also for withdrawals,
so the prefix+path ID information can be used to determine which route
should be withdrawn.
Many thanks for the pointed Ondrej! I will reply back to the list with a
working setup after some testing
in case it is of value for other people too.

Have a great day,
Vasileios

On Tue, Dec 13, 2022 at 5:01 PM Vasileios Kotronis <vkotronis at codebgp.com>
wrote:

> Thank you for your fast response Ondrej (now I am cc'ing the list too,
> forgot before)!
> That is correct, however the BGP RR client cannot know which router
> actually withdrew
> the prefix, since this information is lost if not attached to the
> withdrawal.
> We also have an add-path setup, but the problem I am referring to is more
> generic
> (related to understanding which monitor actually sent the withdrawal).
> Withdrawal MRT files I checked carry the withdrawn route, but nothing more.
> Just trying to understand if the RFC leaves this ambiguous (i.e., how an
> RR client
> can know that the withdrawal it sees was actually generated by itself for
> example,
> since without an originator ID this is not feasible). In the latter case
> an RR client cannot
> know where the withdrawal came from, so it does not know if it should
> actually delete the route
> from its routing table or not (other RS clients may have the route active).
> Have you encountered this use case before?
>
> Best regards,
> Vasileios
>
> On Tue, Dec 13, 2022 at 4:15 PM Ondrej Zajicek <santiago at crfreenet.org>
> wrote:
>
>> On Tue, Dec 13, 2022 at 12:46:24PM +0200, Vasileios Kotronis via
>> Bird-users wrote:
>> > Hello there,
>> >
>> > I am facing an issue with a route reflection setup on BIRD.
>> > ...
>> > The reflector reflects routes from the monitor (monitoring the external
>> > router via BGP) to the client. However, I notice that the originator ID
>> > (used for loop detection in a RR setup) is input by the  BIRD RR only in
>> > announcements, and not in withdrawals. This means that if the same
>> > withdrawal (from the monitor) propagates within the RR cluster there is
>> no
>> > way to disambiguate this from another withdrawal.
>> > ...
>> > So, since RFC4456 is fully supported in BIRD, shouldn't this be present
>> > both in route announcements and withdrawals?
>>
>> Hello
>>
>> No. In BGP, route attributes are associated with updates, never with
>> withdrawals. That is a general principle for all attributes.
>>
>> BGP clients know their state (including received prefixes) so they
>> know which route was withdrawn, as it is identified by the prefix.
>>
>> If there are multiple paths for the same network within RR cluster,
>> then RR selects one and announce it, so for a receiver there is no
>> ambiguity.
>>
>> That could lead to loss of information, so if you want multiple paths for
>> the same network announced, you should enable 'add path' extension, which
>> allow sending multiple paths for one network, disambiguated by 'path
>> identifier' (which is not a route attribute, but an extension to NLRI).
>>
>> --
>> Elen sila lumenn' omentielvo
>>
>> Ondrej 'Santiago' Zajicek (email: santiago at 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."
>>
>
>
> --
>
> Vasileios Kotronis
>
> CTO & Co-founder
> www.codebgp.com
>
> Monitor • Detect • Protect
>


-- 

Vasileios Kotronis

CTO & Co-founder
www.codebgp.com

Monitor • Detect • Protect
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20221214/8b459efc/attachment.htm>