February 2026 - Bird-users

Several assertion failures in 3.2.0
by Matt Corallo 02 May '26

02 May '26

Figured I'd give 3.2.0 a whirl, but sadly it still seems quite assertion-failure-prone. It seems to hit quite a few assertions, sadly, so not sure if the underlying issue isn't something less than deterministic. I have core dumps that I can provide against the debian forky 3.2.0 package. I saw at least the following: (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007fa1b85289ff in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89 #2 0x00007fa1b84d3cc2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007fa1b84bc4ac in __GI_abort () at ./stdlib/abort.c:77 #4 0x0000555dddb0a1bc in bug (msg=msg@entry=0x555dddb1ace8 "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:412 #5 0x0000555ddda7ad4c in proto_announce_state_locked (ts=0x555dddb9a260 <proto_state_table_pub>, p=0x555e06438c70, new_state=0x7fa111f18208) at nest/proto.c:3069 #6 proto_announce_state (p=0x555e06438c70, attr=0x7fa111f18208) at nest/proto.c:3129 #7 0x0000555ddda58cb6 in defer_execute (_ld=<optimized out>) at lib/defer.c:22 #8 0x0000555ddda590a6 in ev_run_list_limited (l=l@entry=0x555dddb94578 <main_birdloop+216>, limit=4294967294, limit@entry=0) at lib/event.c:336 #9 0x0000555dddb007a4 in io_loop () at sysdep/unix/io.c:2648 #10 0x0000555ddda1632e in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:1106 and this twice: (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007facbfb6c9ff in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89 #2 0x00007facbfb17cc2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007facbfb004ac in __GI_abort () at ./stdlib/abort.c:77 #4 0x0000557b139b21bc in bug (msg=msg@entry=0x557b139c2ce8 "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:412 #5 0x0000557b13934353 in rt_notify_basic (c=c@entry=0x557b1d7e2e10, new=<optimized out>, new@entry=0x7fac024adfb8, old=old@entry=0x7fac8828a938) at nest/rt-table.c:1192 #6 0x0000557b139385cb in channel_notify_basic (_channel=0x557b1d7e2e10) at nest/rt-table.c:1627 #7 0x0000557b139010a6 in ev_run_list_limited (l=l@entry=0x557b1d7e37d8, limit=4294967294, limit@entry=4294967295) at lib/event.c:336 #8 0x0000557b139af4ff in birdloop_run (_loop=0x557b1d7e3700) at sysdep/unix/io-loop.c:1836 #9 0x0000557b139010a6 in ev_run_list_limited (l=0x557b1d898fb8, limit=4294967294, limit@entry=4294967295) at lib/event.c:336 #10 0x0000557b139ad392 in bird_thread_main (arg=0x557b1d899210) at sysdep/unix/io-loop.c:952 #11 0x00007facbfb6ab7b in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448 #12 0x00007facbfbe87b8 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 I also got a Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1416 once but don't have a coredump for that one.

1 2

bird 3.1.5 crashes after adding "-R" to BIRD_ARGS
by Christoph 16 Mar '26

16 Mar '26

Hello, last night we made two changes to our BIRD config: * enabled ASPA validation (logging only) * added "-R" to BIRD_ARGS (/etc/bird/envvars) after that we run "configure" on birdcl. After that bird started to crash in a loop. We decided to rollback the ASPA configuration change to restore a working setup. This did not help. Then we decided to remove "-R" from BIRD_ARGS and that helped. For this reason we did not include the ASPA config changes in this email since they appear to be not relevant for the crashes. We assume "-R" causes the crashes. Is this a known bug that is solved in 3.2.0? We would like to have graceful restart support but we are a bit hesitant with "-R" now ;-) Logs: 2026-01-05 01:15:31.820 [0001] <INFO> Reconfiguring 2026-01-05 01:15:31.822 [0001] <INFO> Cannot add channel r3k.aspa 2026-01-05 01:15:31.822 [0001] <INFO> Restarting protocol r3k 2026-01-05 01:15:38.339 [0001] <INFO> Reloading channel anexia_v4.ipv4 2026-01-05 01:15:38.339 [0001] <INFO> Reloading channel anexia_v6.ipv6 2026-01-05 01:15:38.366 [0001] <INFO> Reloading channel nextlayer_v4.ipv4 2026-01-05 01:15:38.367 [0001] <INFO> Reloading channel nextlayer_v6.ipv6 2026-01-05 01:15:38.367 [0001] <INFO> Reconfigured 2026-01-05 01:15:42.397 [0002] <BUG> Assertion 'r->cur' failed at lib/lockfree.c:229 Jan 05 01:15:42 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:15:42 bird.service: Failed with result 'signal'. Jan 05 01:15:42 bird.service: Consumed 1d 39min 31.457s CPU time, 1.6G memory peak. Jan 05 01:15:42 bird.service: Scheduled restart job, restart counter is at 2. lots of crashes: journalctl ..|grep 'bird.service: Main process exited,' Jan 05 01:15:42 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:17:16 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:18:45 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:20:13 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:21:28 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:21:41 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:22:42 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:22:56 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:24:22 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:24:36 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:25:30 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:27:02 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:27:16 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:28:10 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:29:37 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:29:51 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:30:52 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:30:59 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:32:10 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:32:20 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:36:04 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:36:18 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:36:33 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:36:47 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:37:02 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:37:16 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:38:36 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:38:51 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:39:05 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:39:20 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:39:34 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:39:49 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:41:26 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:41:40 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:41:55 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:42:10 bird.service: Main process exited, code=killed, status=11/SEGV Bird version (dpkg -l bird): ii bird3 3.1.5-cznic.1~trixie amd64 Internet Routing Daemon best regards, Christoph

2 4

[PATCH] Nest: correct aspa_check() implementation
by Evann DREUMONT 15 Mar '26

15 Mar '26

Hello, Earlier this week, while building a BGP lab I've discovered a weird behavior with aspa_check() that was rejecting routes that should be correct. It seems to be the same bug as https://trubka.network.cz/pipermail/bird-users/2026-February/018611.html. I discover that the previous implementation of the verification algorithm was not fully compliant with the current internet draft (draft-ietf-sidrops-aspa-verification-24) and could incorrectly filter routes when the up-ramp and down-ramp apex were apart by exactly one hop. In practice, this caused legitimate routes to be dropped, such as routes involving Tier-1 peering while having an AS0 ASPA record. One of my test sample was the following AS_PATH: 10846, 7018, 174, 29075, 208627 with the following ASPA records: - AS208627 => AS29075 - AS174 => 0 - AS7018 => 0 - AS10846 => 7018 If you manually compute the upstream and downstream bounds, you get - max_down = 5 - 3 + 1 = 3 - min_down = 5 - 4 + 1 = 2 - max_up = 2 - min_up = 2 Using the downstream algorithm: - max_up + max_down = 5 >= N, so the route is not invalid and we continue - min_up + min_down = 4 < N, so the route is unknown If you draw this on paper, it makes sense. However, BIRD reports this route as invalid, which is unexpected. Given this issue, I tried to implement a patch. With a bit of help of Alarig, I managed to get a working version that still passes the existing unit tests (except one) as well as our corner case. While I tried to understand the initial logic, it was quite hard to follow. Therefore, I tried, as much as possible, to follow the algorithm from the I.D. Something not trivial since the AS_PATH is reversed compared to the draft. This patch also contains few documentation comments. While I am not usually a big fan of comments, I think these are needed to highlight the differences between our implementation and the algorithm specified in the Internet-Draft. To improve unit test coverage, I have added the missing test cases from the official list (https://raw.githubusercontent.com/ksriram25/IETF/main/ASPA_path_verificatio…) They all passed successfully. However, one of the existing custom unit tests did not pass. In this test, the path consists of two ASes: 65544, 65541. AS65544 declare an AS0 ASPA and AS65541 declare AS65545 as a provider. The test expects the route to be invalid. However, I believe this expectation is incorrect. Manual computation gives: - min_up = 1 - max_up = 1 - max_down = 2 - 2 + 1 = 1 - min_down = 2 - 2 + 1 = 1 Using the downstream algorithm: - max_up + max_down = 2 >= N, so the route is not invalid and we continue - min_up + min_down = 2 >= N, so the route is not unknown, and therefore the route is valid. This actually makes sense: although there is no explicit valid ASPA, from a downstream perspective, this can be interpreted as a peering relationship between AS65544 and AS65541 (with the up-ramp and down-ramp apexes separated by exactly one hop), and the route should therefore be considered valid (see: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-…) Don't hesitate to discuss the patch if needed, -- Evann

4 3

evpn rebase to HEAD
by Pim van Pelt 13 Mar '26

13 Mar '26

Hoi folks, I've started to toy with VPP and eVPN/VxLAN, and took a look at the evpn branch from a few years ago. For my network, I'll need the OSPFv3 'unnumbered' features we built, so I thought I'd ask - would it be possible to rebase the evpn branch ? I've taken a stab at it (see attached patch) by replaying the 9 commits on top if HEAD (f1a7229d-evpn.diff). It may not be correct, but it does compile and seemingly work :) root@vpp0-0:/etc/bird# birdc show proto BIRD 2.18+branch.evpn.1efd115564ea ready. Name Proto Table State Since Info device1 Device --- up 12:20:01.347 direct1 Direct --- up 12:20:01.347 kernel4 Kernel master4 up 12:20:01.347 kernel6 Kernel master6 up 12:20:01.347 static4 Static master4 up 12:20:01.347 static6 Static master6 up 12:20:01.347 bfd1 BFD --- up 12:20:01.347 ospf4 OSPF master4 up 12:20:01.347 Running ospf6 OSPF master6 up 12:20:01.347 Running bridge1 Bridge etab up 12:45:13.450 evpn1 EVPN --- up 12:45:13.450 I have a few further changes, notably a new 'vpp protocol' to handle communication with the VPP dataplane for eVPN/VxLAN (and possibly later, GENEVE and MPLS). Before I get too far down the rabbit hole though, I'm also wondering: is releasing eVPN in the cards? groet, Pim -- Pim van Pelt <pim(a)ipng.ch> PBVP1-RIPE https://ipng.ch/

4 17

[EVPN] BIRD leaks internal address representation in BGP next hop
by Tomáš Matuš 06 Mar '26

06 Mar '26

Hello BIRDs! I am trying out EVPN in a multi-vendor environment (namely against Arista and Huawei CE6881E) on an IPv4 underlay and I noticed that neither of these vendors are considering EVPN routes received from BIRD as valid. When I inspect EVPN routes on Huawei it shows that the next-hop address is an IPv4 mapped to IPv6 on all routes from BIRD. To keep it short I'll only include one IMET route from Arista (10.10.10.1) and one from BIRD (10.10.10.3) where the route from Arista has IPv4 next-hop and route from BIRD does not. ----- [~vx-4]displ bgp evpn all routing-table inclusive-route Local AS number : 65000 BGP Local router ID is 10.10.10.2 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete Route Distinguisher: 10.10.10.1:10010 Network(EthTagId/IpAddrLen/OriginalIp) NextHop *>i 0:32:10.10.10.1 10.10.10.1 Route Distinguisher: 10.10.10.3:10010 Network(EthTagId/IpAddrLen/OriginalIp) NextHop i 0:32:10.10.10.3 ::FFFF:10.10.10.3 ----- I also checked with Wireshark and BIRD really sends an IPv6 next hop. I am using the following config for BGP: ----- template bgp evpn_peer { local as 65000; source address 10.10.10.3; ipv4 { import none; # routed by ospf in underlay export none; }; evpn { import all; export all; }; } protocol bgp bgp_Huawei from evpn_peer { neighbor 10.10.10.2 as 65000; }----- Looking at the BIRD BGP docs I also tried explicitly setting "next hop address 10.10.10.3" in the evpn block but the result was the same. I understand that this could technically fall under RFC 8950 and the "extended next hop <switch>" option in which case it would be okay to send the next hop as IPv6 however by default this option should be disabled in BIRD and even if I explicitly disable it I still see the next hop as IPv6. I looked over how the BGP packets are constructed and I think this comes down to the bgp_encode_next_hop_ip() function where the bgp_channel_is_ipv4(s->channel) only checks for BGP_AFI_IPV4 and returns false for EVPN AF so it falls through and sets the next-hop address as IPv6. I've attached a patch which fixes this behavior but I'm certain it is far from perfect. I also went back to my BIRD-only lab and I can see the same behavior. In this case however I think either the kernel is smart enough to figure out it is an IPv4 mapped to IPv6 and therefore treats it as IPv4 or BIRD handles it because the internal representation is the same. Am I right to consider this as a bug or is there something I missed? I don't have any experience with other Address Families in BGP with BIRD so I am not sure how bird behaves there when setting the next-hop address. With my patch applied I am happy to share that the EVPN control-plane works and I don't see any other issues. Received IMET and MAC routes are imported and get propagated into the linux bridge interface and routes exported by BIRD are also installed by the other two vendors. So far I'm only using L2 VNIs and I haven't yet configured Huawei/Arista to include IP address in the Type 2 routes, I expect that BIRD does not support this yet but I am at least curious if it can handle without crashing, or, when used as Route Reflector, if it can reflect such routes. If you have any other ideas what would be worth trying out, please let me know! PS: Thank you Ondřej for including my previous bug report in the latest rebase of the oz-evpn branch! Thank you and have a nice day! Tomáš

2 1

[PATCH 0/4] BGP unnumbered automatic peering based on IPv6 ND
by Matteo Perin 02 Mar '26

02 Mar '26

Dear BIRD dev-team and community, This is a patch proposal spawned from the discussion in a previous mailing list thread [0], regarding how to achieve automatic BGP peering establishment using the IPv6 Neighbor Discovery mechanism. Over the last few weeks, I worked on implementing the feature with the outline Maria Matejka kindly provided. As expected, it proved to be quite challenging, especially when it came to integrate the peer discovery approach with the current dynamic BGP implementation. To briefly summarize the implemented automatic peering mechanism and added capabilites: - The ability for the RAdv protocol to receive and read incoming ICMPv6 RAs was added. - Route-like objects, containing RAs data are created, based on advertisments detections. These are stored in a new kind of routing table. - Lifetime of the objects in the table is determined by the ICMPv6 RA Router Lifetime field. RA expiration will remove the object from the table. - The discovery process is enabled only if a new neighbor discovery option is enabled in the RAdv protocol configuration. - A new channel was added to the BGP protocol called peers. - When present in the BGP configuration, an export to this BGP channel (allowed only in dynamic BGP) will trigger the spawn of a new session. - Withdrawal the object from the peers routing table will trigger the corresponding BGP session shutdown. - An automatic BGP session can be made permanent via configuration with a persist option in the peers channel. To test the main functionality of this feature it I used multiple VMs linked by a bridge with BIRD setup on all of them. BGP session establishment is successful between all routers even with a very minimal configuration. I will provide an example, so you can also see the new configuration parameters in action: protocol device { } peer table nd_peers; protocol radv radv1 { peer { table nd_peers; }; interface "enp5s0" { max ra interval 60; min ra interval 20; # Enable neighbor discovery on this interface # When enabled, BIRD will parse incoming RAs and store router info neighbor discovery yes; }; } protocol bgp bgp1 { dynamic name "bgp_peer"; dynamic name digits 3; local as 65000; neighbor range fe80::/12 external; # Link-local range for BGP unnumbered # Peers channel for importing peer discoveries and spawning sessions peers { # Interface for BGP session establishment from "enp5s0"; # Persist sessions on route withdrawal persist yes; table nd_peers; import all; export all; }; ipv4 { import all; export all; }; ipv6 { import all; export all; }; } Of course, I have some concerns about some design choices and code optimization, I tried to find the best solution that did not involve major refactorings or moving code around and some comments on how to improve rough edges from people more experienced on the current codebase would be really appreciated. Mostly, the two main points I am not entirely happy about are: - How I handled the RAs staleness mechanism based on router lifetime. I looked for it but there does not seem to be a per-route staleness mechanism already in place, so I resorted to adding a check for expired entries when the RAdv protocol timer is triggerd, which is not ideal. - The mechanism to avoid spawning multiple sessions when both dynamic BGP and this new feature are both configured. For now, I try looking for BGP session with the same remote peer address and give precedence to the ones spawned by the dynamic BGP mechanism, but I am quite sure it is possible to find a better solution for this. I tried to make the commit messages both informative and concise, but please ask if something is unclear or missing. I am still working on adding documentation and automated testing, but since I think the discussion about the implemetation is more useful with actual code in hand, I decided to send the main bulk of the patch right now and amend this later along with changes addressing incoming reviews. I hope you will appreciate the work done. Best Regards, Matteo [0] https://bird.network.cz/pipermail/bird-users/2025-November/018482.html Matteo Perin (4): Nest: Add net_peer route type to track discovered peers RAdv: Add neighbor discovery based on incoming RAs to RAdv proto BGP: Move postponed socket reloop logic from start to start_locked to achieve locking requirements BGP: Add peers channel and sessions spawn on export to achieve automatic peering lib/net.c | 16 ++++ lib/net.h | 31 ++++++- nest/config.Y | 3 +- nest/proto.c | 2 +- proto/bgp/attrs.c | 57 +++++++++++++ proto/bgp/bgp.c | 187 +++++++++++++++++++++++++++++++++++++++---- proto/bgp/bgp.h | 28 ++++++- proto/bgp/config.Y | 15 +++- proto/bgp/packets.c | 11 +++ proto/radv/config.Y | 3 +- proto/radv/packets.c | 41 +++++++++- proto/radv/radv.c | 163 ++++++++++++++++++++++++++++++++++++- proto/radv/radv.h | 4 + 13 files changed, 533 insertions(+), 28 deletions(-) -- 2.43.0

2 15

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