- Bird-users - Mailing Lists

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

How to avoid error messages for non-RFC8950 peers
by André Grüneberg 21 Aug '25

21 Aug '25

Hi, We have lately enabled RFC8950 (BGP IPv4 routes with IPv6 nexthop) on (one of) our route servers. We did this for all the connected peers. This means two things: We added ipv4 channels to "protocol bgp"s with an IPv6 neighbor and we enabled "extended next hop" in these channels. This will announce IPv4 and the respective extended next hop capability in BGP OPEN. In an ideal world all existing peers would only have IPv6 AFI enabled on their IPv6 BGP sessions. Unfortunately some BGP implementations by default have proxy-arp^WIPv4 AFI enabled for all neighbors. So we ended up with some peers announcing IPv4 AFI but not "extended next hop". Obviously Bird now tries to send those peers all the IPv4 routes it has in the routing table. Since the route server is transparent, the routes have an IPv6 next-hop and thus we get the following error messages: 2025-08-21 08:14:24 <ERR> pb_0359_asXXXX: Invalid NEXT_HOP attribute - mismatched address family (2001:7f8:19:1:0:3:48d2:1 for ipv4) 2025-08-21 08:14:24 <ERR> pb_0359_asXXXX: Invalid route 45.91.12.0/24 withdrawn Of course I'll try to educate people to correct their configuration to get closer to the ideal world above. At the same time, I'd love to avoid those error messages. So I've been thinking how to avoid the situation we are in and came up with two potential approaches: 1. Since all session are configured in passive mode, the neighbors should send their BGP OPEN first. So upon receiving IPv4 AFI without receiving "Extended next hop - IPv6 nexthop: ipv4" we will remove IPv4 AFI from our BGP OPEN answer. 2. If we had the negotiated protocol capabilities available in the export filter, we could filter IPv4 routes with IPv6 nexthop in case extended next hop is not negotiated. Currently I only see "require extended next hop" switch, but to my understanding this will tear down the BGP session -- which is undesirable. Does anyone have other good ideas? BTW: It's not very intuitive to understand from the above error messages that the announcement is egress. :) Best wishes, André -- André Grüneberg, Managing Director andre.grueneberg(a)bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B

3 3

Hashing Algorithms in OSPFv2
by info＠p01.ch 20 Aug '25

20 Aug '25

Hi everyone I'm using BIRD for OSPFv2 and was testing some stuff the other day. Thats where I noticed something with the "authentication" config. If I go by RFC 2328, only MD5 should be supported. Further Algorithms are defined in RFC 5709, but it says nowhere if BIRD supports that. With that in mind, anything else than MD5 should trow me an error. But it doesn't. Hence my question, what happens if I configure, let's say, SHA512 or blake2b512? Does BIRD support RFC 5709 and just takes the first 64 bits or is there some other magic going on? Best regards Andy

2 1

Configuration management tool
by Paweł Maślanka 20 Aug '25

20 Aug '25

Hello BIRD users, I just wanted to let you know (announce) that I'm currently working on a project for BGP (daemon) configuration management which is an integral part of my another project. The goal is to achieve a common configuration syntax (layer) for multiple BGP daemons (e.g. BIRD, FRR, etc.). I chose the JSON schema specification as an "modelling language" for defining the configuration structure. Additionally the service provides non-RESTful Web API for configuration management. The architecture of this project can be considered as an alternative approach to the YANG & NETCONF based implementation. For more details and additional features please look at the project's repo. Supported configuration parameters in the current state of the project are almost basic and completely meet my needs. But I still actively develop the project so if anyone finds this tool helpful I'm happy to add new configuration options or features. You can find the project here: https://github.com/pawelmaslanka/RoutingConfigApi Regards, Pawel

1 0

Add a space in show route output between AS number and origin
by Sébastien PARISOT 12 Aug '25

12 Aug '25

Hello BIRD team! This simple patch (for branch master) adds a space between the AS number and the route origin in show route output, I think this improves readability. Example, current BIRD: 10.0.0.0/8 unicast [blabla] * (100/210) [AS12322i] And with the patch: 10.0.0.0/8 unicast [blabla] * (100/210) [AS12322 i] Thanks! -- Sébastien

1 0

Print igp_metric in show route output even if AIGP is set
by Sébastien PARISOT 12 Aug '25

12 Aug '25

Hello BIRD team! This patches (for master branch) modifies the output of the show route CLI command for BGP routes to always print the IGP metric value. In current BIRD, the IGP metric is only displayed if the AIGP attribute is not set. Example, current BIRD: 10.0.0.0/8 unicast [blabla] * (100/210) [AS12322i] And with the patch: 10.0.0.0/8 unicast [blabla] * (100/10/210) [AS12322i] Even with AIGP it can be useful to see the IGP metric for each routes to troubleshoot routing issues (BGP best path selection can still consider IGP metric for routes with identical AIGP value). Thanks! -- Sébastien

1 0

Bug: Cannot export static route on FreeBSD running bird 3.1
by Yuri Honegger 12 Aug '25

12 Aug '25

I'm running the following configuration that simply exports a static route to the kernel on FreeBSD with bird v3.1: protocol device { scan time 60; } protocol static { ipv4; route 10.119.0.0/24 via "en6"; } protocol kernel { ipv4 { export all; }; } For some reason, this doesn't export the route. Looking at the bird logs, for some reason the kernel protocol seems to reject the route: bird: 2025-08-10 20:08:30.783 [0001] <TRACE> kernel1: Pruning table master4 bird: 2025-08-10 20:08:30.783 [0001] <TRACE> kernel1.ipv4: route refresh end: rr 1 set 1 valid 1 pruning 0 pruned 0 bird: 2025-08-10 20:08:30.783 [0001] <TRACE> kernel1.ipv4: Feeding 10.119.0.0/24 bird: 2025-08-10 20:08:30.784 [0001] <TRACE> kernel1.ipv4 < rejected by protocol 10.119.0.0/24 ptr 000000016d18ec30 (0) src 0L 3G 0S id 1 unicast bird: 2025-08-10 20:08:30.784 [0002] <TRACE> kernel1.ipv4: table prune after refresh begin: rr 1 set 1 valid 1 pruning 1 pruned 0 bird: 2025-08-10 20:08:30.784 [0002] <TRACE> kernel1.ipv4: table prune after refresh end: rr 0 set 1 valid 1 pruning 1 pruned 1 bird: 2025-08-10 20:08:30.784 [0001] <TRACE> kernel1.ipv4 < idempotent withdraw (filtered on export) 10.119.0.0/24 ptr 0000000102e58050 (0) src 0L 3G 0S id 1 unicast bird: 2025-08-10 20:08:30.784 [0001] <TRACE> kernel1.ipv4: Export state changed from PARTIAL to READY bird: 2025-08-10 20:08:30.784 [0001] <TRACE> kernel1.ipv4: Fed up bird: 2025-08-10 20:08:30.784 [0001] <TRACE> kernel1: Table master4 pruned bird: 2025-08-10 20:08:30.784 [0001] <TRACE> kernel1.ipv4: Export drained During a debuggin session, I've traced it to the following lines things: It seems to be rejected in nest/rt-table.c, function export_filter because p->preexport returns -1 https://gitlab.nic.cz/labs/bird/-/blob/stable-v3.1/nest/rt-table.c?ref_type… Tracing that further, the actual reason it does get rejected seems to come from here in krt_capable: https://gitlab.nic.cz/labs/bird/-/blob/stable-v3.1/sysdep/bsd/krt-sock.c?re… A debugging printf showed !NEXTHOP_ONE(nh) is always false. As far as I understand, NEXTHOP_ONE returns true if there is just one nexthop, so !NEXTHOP_ONE(nh) effectively demands multiple nexthops. This contradicts the comment that no multipath is supported. Furthermore, looking at the last commit touching that line, the condition used to be !a->nh.next, which reads to me as checking that there is just one nexthop. I suspect the condition there is probably wrong and should say NEXTHOP_ONE(nh) without negation? Changing that made bird export the route just fine in a quick test. Does that make any sense? Yuri

2 1

Re: Changing route based on packet loss
by gaoxing＠huize.org 10 Aug '25

10 Aug '25

Hi Nico, I don’t think a bird has a built-in function for that. I have an experimental network connecteal network connected by bgp confederation, and I use BGP.med values for the latency of the echo link. And if the package is lost is more than 30 per cent of the bgp session can't be established because bgp requires a stable environment. I think the possible way to do that is to write some script in Python and let Python to generate some configuration to control the bird. Regards, Gaoxing Zhang Sent from my iPhone > On 10. 8. 2025, at 0:26, Nico Schottelius via Bird-users <bird-users(a)network.cz> wrote: > > > Hello fellow bird users, > > I was wondering if anyone has solved this with bird or bird plus > something: > > Assuming you have multiple, somewhat lossy links. Packet loss might be > in the range of 0-30% on each link. I would like bird to select the > current best path, based on the amount of packet loss on each link. > > I've the seen the various rtt* options in babel, but the notion there > seems to be more time(out) specific, rather than loss specific. > > Any pointers in the right direction are appreciated. > > Best regards, > > Nico > > -- > Sustainable and modern Infrastructures by ungleich.ch > <signature.asc>

1 1