- Bird-users - Mailing Lists

[PATCH 2/4] Netlink: Skip request payload in acknowledgements
by Asbjørn Sloth Tønnesen 10 Feb '26

10 Feb '26

Set NETLINK_CAP_ACK, as we don't need a full copy of the request payload, so it's "rather wasteful"[1] to not set NETLINK_CAP_ACK. We don't check the return value of setsockopt(), as any capped message will have NLM_F_CAPPED set in nlmsg_flags. NETLINK_CAP_ACK was introduced in Linux v4.3 commit 0a6a3a23ea6e ("netlink: add NETLINK_CAP_ACK socket option"), and so AFAICT it doesn't need to be added to netlink-sys.h. [1] https://docs.kernel.org/userspace-api/netlink/intro.html Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 4268244a0..c9eedf8a4 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -67,6 +67,14 @@ static linpool *nl_linpool; static struct nl_sock nl_scan = {.fd = -1}; /* Netlink socket for synchronous scan */ static struct nl_sock nl_req = {.fd = -1}; /* Netlink socket for requests */ +static void +nl_set_cap_ack(struct nl_sock *nl UNUSED, int val UNUSED) +{ +#ifdef SOL_NETLINK + setsockopt(nl->fd, SOL_NETLINK, NETLINK_CAP_ACK, &val, sizeof(val)); +#endif +} + static void nl_open_sock(struct nl_sock *nl) { @@ -79,6 +87,8 @@ nl_open_sock(struct nl_sock *nl) nl->rx_buffer = xmalloc(NL_RX_SIZE); nl->last_hdr = NULL; nl->last_size = 0; + + nl_set_cap_ack(nl, 1); } } -- 2.51.0

1 0

[PATCH 1/4] Netlink: Enable strict checking on nl_req
by Asbjørn Sloth Tønnesen 10 Feb '26

10 Feb '26

Enable strict checking of netlink messages on the nl_req connection, so it is enabled on both connections. Also rename the function to remove "_dump" suffix, as it's a generic option. Strict checking was originally called NETLINK_DUMP_STRICT_CHK, but was renamed to NETLINK_GET_STRICT_CHK, as it should apply to all calls, not only dumps (Linux commmit d3e8869ec826). When set on nl_req, we don't need to check the return code, as it will fail on nl_scan as well, and so one log message should be enough and unlike nl_scan, we don't need to alter the mode of operation. Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 8be5112c4..4268244a0 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -83,7 +83,7 @@ nl_open_sock(struct nl_sock *nl) } static int -nl_set_strict_dump(struct nl_sock *nl UNUSED, int strict UNUSED) +nl_set_strict_chk(struct nl_sock *nl UNUSED, int strict UNUSED) { #ifdef SOL_NETLINK return setsockopt(nl->fd, SOL_NETLINK, NETLINK_GET_STRICT_CHK, &strict, sizeof(strict)); @@ -122,7 +122,8 @@ nl_open(void) nl_open_sock(&nl_scan); nl_open_sock(&nl_req); - if (nl_set_strict_dump(&nl_scan, 1) < 0) + nl_set_strict_chk(&nl_req, 1); + if (nl_set_strict_chk(&nl_scan, 1) < 0) { log(L_WARN "KRT: Netlink strict checking failed, will scan all tables at once"); krt_use_shared_scan(); -- 2.51.0

1 0

How to work with ASPA efficiently?
by Ondřej Caletka 05 Feb '26

05 Feb '26

Hello! I am trying to troubleshoot some ASPA validation failures in BIRD 3.2.0. I wonder whether there is a way how to see a ASPA table entry for particular customer AS number. Something like: bird> show route table aspas all for 2121 syntax error, unexpected NUM, expecting IP4 or IP6 or VPN_RD or CF_SYM_KNOWN I also wonder whether it is possible to filter the data based on the contents of the aspa_provider sets like: bird> show route table aspas all where 3333 ~ aspa_providers Table aspas: Regarding the validation itself, a random trivial example where aspa_check_downstream fails and I don't know why is this: 80.254.230.0/24 bgp_path: 3333 12859 42695 (My ASN is 2121 and there is an ASPA stating that 3333 is provider for 2121) There is no ASPA for 3333 There is ASPA for 12859 not stating 42695 as provider There is ASPA for 42695 not stating 12859 as provider So the up ramp should be 42695 and the down ramp should be 2121 3333 12859 I don't see any valleys here yet it is rejected. Am I doing it wrong? -- Best regards, Ondřej Caletka

2 2

Re: bird 3.2.0 - Malformed AS_PATH attribute - AS_SET segment (1) at 26
by Benjamin LaHaise 04 Feb '26

04 Feb '26

Hello Maria, On Wed, Feb 04, 2026 at 10:23:39PM +0100, Maria Matejka wrote: ... > This is a known feature, mandated by RFC 9774, Section 3: ... > It is still possible to `allow as sets` explicitly, if you really need > to keep them. Ah, so this is a case of the RFCs being ahead of what's actually deployed on the Internet. Sadly, I must accept them as otherwise there are holes in the routing table across a number of providers. If it was just 1 provider then new behaviour could be acceptable. Will have to revisit this in 2 or 3 years to see if ISPs have caught up with RFC 9774. Thank you for the quick response -- it is much appreciated. Cheers, -ben -- "Thought is the essence of where you are now."

1 0

bird 3.2.0 - Malformed AS_PATH attribute - AS_SET segment (1) at 26
by Benjamin LaHaise 04 Feb '26

04 Feb '26

Hello all, With Fedora 43's bird 3.2.0-1 rpm installed on an x86_64 system, I'm seeing that several routes are being dropped from a full feed with the log messages below. Using Fedora's bird 3.1.4-1 does not seem to have any issues with the same BGP config and peer. Is this a known bug? What additional information can I provide to aid in the debugging? This is a backup transit connection that is not yet in full production use (but will be soon), so I can help with debugging and testing for now. Cheers, -ben Feb 4 14:42:49 router bird[24317]: upstream: Malformed AS_PATH attribute - AS_SET segment (1) at 14 Feb 4 14:42:49 router bird[24317]: upstream: Invalid route 76.165.0.0/16 withdrawn Feb 4 14:42:49 router bird[24317]: upstream: Malformed AS_PATH attribute - AS_SET segment (1) at 18 Feb 4 14:42:49 router bird[24317]: upstream: Invalid route 204.10.20.0/22 withdrawn Feb 4 14:42:49 router bird[24317]: upstream: Malformed AS_PATH attribute - AS_SET segment (1) at 14 Feb 4 14:42:49 router bird[24317]: upstream: Invalid route 213.186.96.0/19 withdrawn Feb 4 14:42:49 router bird[24317]: upstream: Invalid route 94.178.0.0/15 withdrawn Feb 4 14:42:49 router bird[24317]: upstream: Invalid route 37.52.0.0/14 withdrawn Feb 4 14:42:50 router bird[24317]: upstream: Malformed AS_PATH attribute - AS_SET segment (1) at 26 Feb 4 14:42:50 router bird[24317]: upstream: Invalid route 208.68.112.0/21 withdrawn Feb 4 14:42:50 router bird[24317]: upstream: Malformed AS_PATH attribute - AS_SET segment (1) at 18 Feb 4 14:42:50 router bird[24317]: upstream: Invalid route 147.92.87.0/24 withdrawn Feb 4 14:42:50 router bird[24317]: upstream: Invalid route 52.129.48.0/24 withdrawn Feb 4 14:42:50 router bird[24317]: upstream: Malformed AS_PATH attribute - AS_SET segment (1) at 18 Feb 4 14:42:50 router bird[24317]: upstream: Invalid route 15.20.64.0/18 withdrawn -- "Thought is the essence of where you are now."

2 1

iBGP config.
by Mike Neo 29 Jan '26

29 Jan '26

Hi, I have one operator with a full BGP table (one BGP session) and one IX (two BGP sessions, one BGP session each, to two different ISP routers). I need to configure two BGP routers based on Ubuntu + Bird 2/3 with iBGP. Could someone share this configuration and point out what to watch out for when traffic is ~1-2 Gbps? Thanks in advance.

4 5

BIRD at FOSDEM 2026
by Maria Matejka 18 Jan '26

18 Jan '26

Dear BIRD Users, in two weeks, there is FOSDEM 2026, and you are all welcome to meet us at our stand there, chat with us, ask your technical questions or fetch some branded items. Our stand is shared with Turris, and we expect to be in the building K, somewhere nearby WireShark and OpenTofu. Please check the official maps when they are released. If you're thinking about throwing some money on the project in exchange for some support services or feature development, our stand is a perfect place to consult that. You may also message me privately in advance to get a time slot reserved. Looking forward to meeting you all! Maria et al. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

Not receiving OSPF Hello even though tcpdump shows it's received
by Lukas Haase 15 Jan '26

15 Jan '26

2 2

draft-ietf-idr-linklocal-capability
by Donatas Abraitis 15 Jan '26

15 Jan '26

Hello! Is this the right place to ask for implementing [1]draft-ietf-idr-linklocal-capability capability? [1] - https://datatracker.ietf.org/doc/html/draft-ietf-idr-linklocal-capability? -- Donatas

2 2

BIRD 3.2.0 and 2.18 released
by Maria Matejka 15 Jan '26

15 Jan '26

Dear BIRD users, we are releasing BIRD versions 3.2.0 and 2.18. We have implemented BGP dynamic onlink/unnumbered and link-local connection scenarios and fixed various behavior bugs in reconfiguration. Also, AS Sets in AS Paths are now considered malformed by default. For BIRD 3.2.0, we have split back the `igp_metric` attribute so that now you may find also `local_metric` where applicable. There was a confusion in BIRD 3.0 and 3.1 arising from two distinct attributes in BIRD 2 named the same in the code, and me not understanding what Santiago was telling me about that. More on that in updated 3.2 documentation. We have done various minor updates, e.g. flags in RAdv (both versions), fixed a RIP non-determinism (v3) and additional CLI configuration bugs. There have been some more core reworks, removing some more performance chokepoints. Both versions also include all relevant fixes applied for 3.1.5 and 2.17.3. Considering unfinished work, we also have several Babel patches pending which we failed again to review in time to merge into 2.18. We'll do them as soon as possible. Also, in BIRD 3.x, the "show route for" displays all covering routes instead of just the longest prefix match. We're working on a fix but it's quite a can of worms. Officially supported versions are now: - 3.2.0 and 2.18 until 6 months after 3.3.0 and 2.19 get released - LTS 3.1.x and 2.17.x, expected to track Debian Trixie The DEB packages in pkg.labs.nic.cz are already there, and RPMs will come soon. Please note that the upstream DEBs weren't built directly from the tagged commit but from the `release-v2.18` and `release-v3.2` branch because of our current CI limitations. We'll fix that for later versions. Happy new year! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

5 8