- Bird-users - Mailing Lists

Question about extracting values from bgp_ext_community in BIRD
by yazan slaila 15 Sep '25

15 Sep '25

Hello there, I am currently working with BGP route filtering in BIRD daemon, specifically with the bgp_ext_community attribute. I want to understand how to properly extract individual values from tuples inside the bgp_ext_community list. For example, when an extended community contains something like (rt, 1, 10), I need to store the third value (10) into a variable and use it in my filter logic. I want to iterate with a for loop on the ext_community list (ec) and extract the last value. For example: # Iterate through all extended communities for ec c in bgp_ext_community do { print "Yaz: " , c; And the output: bird: Started bird: Yaz: (rt, 2, 70) bird: Yaz: (rt, 3, 90) bird: Yaz: (rt, 4, 80) bird: Yaz: (rt, 5, 20) I also tried accessing fields with .type or .val, but that seems unsupported --> c.type, or c.val Could you please clarify: 1. What is the correct way to iterate over bgp_ext_community in a filter? 1. How can I extract individual values (e.g., asn, value) from a route target community like (rt, 1, 10)? 2. Are there predefined functions or operators in BIRD to work with extended community tuples? Any guidance or documentation pointers would be greatly appreciated. Thank you for your time and for the excellent work on BIRD. Best regards, Yazan.

1 0

Assertion 'DG_IS_LOCKED(p->domain)' failed at lib/resource.c:449
by Rob Lister 15 Sep '25

15 Sep '25

Hmm. BIRD 3.1.3 seems to crash after a while with this: <BUG> Assertion 'DG_IS_LOCKED(p->domain)' failed at lib/resource.c:449 Anyone seen this before/know what this is about? Thanks, Rob -- Rob Lister rob(a)lonap.net +44 20 3137 8330

2 1

Writing filters that change output depending on peer
by Nico Schottelius 14 Sep '25

14 Sep '25

Hello, we are having a bit of a "special case" on various ASNs that we'd like to implement as clean as possible in bird: For a number of ASNs that we control we would like to emit the same set of networks (as in filtered, the actualy networks might be different) PLUS a test network that allows us to verify that the specific link is working from the outside. Or in other words: - ASN_A sends routes defined in filter "to_outside" to EXT_ASN_1 PLUS 2001:db8:1::/48 - ASN_A sends routes defined in filter "to_outside" to EXT_ASN_2 PLUS 2001:db8:2::/48 - ASN_B sends routes defined in filter "to_outside" to EXT_ASN_3 PLUS 2001:db8:3::/48 - ASN_B sends routes defined in filter "to_outside" to EXT_ASN_4 PLUS 2001:db8:4::/48 ... The routes defined in "to_outside" are basically all locally known /48's of a specific /32. What I was looking for is whether I can match on the peer in the filter, something like that: -------------------------------------------------------------------------------- function has_internet_length() -> bool { if ((net.type = NET_IP6 && net.len > 48) || (net.type = NET_IP4 && net.len > 24)) then { return false; } return true; } filter to_outside { if(!has_internet_length()) then reject; case peer in ext_asn_1: if(net ~ [ 2001:db8:1::/48 ]) then accept; ext_asn_2: if(net ~ [ 2001:db8:2::/48 ]) then accept; ext_asn_3: if(net ~ [ 2001:db8:3::/48 ]) then accept; ext_asn_4: if(net ~ [ 2001:db8:4::/48 ]) then accept; ... reject; } -------------------------------------------------------------------------------- Obviously above syntax is not bird syntax, but I think it is clear what I mean. It would be possible to write some functions and then for each peer define a different filter only differing by a single line, but it "feels wrong" to repeat all that code: -------------------------------------------------------------------------------- filter asn_a_to_ext_asn_1 { if(some_main_function()) then accept; if(net ~ [ 2001:db8:1::/48 ]) then accept; } filter asn_a_to_ext_asn_2 { if(some_main_function()) then accept; if(net ~ [ 2001:db8:1::/48 ]) then accept; } filter asn_b_to_ext_asn_3 { if(some_main_function()) then accept; if(net ~ [ 2001:db8:3::/48 ]) then accept; } filter asn_b_to_ext_asn_3 { if(some_main_function()) then accept; if(net ~ [ 2001:db8:4::/48 ]) then accept; } -------------------------------------------------------------------------------- How would you solve that cleanly in bird? I'm looking forward to your ideas. BR, Nico -- Sustainable and modern Infrastructures by ungleich.ch

4 6

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

BIRD 3.1.3 and 2.17.2 released
by Maria Matejka 04 Sep '25

04 Sep '25

Dear BIRD Users, we have released versions 3.1.3 and 2.17.2 of BIRD, with the patch contributed by Evann Dreumont and Alarig Le Lay, fixing ASPA crash with AS Sets. Thank you so much! In 2.17.2, we also included a configuration parser rare crash fix, which has already been fixed in 3.1.2. The git branches contain more commits but all of these are just technical updates of our CI machinery. There are some more outstanding patches and not-yet-fully-investigated crashes in BIRD 3.1 so you may expect BIRD 3.1.4 after we process all the reports. Also there is quite a delayed BIRD 2.18 and BIRD 3.2 release which has now been postponed to the second half of September. The packages are, as always, in our repository at https://pkg.labs.nic.cz/ and on our website at https://bird.nic.cz/ If you are traveling to APNIC in Da Nang, see you there soon! Happy routing! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

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