September 2025 - Bird-users

Help with peering, routes are not being imported
by Marek Küthe 16 Sep '25

16 Sep '25

Hello dear mailing list, naain and I are trying to set up peering, but it's not working. We are doing the peering via a WireGuard tunnel. This is working. We can ping each other's endpoints without any problems. On my side, it shows me that I am exporting the routes. However, naain's bird does not show any imported routes (despite a filter that accepts everything). We enabled the debug function for testing purposes and he received "filtered out" log messages. Neither he nor I can explain this, since the import filter accepts everything. I am using bird 2.17.2 on Debian 13 and he is using bird 2.15.1 on OpenWrt. Does anyone have any idea what the problem could be? Best regards, Marek Küthe -- Marek Küthe m.k(a)mk16.de er/ihm he/him

2 1

Display of an incorrect value in BFD "Remote state" in BIRD 3.1.3
by Andrey Ziltsov 16 Sep '25

16 Sep '25

Hello. I noticed an issue in BIRD version 3.1.3 with the display of the "Remote state" when showing the status of a BFD session. For all BFD sessions, the state is shown as "Remote state: Init". For example: # birdc show bfd sessions address 195.208.208.100 all BIRD 3.1.3 ready. bfd_v6: bfd_v4: Address: 195.208.208.100 Interface: vlan701 Session type: Direct Session state: Up *Remote state: Init* Last state change: 11:32:02.130 Local diagnostic: None Remote diagnostic: None Local discriminator: XXXXXXXX Remote discriminator: XXXXXXXX Transmit timer: 0.698 / 1.000 Detect timer: 4.234 / 5.000 Local parameters: Min TX interval: 1.000 Min RX interval: 1.000 Demand mode: No Multiplier: 5 Remote parameters: Min TX interval: 1.000 Min RX interval: 1.000 Demand mode: No Multiplier: 5 At the same time, in version BIRD 3.1.2 it is displayed as follows: # birdc show bfd sessions address 195.208.208.100 all BIRD 3.1.2 ready. bfd_v6: bfd_v4: Address: 195.208.208.100 Interface: vlan701 Session type: Direct Session state: Up *Remote state: Up* Last state change: 11:29:29.994 Local diagnostic: None Remote diagnostic: None Local discriminator: XXXXXXXX Remote discriminator: XXXXXXXX Transmit timer: 0.729 / 1.000 Detect timer: 4.596 / 5.000 Local parameters: Min TX interval: 1.000 Min RX interval: 1.000 Demand mode: No Multiplier: 5 Remote parameters: Min TX interval: 1.000 Min RX interval: 1.000 Demand mode: No Multiplier: 5 In BIRD version 2.17.2 the state is displayed as: # birdc show bfd sessions address 195.208.208.100 all BIRD 2.17.2 ready. bfd_v4: Address: 195.208.208.100 Interface: vlan701 Session type: Direct Session state: Up *Remote state: Up* Last state change: 10:07:54.557 Local diagnostic: None Remote diagnostic: None Local discriminator: XXXXXXXX Remote discriminator: XXXXXXXX Transmit timer: 0.651 / 1.000 Detect timer: 4.550 / 5.000 Local parameters: Min TX interval: 1.000 Min RX interval: 1.000 Demand mode: No Multiplier: 5 Remote parameters: Min TX interval: 1.000 Min RX interval: 1.000 Demand mode: No Multiplier: 5 It seems that in BIRD 3.1.3 the "Remote state" is displayed incorrectly.

1 0

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