August 2025 - Bird-users

Re: [PATCH v5] Babel: Replace internal route selection by bird's nest
by nick 26 Oct '25

26 Oct '25

Hello, We're still waiting for any feedback on this useful patch. We've been running it in our mesh network with nearly 200 nodes. I'm also considering submitting it to the routing feed (cc @Toke), and I hope the patch will be adapted for BIRD 3 as well. For reference, here's the original post: https://bird.network.cz/pipermail/bird-users/2023-February/016705.html Tested-by: Nick Hainke <vincent(a)systemli.org> Best regards, Nick

3 3

Display BGP gateway mode in show protocol output
by Sébastien PARISOT 10 Sep '25

10 Sep '25

Hello BIRD team! This simple patch (for branch master) adds a field for the BGP channel gateway mode (direct or recursive) setting in show protocol output. It is is a useful information to have in some troubleshooting scenario. Example: bird> show protocol all bgp_test Name Proto Table State Since Info bgp_test BGP --- up 2025-08-12 15:11:54 Established BGP state: Established [...] Channel ipv6 State: UP [...] Gateway: recursive [...] Thanks! -- Sébastien

8 19

Questions on handling bytestring attributes and using them in preference logic
by yazan slaila 03 Sep '25

03 Sep '25

Dear BIRD Developers, I am currently experimenting with custom BGP attributes using bytestring type within a topology that consists of 8 routers. My goal is to display and handle the newly added custom attributes and be able to see the value for each router in all other routers, like the AS_path idea: router1: 50 router2: 50 35 router2: 50 35 70 Because I want to reach a point where I can decide the lowest value for this cutom attribute and choose the best path based on that lowest value, but the problem is that I can't perform operations on attribute type bytestings due to implementation limitations. Now I have two main questions: 1. Working with bytestring values to be able to decide the best path based on the lowest total path cost we have: * Is there a recommended way to parse, compare, or extract numbers from a bytestring attribute within a BIRD filter? And how? * Currently, the raw output prints hexadecimal sequences (e.g., 31:30). How should these be decoded/processed for comparisons? * How can I apply this idea using the bytestring type to add a value to each router and then advertise it to every other router (in the topology of 8 routers) to decide what is the best path to take based on the lowest cost value we have? 2. Preference logic example: * How can a bytestring attribute be integrated into preference calculation in a filter? * The documentation shows how to set preference based on integers or communities, but I couldn’t find a concrete example for bytestring. Could you provide a minimal example filter to illustrate this in order to prefere the path that has the lowest values? Any guidance or best practices on working with bytestring attributes for routing decisions would be greatly appreciated. Best regards, Yazan

2 3

[PATCH] Wrong calculation in as_path_getlen, and check_aspa improvement suggestion
by Alarig Le Lay 02 Sep '25

02 Sep '25

Hello, We (Evann and I) found a bug related to as_path_getlen() when used by aspa_check(). When a route contains an AS_SET segment type, the length returned by as_path_getlen() is incorrect. The function assumes that the length of an AS_PATH_SET is a single AS (1), while in reality an AS_PATH_SET is an unordered set of ASN (as described here https://www.rfc-editor.org/rfc/rfc4271#section-9.2.2.1) See the following update: 2025-08-31 15:35:15.134 <INFO> Checking prefix 76.165.0.0/16 (path 208627 29075 174 32440 {2055 10349 22985 23207 23294 23366 26002 26303 26333 30564 54529 396992 401290}) IN from bgp_alarig_ipv4 Using gdb we can inspect the path object: (gdb) p path->length $101 = 72 (gdb) x /72xb path->data 0x555555725e54: 0x02 0x04 0x00 0x03 0x2e 0xf3 0x00 0x00 0x555555725e5c: 0x71 0x93 0x00 0x00 0x00 0xae 0x00 0x00 0x555555725e64: 0x7e 0xb8 0x01 0x0d 0x00 0x00 0x08 0x07 0x555555725e6c: 0x00 0x00 0x28 0x6d 0x00 0x00 0x59 0xc9 0x555555725e74: 0x00 0x00 0x5a 0xa7 0x00 0x00 0x5a 0xfe 0x555555725e7c: 0x00 0x00 0x5b 0x46 0x00 0x00 0x65 0x92 0x555555725e84: 0x00 0x00 0x66 0xbf 0x00 0x00 0x66 0xdd 0x555555725e8c: 0x00 0x00 0x77 0x64 0x00 0x00 0xd5 0x01 0x555555725e94: 0x00 0x06 0x0e 0xc0 0x00 0x06 0x1f 0x8a In this example, we have a route with an AS_PATH that contain: - an AS_PATH_SEQUENCE (0x02) with a length of 4 (0x04): (208627 29075 174 32440); - an AS_PATH_SET (0x01) with a length of 13 (0x0d): {2055 10349 22985 23207 23294 23366 26002 26303 26333 30564 54529 396992 401290}. The total length of this update is then 17, but if we dump the function result, we can see that the actual computed length is 5 (4 + 1 for the AS_PATH_SET). (gdb) p len $103 = 5 This leads to a too small memory allocation, when normalizing the AS Path in aspa_check(): /* Normalize the AS Path: drop stuffings */ u32 *asns = alloca(sizeof(u32) * len); Causing a SEGFAULT during the as path walk. Since as_path_walk() considers each element of the AS_PATH_SET as a step. In the while (as_path_walk(path, &ppos, &asns[nsz])), the asns object should have a size of 17 and not 5 resulting in overwriting memory and finally triggering a SEGFAULT. (However we've seen this working when the AS_SET is small, for example, it's working for the following route, but this is mostly luck and could lead to weird behaviors): Checking prefix 104.141.0.0/16 (path 208627 29075 174 32440 {400943}) IN from bgp_alarig_ipv4 Here is the gdb output showing this behaviour: 2025-08-31 15:35:15.134 <TRACE> bgp_alarig_ipv4: Got UPDATE 2025-08-31 15:35:15.134 <INFO> Checking prefix 76.165.0.0/16 (path 208627 29075 174 32440 {2055 10349 22985 23207 23294 23366 26002 26303 26333 30564 54529 396992 401290}) IN from bgp_alarig_ipv4 Thread 1 "bird" received signal SIGSEGV, Segmentation fault. 0x00005555555d68ac in as_path_walk (path=0x5555000066dd, pos=0x7fffffffd15c, val=0x7fffffffd144) at nest/a-path.c:702 702 const u8 *q = p + path->length; (gdb) p path->data $1 = 0x5555000066e1 <error: Cannot access memory at address 0x5555000066e1> And here is a dump of asns just before the segfault : (gdb) p *asns@nsz+1 $57 = {208627, 29075, 174, 32440, 2055, 10349, 22985, 23207, 23294, 23366, 26002, 26303, 26333} We propose to set the AS_PATH_SET length to the announced length in the AS_PATH data instead of 1, see 0001-NEST-correct-as_path-len-calculation.patch. Furthermore, as per https://datatracker.ietf.org/doc/html/rfc9774#name-updates-to-the-requireme… (BGP speakers MUST use the "treat-as-withdraw" error handling behavior per [RFC7606] upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs in the AS_PATH or AS4_PATH [RFC6793]) and even if https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-… changes it to a SHOULD, another improvement we propose is to check for AS_PATH_SET the same way it’s already done for AS_PATH_CONFED_SEQUENCE and AS_PATH_CONFED_SET at the beginning of the aspa_check() (see 0002-NEST-return-ASPA_INVALID-for-path-containing-AS_SET.patch). The proposed patch is only for ASPA, not for ROV, in order to avoid dropping routes for too much people, and the patch only drop a few amounts of routes (including a few routes dropped for invalid ROV) : Routes: 1031692 imported, 212 filtered, 0 exported, 1031692 preferred Don’t hesitate to discuss the patch if needed, -- Alarig and Evann

5 6

3.1.2 / routes disappear from kernel
by Alexander Javoronkov 31 Aug '25

31 Aug '25

Greetings, I have stumbled on a problem with the new (v3) BIRD. I've been using v2 (still using 2.15.1 on old systems) over the years without problems. The kernel4 protocol is defined with the following options: * persist off; (I need the routes to exist only when the BIRD is running) * scan time 86400; (BIRD v2 had a very hard time scanning Full View routing tables, so I have incremented this number) * learn off; (I only need to export routes to the kernel) // Disregard the full view comment, I am having a problem even with a simplest setup with 1 or 2 routes. "birdcl show route export kernel4" shows that routes are supposed to be exported to the kernel: 10.0.4.0/24 unicast [users 16:43:23.752 from fe80::be24:11ff:fe00:303] * (100) [AS65004i] via 10.0.3.3 on eth1 However, when I check the routes (ip -4 r), they are not there. If I run the "birdcl configure", the routes do not appear. If I restart the protocol with "birdcl restart kernel4", I start to see the routes in the routing table. Some time passes (something about an hour) and they disappear (without a single message in the logs). Please advise how can I further debug/fix this problem. LXC, CentOS 9 Stream, bird-3.1.2-1.el9.x86_64

2 1

BGP and passwords
by Elmar K. Bins 27 Aug '25

27 Aug '25

Hello friends, running current BIRD2 on FreeBSD, 2.17.1. Starting a few updates ago I get a nagging warning in my log files for BGP sessions that carry a password, namely: --- /usr/local/etc/bird.peers:94:1: Missing authentication option, assuming MD5 --- Yet, when I try to add the algo option, like this: --- protocol bgp <nei> from <templ> { neighbor <ip>; password "<pass>" { algorithm MD5; }; }; --- BIRD still hates on me: --- /usr/local/etc/bird.peers:94:20 syntax error, unexpected '{', expecting ';' --- I suppose this only works with BIRD 3? BIRD2 documents as follows: --- password string Use this password for MD5 authentication of BGP sessions (RFC 2385). When used on BSD systems, see also setkey option below. Default: no authentication. --- So - how do I fix this? Thanks for any help, Elmar.

4 5

BIRD 3 thread group configuration syntax
by Robert Lister 27 Aug '25

27 Aug '25

Hello, According to the docs for v3.1.2 and v3.1.1: https://bird.nic.cz/doc/bird-3.1.2.html#global-opts *Thread setup* [..] Thread groups are configured by writing thread group /name /{} blocks, which contain the following options: threads /number/ default /bool/ /[...]/ It also notes the following: There is also a "simple" thread group setting. If you write *threads */number/ on top level, it is equivalent to setting the worker group thread count to that number, and the express group thread count to one. This setting is deprecated and may disappear in some future version. So.. now I come to setting up a new server, I thought I'd better try to use this "new" config style. But whatever I try doesn't seem to work. I've tried various iterations of: thread group worker { threads 1; } --> <FATAL> /etc/bird/bird.conf:55:10 No default thread group configured thread group worker { default; threads 1; } --> <FATAL> /etc/bird/bird.conf:43:2 syntax error, unexpected THREADS, expecting '}' thread group worker { threads 1; default yes; } --> <FATAL> /etc/bird/bird.conf:43:2 syntax error, unexpected DEFAULT, expecting '}' thread group worker { threads 1; default; } --> <FATAL> /etc/bird/bird.conf:43:2 syntax error, unexpected DEFAULT, expecting '}' Weirdly, if I configure only "default;" with no other options, it accepts the config: thread group worker { default; } root@rc01:/# /usr/local/sbin/bird -c /etc/bird/bird.conf -p root@rc01:/# If I add the (deprecated) top-level "threads", it complains I've got them both configured: threads 1; thread group worker { default; threads 1; } --> <FATAL> /etc/bird/bird.conf:41:14 Mixing of `threads NUM` and `threads worker {}` is not allowed. As soon as I try any other config options, it doesn't accept it: thread group worker { default; wakeup time 31415 s; } --> <FATAL> /etc/bird/bird.conf:43:2 syntax error, unexpected WAKEUP, expecting '}' Also tried: thread group { worker { threads 1; default; }; } --- - nope. thread group worker { threads 1; } thread group express { threads 1; } --> <FATAL> /etc/bird/bird.conf:45:14 syntax error, unexpected EXPRESS, expecting CF_SYM_KNOWN or CF_SYM_UNDEFINED --- thread group worker { threads 2; default; } --> <FATAL> /etc/bird/bird.conf:43:2 syntax error, unexpected DEFAULT, expecting '}' --- thread worker { threads 2; default; } --> <FATAL> /etc/bird/bird.conf:41:8 syntax error, unexpected CF_SYM_UNDEFINED, expecting GROUP So, it seems the "default" option must be present, but if I add /any /other option, it doesn't accept it. Oddly, if I put another option before default, it doesn't complain about that, but instead complains about "default" being there. I tried various 3.x versions 3.1.1, 3.1.2 and a couple of recent branches from git repo. As for the config - I just have the default bird.conf which ships with the BIRD debian package, and I've added the thread group option somewhere near the top. Any hints on the correct config would be appreciated. Or is this maybe a bug? Thanks! Rob -- Rob Lister rob(a)lonap.net +44 20 3137 8330

2 1

Guidance on using custom BGP attributes for traffic engineering
by yazan slaila 26 Aug '25

26 Aug '25

Hello there, I am currently working on my thesis and experimenting with the BIRD routing daemon. As part of my work, I added a new optional transitive BGP path attribute using the following configuration line: attribute bgp 200 bytestring new_attribute; The attribute appears correctly in the routing table as follows: (birdc show route all) 192.168.5.0/24 unicast [router5 15:00:40.321] * (100) [AS5i] via 10.0.51.5 on eth2 Type: BGP univ BGP.origin: IGP BGP.as_path: 5 BGP.next_hop: 10.0.51.5 BGP.local_pref: 100 BGP.c8 [t]: 20 And this is the way I declare it in my bird.conf file: filter export_with_new_attribute { new_attribute = hex:20; accept; } But now I would like to use it as part of traffic engineering decisions. Specifically, I would like to understand what steps are required in order to make this new attribute influence the BGP decision-making process for choosing the best path to route the traffic. Could you please advise: 1. Which files and functions in the BIRD source code are responsible for the BGP path selection process that I need to edit to make my new attribute come after LOCAL_PREF attribute in the priority list? Or if there is a way to do this without the need to edit the source code. 2. Are the previous things correct to add a custom path attribute that is doing something? 3. Why is it displaying like this: BGP.c8 [t]: 20? Is there a way to make it appear like this: BGP.new_attribute [t]: 20? 4. Is there a standard or recommended way to extend BIRD so that a custom attribute can be incorporated into route preference / best path selection, and if I want to compare 2 values and choose the lowest path that has this value? I would greatly appreciate any pointers or guidance that could help me move forward because I did not find any clues on that in your documentation. Thank you very much for your time and support. Best regards, Yazan.

3 2

Stack buffer overflow during obj/filter/filter_test execution
by Sergey L 24 Aug '25

24 Aug '25

Hi, ASAN reports stack-buffer-overflow in ip6_getbit() function during obj/filter/filter_test execution. How to reproduce the issue without ASAN: apply the following patch: diff --git a/lib/ip.h b/lib/ip.h index bae05261..e76ded9c 100644 --- a/lib/ip.h +++ b/lib/ip.h @@ -13,6 +13,7 @@ #include "lib/string.h" #include "lib/bitops.h" #include "lib/unaligned.h" +#include <stdio.h> #define IP4_ALL_NODES ipa_build4(224, 0, 0, 1) @@ -331,7 +332,9 @@ static inline u32 ip4_getbits(ip4_addr a, uint pos, uint n) { return (_I(a) >> ((32 - n) - pos)) & ((1u << n) - 1); } static inline u32 ip6_getbit(ip6_addr a, uint pos) -{ return (a.addr[pos / 32] >> (31 - (pos % 32))) & 0x1; } +{ +fprintf(stderr,"pos=%u\n",pos); + return (a.addr[pos / 32] >> (31 - (pos % 32))) & 0x1; } static inline u32 ip6_getbits(ip6_addr a, uint pos, uint n) { return (a.addr[pos / 32] >> ((32 - n) - (pos % 32))) & ((1u << n) - 1); } Then run the commands: autoreconf ./configure make -j make check -j obj/filter/filter_test You will see the following lines: pos=127 pos=128 (stack overflow is here) pos=129 pos=130 pos>=128 is invalid due to a.addr is 4xu32, it's not not 5xu32

2 2

BIRD 3.1.0, 2.17, 3.0.2, 2.16.2 released
by Ondrej Filip 24 Aug '25

24 Aug '25

Dear BIRD Users, we have released four versions of BIRD at once; 2.17 and 3.1.0 with new features and 2.16.2 and 3.0.2 fixing bugs in 2.16.1 and 3.0.1, respectively. It may become common in the future to keep certain versions stable with only fixes for some longer time. Specifically, 3.1.0 and 2.17 have already successfully migrated to Debian testing, so these versions may get quite a long chain of updates. In 2.17 and 3.1.0, we added TCP-AO support for BGP on Linux. We haven't found any resource for TCP-AO in any flavor of BSD; if you know of any, please tell us. We also implemented graceful restart timer minima and maxima in BGP, format specification for link-local-only next hops in BGP, to improve compatibility with other routing stacks, and also we merged a new next hop option for IPv4 routes in Babel. In 3.1.0, we also added a compatibility layer for show route outputs, to allow your BIRD 2 automation to work with BIRD 3. Please tell us if you find any significant difference there. In all versions, we fixed several rare crashes in BFD and table removal, and other minor bugs. In 3.1.0 and 3.0.2, we also fixed quite some crashes in route propagation and state machines. Also setting route gateway in 3.x by filters is now fixed. It also looks like that some bugs in 3.1.0 slipped through our release process, most notably failure to build on FreeBSD 13 with Netlink and some strange crash on BGP neighbor flap. We are currently investigating that and we may release 3.1.1 soon. We apologize for for that. Anyway, the packages are as always in our repository at https://pkg.labs.nic.cz/ and on our website at https://bird.network.cz/ Have a pleasant spring or autumn, and happy routing! Ondrej and Maria

6 5