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

[Vasileios Kotronis]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20221213/fe16e4e7/attachment.htm>