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