February 2026 - Bird-users

BGP BFD strict mode support?
by Christian Ruppert 17 Feb '26

17 Feb '26

Hi list, is it possible to add BFD strict mode support? Or is it possible to let bird behave like this already with some workarounds by chance? It looks like both sides must support that in order to get it working: > Both peers must advertise support for strict-BFD capability for strict > behavior to take effect on that session. Right now it seems like BFD + BGP is kinda useless because when we drop BFD packets for example, to simulate an outage, even tho the BFD session is going down, BGP stays up and still exports routes etc. We have configured bfd into our bgp template / config in bird: template bgp bfd_bgp_v6 { description "IPv6 BGP"; local ... as 1337; strict bind yes; hold time 90; keepalive time 30; bfd; ipv6 { next hop self; import filter { reject "No import on LB!"; }; export where lb_export(); }; } protocol bfd { accept direct; neighbor ... neighbor ... ... }; I *might* also be able to arrange either some money donation for the project and/or an individual developer, whatever is preferred. https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bfd-strict-mode/ https://supportportal.juniper.net/s/article/BFD-strict-mode-for-BGP-peer-se… https://www.juniper.net/documentation/us/en/software/junos/high-availabilit… https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic… -- Regards, Christian Ruppert

2 1

[PATCH] nexthop_compare_node: fix NULL iface dereference
by Mathieu Hautebas 16 Feb '26

16 Feb '26

Hello, I am proposing a fix for a segfault encountered in bird6, in the nexthop_compare_node function. This patch adds checks for validating that x->iface and y->iface are not null before accessing their index field. I initially proposed a fix on calico's bird fork : https://github.com/projectcalico/bird/pull/117 but I was asked to propose it to the official repo. Please find the full patch attached. Best regards, Mathieu.

2 1

set bgp_med
by Christoph 12 Feb '26

12 Feb '26

Hi, in the config snippets below I added the export filter, see the "<<<<" signs. The goal is to set the med. When running "configure" this change triggers this warning: <WARN> Channel nextlayer_ndc1_v4.ipv4 hits route export limit (1), action: disable Which suggests that this config change causes a misconfiguration and route leak, correct? I only expect to announce a single prefix. How would you actually set the med instead? thank you! Christoph protocol static mynet4 { ipv4; route 109.70.100.0/24 reject; } filter set_med20 { bgp_med = 20; accept; } template bgp bgp_base4 { local as 208323; strict bind on; prefer older yes; graceful restart on; graceful restart time 300; ipv4 { import filter transit_in; import keep filtered on; import table on; export where proto = "mynet4"; export limit 1; }; } protocol bgp nextlayer_ndc1_v4 from bgp_base4 { hold time 120; keepalive time 20; neighbor 2.2.2.2 as 1764; source address 1.1.1.1; authentication md5; include "../peers-secrets/....conf"; multihop; ipv4 { <<<< export filter set_med20; <<<< }; <<<< }

2 2

[PATCH] bgp: Implement Multiple Labels capability (RFC 8277)
by Sébastien PARISOT 12 Feb '26

12 Feb '26

Hello BIRD team, This patch (for master branch / 2.18) adds negotiation for the Multiple Labels capability (Capability Code 8, RFC 8277) to control MPLS label stack encoding in BGP NLRI updates. BIRD currently reads labels until BOS unconditionally, as specified by RFC 3107. This works fine with peers that do the same (including previous BIRD versions) but does not conform to RFC 8277 when interoperating with peers that only expect a single label. Note that this also matters for SRv6: when an SRv6 service TLV is present (RFC 9252), the NLRI label field carries raw 24-bit values used for SID transposition, and the BOS bit is not set, so it cannot be used to delimit the label stack. The patch adds a new "multiple labels" channel option with 4 modes: - always (default): always read/write label stacks until BOS. The capability is not advertised. This preserves compatibility with existing BIRD peers and RFC 3107 implementations that send multiple labels. - advertise: same as always, but also advertises the capability to the peer. - yes / negotiated: advertise the capability and only use BOS-delimited stacks when the peer also advertises it (strict RFC 8277 behavior). If the peer does not support the capability, only a single label is read and sent. - no / disabled: no capability advertised, only single labels used. The default "always" preserves the existing BIRD behavior, so this is a no-op change for existing configurations. "require multiple labels yes" rejects sessions where the peer does not advertise the capability. Additional RFC 8277 compliance: - Duplicate AFI/SAFI triples in the capability are handled by keeping the first value and ignoring duplicates (Section 2.1) - Excess labels on receive trigger treat-as-withdraw per RFC 7606 (Section 2.1) - Routes with more labels than the peer's advertised count are rejected on export (Section 3.2.1/3.2.2) Thanks! -- Sébastien

1 0

[PATCH] bgp: suppress link-local next hop based on RFC 2545 shared-subnet rule
by Sébastien PARISOT 12 Feb '26

12 Feb '26

Hello BIRD team, This patch (for master branch / 2.18) fixes the link-local next hop handling in BGP UPDATE messages sent by BIRD. Currently BIRD includes the link-local address in the IPv6 next hop field unconditionally whenever it is available (on single-hop sessions where the peer is on a directly connected subnet). This affects any address family that carries an IPv6 next hop: IPv6, VPNv6, as well as IPv4 and VPNv4 when using Extended Next Hop encoding (RFC 5549). RFC 2545 Section 3 specifies: "The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to." In practice this causes problems on single-hop sessions where the peer is on a directly connected subnet but the next hop is set to a non-connected address (e.g. a loopback address): some routers reject the UPDATE and close the session when they receive a route carrying a link-local next hop whose global address is not on the shared subnet. This behavior was observed with Cisco IOS XR with VPN SRv6 routes. The fix checks whether the global next hop falls within the connected prefix of the neighbor interface before including the link-local address. Thanks! -- Sébastien

1 0

[PATCH 4/4] Netlink: Skip stats in device dumps
by Asbjørn Sloth Tønnesen 10 Feb '26

10 Feb '26

Gathering interface statistics can be a relatively expensive operation on certain systems as it requires iterating over all the cpus. This patch instructs the kernel to not include device statistics, when scanning devices, as the statistics aren't used by BIRD. Kernel-side support for this was added in Linux v4.4 in commit d5566fd72ec1 ("rtnetlink: RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats"), this saves 368 bytes of statistics. In the Linux v6.19 commit 105bae321862 ("rtnetlink: honor RTEXT_FILTER_SKIP_STATS in IFLA_STATS"), it is expanded to skip more statistics bringing the savings to 800 bytes per device. Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 844aefa16..a5493feed 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -172,12 +172,19 @@ nl_request_dump_link(void) struct { struct nlmsghdr nh; struct ifinfomsg ifi; + struct { + struct rtattr hdr; + u32 val; + } attr; } req = { .nh.nlmsg_type = RTM_GETLINK, - .nh.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg)), + .nh.nlmsg_len = NLMSG_LENGTH(sizeof(req.ifi) + sizeof(req.attr)), .nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_DUMP, .nh.nlmsg_seq = ++(nl_scan.seq), .ifi.ifi_family = AF_UNSPEC, + .attr.hdr.rta_len = sizeof(req.attr), + .attr.hdr.rta_type = IFLA_EXT_MASK, + .attr.val = RTEXT_FILTER_SKIP_STATS, }; send(nl_scan.fd, &req, sizeof(req), 0); -- 2.51.0

1 0

[PATCH 0/4] Modernize Netlink code
by Asbjørn Sloth Tønnesen 10 Feb '26

10 Feb '26

These patches tweaks the netlink code, bringing it closer to best practice. Asbjørn Sloth Tønnesen (4): Netlink: Enable strict checking on nl_req Netlink: Skip request payload in acknowledgements Netlink: Enable and decode extended acknowledgements Netlink: Skip stats in device dumps sysdep/linux/netlink.c | 105 ++++++++++++++++++++++++++++++++--------- 1 file changed, 84 insertions(+), 21 deletions(-) base-commit: f1a7229de507d646d46758dcacdcba13585196ea -- 2.51.0

1 1

[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