- Bird-users - Mailing Lists

BMP Adj-RIB-Out post-policy support
by admin＠nxthdr.dev 26 Feb '26

26 Feb '26

Hello, Currently, the (preliminary) BMP protocol implementation in BIRD does not support ADJ-RIB-Out monitoring. Only ADJ-RIB-In pre- and post-policy are supported at the moment. I have implemented support for ADJ-RIB-Out post-policy monitoring, which is relatively straightforward to add. The proposed implementation is available here: https://github.com/CZ-NIC/bird/compare/master...matthieugouel:bird:bmp-adj-… I have not implemented ADJ-RIB-Out pre-policy yet, as this would require more intrusive changes related to export tables. I would be interested to know whether this is something you would consider merging. More generally, is there interest in extending BMP support in BIRD with additional features? I know that BMP is still marked as preliminary and not production-ready, but it is a protocol I personally rely on quite heavily. Best,Matthieu.

4 4

[PATCH] SRv6 support for BIRD
by Sébastien PARISOT 25 Feb '26

25 Feb '26

Hello BIRD team, This patch (for master branch / 2.18) adds SRv6 L3VPN support to BIRD. It applies on top of the Multiple Labels capability (RFC 8277) patch I sent earlier. - Patch 0001 is preparatory work that adds a new internal attribute BA_RAW_MPLS_LABEL_STACK (0xfd) that stores the full 24-bit wire values from MPLS label fields in BGP NLRI, alongside the existing BA_MPLS_LABEL_STACK (0xfe) which stores decoded 20-bit label values. The existing BA_MPLS_LABEL_STACK only preserves the 20-bit label value from each 24-bit NLRI label field, discarding the traffic class and BOS fields. This is fine for normal MPLS but is lossy for SRv6: RFC 9252 uses the NLRI label field to carry part of an SRv6 SID via transposition, where the full 24 bits are significant and BOS may not be set. - Patch 0002 adds SRv6 to the nest, it includes SID stack in next hop, adds the parser, display in CLI outputs. - Patch 0003 adds Netlink support for SEG6 routes in Linux kernel (but not SEG6LOCAL routes). - Patch 0004 adds SRv6 support to static protocol. - Patch 0005 updates l3vpn protocol to operate without MPLS. - Patch 0006 adds Prefix SID BGP attribute support for L3VPN. With this patch set BIRD can act as a SRv6 PE/headend, but there are some limitations: - Dynamic SID allocator is not implemented (SID can be read routing table with netlink or configured on static routes) - The code supports a SID stack but SRV6_MAX_SID_STACK is currently #defined to 1 because L3VPN uses only one (no SRv6 TE support) - The SID structure sub-sub-TLV is parsed on import (for transposition) but not generated on export (it is not mandatory per RFC 9252) - Endpoint behavior is set the opaque value (0xffff) in generated SID information sub-TLV (it is not mandatory to specify the codepoint of actual SID behavior per RFC 9252) A pair of BIRD configuration file are also included in attachment as examples. Example "show route" output: 65001:1 10.10.1.0/24 unicast [static_vpn 17:37:31.789] * (200) via 10.0.0.100 on veth1 srv6 <fc00:a1::1> Type: static univ 65002:1 10.20.1.0/24 unicast [peer2 17:37:36.192 from 10.0.0.2] * (100/) [AS65002i] via 10.0.0.200 on veth1 srv6 <fc00:a2::1> Type: BGP univ BGP.origin: IGP BGP.as_path: 65002 BGP.next_hop: 10.0.0.200 BGP.local_pref: 100 BGP.prefix_sid: SRv6 L3 Service SID=fc00:a2::1, Flags=0x00, Behavior=0xffff BGP.raw_mpls_label_stack: 0x000000 BGP.mpls_label_stack: 0 Looking forward to your feedback. Thanks! -- Sébastien

2 3

State of resilient nexthop ECMP
by Christopher Munz-Michielin 20 Feb '26

20 Feb '26

Hey all, Wondering what the state of support for resilient ECMP with BIRD is? I'm currently using BIRD to send traffic to a number of backend servers using ECMP, but of course if one server leaves the group, the entire hash is recalculated which results in clients being potentially directed to a different server resulting in tcp resets. I've been reading up on resilient nexthop which seems to solve this issue, and is supported natively in FRR, but I can't find any documentation about it's level of support in BIRD. Wondering if anyone else has had experience with this technology and BIRD.

2 1

What could be reason of route not propagating from LSA to routing table ?
by Mariusz Gronczewski 17 Feb '26

17 Feb '26

Hi, I'm trying to replace one of our Junipers and I've come up with bizzare problem. I'm trying to run OSPF instance on VRF (I don't think problem is VRF related, I tried without VRF and it's same result) and I see both peers and the LSA database are getting filled ☠ ip r sh vrf vrf-core 10.30.0.0/31 dev b-swcore.3011 proto kernel scope link src 10.30.0.0 10.30.0.4/31 dev b-swcore.3012 proto kernel scope link src 10.30.0.4 10.30.1.0/31 dev b-swcore.3000 proto kernel scope link src 10.30.1.0 bird> show ospf neighbors core: Router ID Pri State DTime Interface Router IP 10.100.1.1 1 Full/PtP 37.905 b-swcore.3011 10.30.0.1 10.100.1.2 1 Full/PtP 37.904 b-swcore.3012 10.30.0.5 193.200.227.2 128 Full/PtP 39.907 b-swcore.3000 10.30.1.1 bird> show ospf state area 0.0.0.0 router 193.200.227.1 distance 0 router 10.100.1.1 metric 10 router 10.100.1.2 metric 10 router 193.200.227.2 metric 10 stubnet 193.200.227.1/32 metric 0 stubnet 10.30.1.0/31 metric 10 stubnet 10.30.0.0/31 metric 10 stubnet 10.30.0.4/31 metric 10 stubnet 10.30.1.0/31 metric 10 bird> show ospf topology area 0.0.0.0 router 193.200.227.1 distance 0 router 10.100.1.1 metric 10 router 10.100.1.2 metric 10 router 193.200.227.2 metric 10 bird> show protocols Name Proto Table State Since Info device1 Device --- up 2026-02-11 15:43:43.320 kcore Kernel master4 up 2026-02-11 15:43:43.320 core OSPF master4 up 2026-02-11 15:43:43.320 Running (kcore is fetching from VRF kernel table to the main bird table) config is very bare bones protocol ospf core { vrf "vrf-core"; ipv4 { import keep filtered on; import all; export all; }; area 0 { interface "b-swcore.30*" { }; interface "vrf-core" { stub; }; }; }; protocol kernel kcore { kernel table 1002; learn all; ipv4 { export none; import all; }; }; but I'm only getting my own routes bird> show route Table master4: 10.30.1.0/31 unicast [core 2026-02-11 16:21:37.684] * I (150/10) [193.200.227.1] dev b-swcore.3000 unicast [kcore 2026-02-11 16:21:38.584] (10) dev b-swcore.3000 10.30.0.0/31 unicast [core 2026-02-11 16:21:37.684] * I (150/10) [193.200.227.1] dev b-swcore.3011 unicast [kcore 2026-02-11 16:21:38.584] (10) dev b-swcore.3011 10.30.0.4/31 unicast [core 2026-02-11 16:21:37.684] * I (150/10) [193.200.227.1] dev b-swcore.3012 unicast [kcore 2026-02-11 16:21:38.584] (10) dev b-swcore.3012 193.200.227.1/32 unicast [core 2026-02-11 16:21:37.684] * I (150/0) [193.200.227.1] dev vrf-core bird> So far I tried running it outside of VRF and adding some PtP related options to OSPF but it didn't change anything I'm getting warnings about broadcast address Feb 11 16:21:37 d1-r1 bird[7194]: Missing broadcast address for interface b-swcore.3011 Feb 11 16:21:37 d1-r1 bird[7194]: Missing broadcast address for interface b-swcore.3012 Feb 11 16:21:37 d1-r1 bird[7194]: Missing broadcast address for interface b-swcore.3000 but those appear to be unrelated, I've changed one of the /31 links to /30 and nothing changed Version is 3.1.0 from Debian package but I also tried to downgrade to 2.x with no effect. The P2P links are just vlans to juniper and our 2 core switches on other side I also get no routes xani@r2> show ospf database advertising-router 193.200.227.1 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 193.200.227.1 193.200.227.1 0x80000060 347 0x42 0xadd4 108 while at same time getting some bird> show ospf lsadb router 193.200.227.1 Area 0.0.0.0 Type LS ID Router Sequence Age Checksum 0001 193.200.227.1 193.200.227.1 80000076 76 cd17 bird> show ospf lsadb router 193.200.227.2 Global Type LS ID Router Sequence Age Checksum 0005 88.156.75.236 193.200.227.2 8000c3e1 1249 3340 0005 193.200.227.2 193.200.227.2 8002a08f 2150 7d23 0005 194.50.132.0 193.200.227.2 80006374 1849 a24f 0005 194.50.134.0 193.200.227.2 80006374 648 8c63 0005 194.50.135.0 193.200.227.2 80006373 1549 836c 0005 212.91.10.200 193.200.227.2 800019e7 948 1b27 0005 0.0.0.0 193.200.227.2 80001b60 48 9334 0005 46.28.244.72 193.200.227.2 80018367 349 339f Area 0.0.0.0 Type LS ID Router Sequence Age Checksum 0001 193.200.227.2 193.200.227.2 8002a1f5 87 074e 0002 10.30.1.1 193.200.227.2 80000001 87 427e I did try to run very simple equivalent OSPF config on FRR and it "just worked" so needless to say I'm very confused by the issue. Any ideas how I can even debug what's happening in the first place ? Regards -- Mariusz Gronczewski (XANi) <xani%2Bbird(a)devrandom.pl> GnuPG: 0xEA8ACE64 https://devrandom.eu

2 5

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