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 <[email protected]> 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 <[email protected]> > 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: [email protected]) >> 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
