- Bird-users - Mailing Lists

[EVPN] BIRD does not handle multihomed host
by Tomáš Matuš 25 Mar '26

25 Mar '26

Hello BIRDs! Hello Ondra. In my lab I have an all-active multihomed host to PE1 and PE2, BIRD is there as a PE3. I noticed that when both PE1 and PE2 announce a Type 2 route for the multihomed MAC (b8:69:f4:e0:4e:04) BIRD only uses one and does not fallback to the other when the first is withdrawn. I understand that this is starting to touch unsupported EVPN parts and BIRD doesn't do much with Type 1 and Type 4 routes apart of adding them to the evpn table, but it should at least handle multiple Type 2 routes for the same MAC. With ESI and LAG configured on PE1&PE2 BIRD accepts and shows all relevant routes and both Type 2s are there: ``` bird> sh route table evpntab Table evpntab: evpn mac 10.10.10.1:10010 0 b8:69:f4:e0:4e:04 * unicast [bgp_Arista 22:25:26.352 from 10.10.10.1] * (100/12) [i] via 100.90.109.98 on ens192 mpls 10010 evpn mac 10.10.10.2:10010 0 b8:69:f4:e0:4e:04 * unicast [bgp_Huawei 22:25:45.280 from 10.10.10.2] * (100/1) [?] via 100.90.109.98 on ens192 mpls 10010 evpn ead 10.10.10.1:1 4294967295 00:00:00:00:11:11:22:22:33:33 unicast [bgp_Arista 22:24:58.357 from 10.10.10.1] * (100/12) [i] via 100.90.109.98 on ens192 mpls 0 evpn ead 10.10.10.1:10010 0 00:00:00:00:11:11:22:22:33:33 unicast [bgp_Arista 22:25:08.352 from 10.10.10.1] * (100/12) [i] via 100.90.109.98 on ens192 mpls 10010 evpn ead 10.10.10.2:0 4294967295 00:00:00:00:11:11:22:22:33:33 unicast [bgp_Huawei 22:25:51.723 from 10.10.10.2] * (100/1) [?] via 100.90.109.98 on ens192 mpls 0 evpn ead 10.10.10.2:10010 0 00:00:00:00:11:11:22:22:33:33 unicast [bgp_Huawei 17:29:05.249 from 10.10.10.2] * (100/1) [?] via 100.90.109.98 on ens192 mpls 10010 evpn es 10.10.10.2:0 00:00:00:00:11:11:22:22:33:33 10.10.10.2 [bgp_Huawei 22:26:06.724 from 10.10.10.2] * (100) [?] evpn es 10.10.10.1:1 00:00:00:00:11:11:22:22:33:33 10.10.10.1 [bgp_Arista 22:24:58.357 from 10.10.10.1] * (100) [i] ``` When I inspect the ethernet table inside BIRD only one of these Type 2 routes is added (omitting flood entries to keep it short) and this route is also added to the kernel: ``` bird> sh route table etab10010 all ... b8:69:f4:e0:4e:04 mpls 10010 unicast [evpn10010 22:25:45.280] * (80) via 10.10.10.2 on vxlan10010 mpls 10010 Type: EVPN univ mpls_label: 10010``` Once one link from the LAG goes down and one of PE1 or PE2 withdraws its routes (does not matter which one) BIRD then receives withdraw for Type 2 route with MAC b8:69:f4:e0:4e:04 and removes it from ethernet table and from the bridge fdb without checking if any other route is still available in the evpntab to replace it with. As a result the traffic is flooded. I am somewhat convinced that this is partially caused by the channel being RA_ANY rather than RA_OPTIMAL for the non-BUM entries and because multiple routes are not considered in the BIRD eth table. To at least hack around this and make sure BIRD falls back to another available route I came up with the attached patch. - similarly to IMET routes it uses RD to create unique sources for received Type 2 routes and adds all to the eth table - uses first route from net->routes in kbr_rt_notify to install it to the kernel Using the first route likely is not optimal right now as kbr_rte_better isn't implemented to do BGP-style comparison. With my patch i see both routes in eth table and only one is installed to fdb: ``` bird> sh route table etab10010 all ... b8:69:f4:e0:4e:04 mpls 10010 unicast [evpn10010 11:04:26.321] * (80) via 10.10.10.1 on vxlan10010 mpls 10010 Type: EVPN univ mpls_label: 10010 unicast [evpn10010 11:04:48.048] (80) via 10.10.10.2 on vxlan10010 mpls 10010 Type: EVPN univ mpls_label: 10010 [root@col ~]# bridge fdb show br br10010 b8:69:f4:e0:4e:04 dev vxlan10010 vlan 1 extern_learn master br10010 b8:69:f4:e0:4e:04 dev vxlan10010 extern_learn master br10010 00:00:00:00:00:00 dev vxlan10010 dst 10.10.10.1 self extern_learn permanent 00:00:00:00:00:00 dev vxlan10010 dst 10.10.10.2 self extern_learn permanent b8:69:f4:e0:4e:04 dev vxlan10010 dst 10.10.10.1 self extern_learn permanent ```and when the route from 10.10.10.1 is withdrawn it gets immediately replaced by the route from 10.10.10.2. I'm curious to hear your opinion how you feel about having multiple routes for same MAC in the eth bridge protocol. Would it be cleaner to do this between EVPN table and the eth table rather than eth table and kernel? As in install optimal route from evpn table into eth table, if route is withdrawn put the next best route from evpn table into eth table. And 1:1 sync eth table to kernel. I don't plan to further adjust my "patch" so feel free to treat this as a bug report but I would appreciate to hear what you think if I may steal some of your time. Thanks for the fun, Tomáš

2 1

Documentation typo in filter example (bird-2.17.1.html#filters)
by Evgeniy Gaydarenko 19 Mar '26

19 Mar '26

Hello, I noticed a small typo in the HTML documentation for BIRD 2.17.1, in the Filters section: https://bird.nic.cz/doc/bird-2.17.1.html#filters In the example filter *not_too_far*, the comparison uses the HTML entity *&g* t instead of the literal *>* character. If you copy the example as-is into a BIRD configuration file, the line *if rip_metric &gt 10 then* causes a “Unknown character” error when BIRD parses the configuration. Replacing &gt with > fixes the problem: *if rip_metric > 10 then* It would be helpful if the documentation could be updated so the example uses the correct > character, to avoid confusing users who copy the example directly. Best regards, Evgeniy Gaydarenko gaydarenko(a)mail.ru

2 1

bird 3.2.0 crashes: "Attempted to start channel's already started export"
by Arkadiusz Miśkiewicz 18 Mar '26

18 Mar '26

Upgraded to 3.2.0 (from 1.x) on ancient i686 machine, running bird with -R and #0 0xb7ef9569 in __kernel_vsyscall () #1 0xb7cc7ab7 in ?? () from /lib/libc.so.6 #2 0xb7c71171 in raise () from /lib/libc.so.6 #3 0xb7c59216 in abort () from /lib/libc.so.6 #4 0x08148c71 in bug (msg=msg@entry=0x815e7b8 "%s.%s: Attempted to start channel's already started export") at sysdep/unix/log.c:412 #5 0x080af197 in channel_start_export (c=c@entry=0x9ab5e60) at nest/proto.c:780 #6 0x080b2d0b in graceful_recovery_done (_=0x81d30d0 <_graceful_recovery_context+16>) at nest/proto.c:2082 #7 0x08090182 in ev_run_list_limited (l=<optimized out>, limit=4294967293, limit@entry=4294967295) at lib/event.c:338 #8 0x0813eb77 in io_loop () at sysdep/unix/io.c:2646 #9 0x0804b32e in main (argc=2, argv=0xbfea0d24) at sysdep/unix/main.c:1111 Fed claude with the problem and its "findings" were like this below (bird doesn't crash with this "fix" but I can't tell if this is the right fix or papering of the real bug) Kernel: skip export start in krt_init_scan() when gr_wait is set When graceful restart recovery is active (-R), krt_start() sets gr_wait=1 on the kernel channel to defer export until recovery completes (via graceful_recovery_done()). However, krt_init_scan() unconditionally calls channel_start_export() when transitioning from KPS_INIT, without checking gr_wait. When graceful_recovery_done() later runs, it finds gr_wait=1 and tries to start the export again, triggering: bug("%s.%s: Attempted to start channel's already started export") Reported on bird-users by Christoph (Jan 2026) for BIRD 3.1.5. Still present in 3.2.0 despite bda2178e ("Kernel: pause exports also on restart until scan is done") which set rt_notify=NULL in krt_start() but didn't address the krt_init_scan() path. Skip channel_start_export() in krt_init_scan() when gr_wait is set, letting graceful_recovery_done() handle it instead. --- a/sysdep/unix/krt.c +++ b/sysdep/unix/krt.c @@ -449,7 +449,9 @@ krt_init_scan(struct krt_proto *p) case KPS_INIT: /* Allow exports now */ p->p.rt_notify = krt_rt_notify; - channel_start_export(p->p.main_channel); + /* When gr_wait is set, graceful_recovery_done() will start the export */ + if (!p->p.main_channel->gr_wait) + channel_start_export(p->p.main_channel); rt_refresh_begin(&p->p.main_channel->in_req); p->sync_state = KPS_FIRST_SCAN; return 1; - The upstream fix bda2178e / 47ed4aa0 is already in 3.2.0 — it sets rt_notify = NULL in krt_start() to defer exports - But it's incomplete — krt_init_scan() still unconditionally calls channel_start_export() on first scan timer, without checking gr_wait - This is a new bug in the 3.2.0 release, not present in older code (since 91c98efe introduced the KPS_INIT state machine) - The fix on the 372-release-v3.2.1 branch has the same code — the bug will still be in 3.2.1 unless they pick up a further fix - Our patch is the correct minimal fix for this -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

1 1

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

bgp template inheritance
by BASSAGET Cédric 03 Mar '26

03 Mar '26

Hello, I'm trying to simplify my old bird 1.6 config, the aim is migrating to v2 then v3. I have a config like : template bgp private_peering_ipv4 { local as my_ans; path metric 2; ipv4 { import all; import filter { if (net.len > 24 ) then reject; bgp_large_community.add((my_asn, 1, 1003)); accept; }; export filter export_my_routes_ipv4; import keep filtered; }; } protocol bgp PEER_v4_peer1 from private_peering_ipv4 { router id 195.42.145.x; neighbor 195.42.144.104 as 6939; } protocol bgp PEER_v4_peer2 from private_peering_ipv4 { router id 195.42.145.x; neighbor 195.42.144.104 as 6939; ipv4 { import filter { bgp_large_community.add((my_asn, 1, 1009)); accept; }; }; } the problem here is that as soon as I define a new import filter for my second peer, the filter from the template is omitted. Is there a way to add inheritance between the templates, or anything else that wouldn't overwrite the template filters ? Regards, Cédric

3 2

[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