Bug on route reflection with BIRD (no originator ID on withdrawals)
Hello there, I am facing an issue with a route reflection setup on BIRD. I have the following setup: external router --(eBGP)-- monitor | (iBGP) | reflector | (iBGP) | client 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. According to RFC4456 ( https://www.rfc-editor.org/rfc/rfc4456): ORIGINATOR_ID ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type code 9. This attribute is 4 bytes long and it will be created by an RR in reflecting a route. This attribute will carry the BGP Identifier of the originator of the route in the local AS. A BGP speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already exists. A router that recognizes the ORIGINATOR_ID attribute SHOULD ignore a route received with its BGP Identifier as the ORIGINATOR_ID. Also: If a route carries the ORIGINATOR_ID attribute, then in Step f) the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of the BGP speaker that has advertised the route. So, since RFC4456 is fully supported in BIRD, shouldn't this be present both in route announcements and withdrawals? This is my simple BIRD configuration (I am running version 2.0.10): log syslog all; router id 192.168.55.4; protocol device { } template bgp rr_clients { local 192.168.55.4 as 50414; neighbor as 50414; rr client; rr cluster id 1.0.0.1; ipv4 { import all; export all; }; ipv6 { import all; export all; }; } protocol bgp monitor from rr_clients { neighbor 192.168.55.3; } protocol bgp client1 from rr_clients { neighbor 192.168.55.2; } Thanks in advance! Best regards, Vasileios -- Vasileios Kotronis CTO & Co-founder www.codebgp.com Monitor • Detect • Protect
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@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."
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@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@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
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@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@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@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
participants (2)
-
Ondrej Zajicek -
Vasileios Kotronis