- Bird-users - Mailing Lists

BIRD performance in a dynamic scenario
by Maxime Peim (mpeim) 01 Jun '25

01 Jun '25

Hi everyone, First of all, thanks a lot for BIRD ! I have some questions about the dynamicity of BIRD wiht BGP. In a scenario where routes needs to be updated accondingly depending on some external informations, I find out that those informations would need to be written into the BIRD configuration file. As an example, if we need to add a bgp community based on the peer address (already known), we would need something like that : ```bird function get_community_from_peer_address(ip addr) -> pair { case addr { <addr1> : (1,1) ; <addr2> : (245, 12434) ; … else : (0, 0) ; } } ``` And we could update that function if needed in the future but the configuration will need to be parsed each time. If the rate of update is high, it can become a bootleneck. So I would like to know if I am going the right direction doing that way ? Is there a plan for a direct API to BIRD internals instead of passing a configuration file ? Thanks in advance for your answer, Maxime Peim

2 6

[PATCH v3.1] BFD: remove unused spinlock
by Zhang Maiyun 01 Jun '25

01 Jun '25

The only use of the spinlock in `struct bfd_proto` was removed in 38acb415f and now it should be fine to remove it. The check for `pthread_spin*` in `aclocal.m4` is also removed accordingly. This makes it possible to port BFD support to platforms without spinlocks (e.g. Darwin) Signed-off-by: Zhang Maiyun <me(a)maiyun.me> --- aclocal.m4 | 4 ++-- proto/bfd/bfd.h | 2 -- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/aclocal.m4 b/aclocal.m4 index dd5cca35..7fc9c995 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -91,8 +91,8 @@ AC_DEFUN([BIRD_CHECK_PTHREADS], [ pthread_t pt; pthread_create(&pt, NULL, NULL, NULL); - pthread_spinlock_t lock; - pthread_spin_lock(&lock); + pthread_mutex_t lock; + pthread_mutex_lock(&lock); ] ) ], diff --git a/proto/bfd/bfd.h b/proto/bfd/bfd.h index 71f1090d..d8b5f8ea 100644 --- a/proto/bfd/bfd.h +++ b/proto/bfd/bfd.h @@ -82,8 +82,6 @@ struct bfd_proto { struct proto p; - pthread_spinlock_t lock; - pool *tpool; struct birdloop *eloop; -- 2.39.5 (Apple Git-154)

1 0

BIRD 3.1.1 and 3.0.3 released
by Maria Matejka 29 May '25

29 May '25

Dear BIRD users, we are releasing BIRD versions 3.1.1 and 3.0.3. We have fixed BGP route refresh in both versions, and also several build issues on FreeBSD, NetBSD, and CentOS 7. We added several table export fixes to 3.1.1 which were already included in 3.0.2. We fixed several other minor bugs and rare crashes as well. Release tarballs are available on our website <https://bird.nic.cz/get-bird>. Debian and Ubuntu packages are available in our repository at <https://pkg.labs.nic.cz/doc?project=bird>. You may have noticed that the person tagging the version and sending this e-mail has changed. There is also a change in the website URL. I'll send a full e-mail summarizing the organizational changes during the next week. Happy routing! Maria, with Ondrej's approval -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

5 10

handling of the onlink next hop
by Radu CARPA 28 May '25

28 May '25

Hi team, We've just got the update of bird (bird-2.16.2-1.el9.x86_64->bird-3.1.1-1.el9.x86_64) delivered via rpm updates and it broke our configuration with the following error message: `/etc/bird.conf:7:5 syntax error, unexpected ONLINK` By reading the migration guide, i see that it was a deliberate choice to stop supporting this attribute: "The|onlink|route attribute has been temporarily disabled until we find out how to implement it properly." We used the functionality implemented in 7144c9ca46f092da33a4e051bbce8f973a3bd8c4 . In particular, with the following configuration: ``` ifname = "tunl0"; onlink = true; gw = from; ``` Is there a plan to bring back support for it in the nearby future? If not, I will try to get in touch with the maintainer of the package in EPEL to see if it's possible to submit and keep maintaining a "bird2" branch of this package in EPEL. Regards, Radu

3 7

BIRD 3.1.2 and 3.0.4 released
by Maria Matejka 28 May '25

28 May '25

Dear BIRD users, we are releasing BIRD versions 3.1.2 and 3.0.4. We have fixed several crashes in table exports, broken ASPA checks, a crash in MRT, and a logging bug in configure undo. Packages are available on our website <https://bird.nic.cz/get-bird>. Debian and Ubuntu packages are available in our repository at <https://pkg.labs.nic.cz/doc?project=bird>. Also, I have promised an organizational update to you, and I haven't done it yet. We were working hard on fixing all of these reported regressions, so this went a bit aside. Sorry for that, gonna do it very very soon. Thanks to the whole team for fixing and testing! Happy routing! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

Interaction of OSPFv2 and PtP tunnels (bug?)
by LEdoian 27 May '25

27 May '25

Hello! I seem to have hit a strange inconsistency when OSPFv2 does not create routes for its PtP transit interfaces and am not sure whether I am misunderstanding the protocol. I managed to reduce my case into the following setup (full Linux netns reproducer script is at the end): There are three machines, called Local, Remote and Foreign and OSPFv2 running among them. Local is the middle one, having a virtual ethernet to Foreign (IP addresses 10.2.0.0/24) and a 4in6 tunnel to Remote (10.1.0.1 and 10.1.0.2). Moreover, the Local and Remote machines have a dummy interface with another local address (10.0.0.1, 10.0.0.2). In this case, OSPF converges, but the routing tables on Local and Remote are missing the route for 10.1.0.0/30: ``` Table master4: 10.2.0.0/24 unicast [ospf1 03:24:08.362] * I (10/100) [0.0.0.3] dev en_f 10.0.0.1/32 unicast [ospf1 03:23:27.361] * I (10/0) [0.0.0.1] dev dummy0 10.0.0.2/32 unicast [ospf1 03:23:43.363] * I (10/100) [0.0.0.2] via 10.1.0.2 on tun0 ``` OSPF is about the 10.1.0.0/30 addresses, breaking connection between Foreign and Remote. Surprisingly, if the tunnel interface is marked as stub, then the route is imported in the same manner as the route on the veth (but the toy network now has two independent instances of OSPF, effectively being split). The missing route can be added by enabling the Direct protocols but this feels quite off, as the route should not be external to OSPF. Also, the Direct protocol documentation suggests that this should not be necessary: “OSPF protocol creates device routes for its interfaces itself […]”. My reproducer runs on Arch Linux with BIRD 3.1.1, but also appears on my router running BIRD 2.13.1. Am I misunderstanding something, or is this actually a bug? Best regards, LEdoian --- #!/bin/bash # intended to be run inside `unshare -rnmpf --mount-proc` # uses tmux to keep sessions and to run BIRDs in background set -e dir="$(mktemp -d)" mount -t tmpfs bird-repro "$dir" trap 'cd / && umount --recursive "$dir" && rmdir "$dir"' EXIT # does not work cd "$dir" cat >bird.inc <<GO log stderr all; debug protocols all; protocol device { } protocol direct{ ipv4; disabled; } protocol kernel ker4 { learn; ipv4 { preference 100; import all; export all; }; } protocol ospf v2 { ipv4 { preference 10; import all; export all; }; area 0 { interface "tun*" { cost 100; #stub; }; interface "dummy*" { cost 100; stub; }; interface "en*" { cost 100; }; }; } GO cat >local.conf <<GO router id 0.0.0.1; include "bird.inc"; GO cat >remote.conf <<GO router id 0.0.0.2; include "bird.inc"; GO cat >foreign.conf <<GO router id 0.0.0.3; include "bird.inc"; GO for x in remote local; do touch $x unshare --net=$x ip link add dummy0 type dummy nsenter --net=$x ip link set dummy0 up done nsenter --net=local ip addr add 10.0.0.1/32 dev dummy0 nsenter --net=remote ip addr add 10.0.0.2/32 dev dummy0 ip link add name ve0 type veth peer ve1 ip link set ve0 netns ./local ip link set ve1 name ve0 ip link set ve0 netns ./remote nsenter --net=local ip addr add fd00::1/64 dev ve0 nsenter --net=remote ip addr add fd00::2/64 dev ve0 nsenter --net=local ip link set ve0 up nsenter --net=remote ip link set ve0 up nsenter --net=local ip link add tun0 type ip6tnl mode ipip6 local fd00::1 remote fd00::2 nsenter --net=local ip link set tun0 up nsenter --net=local ip addr add 10.1.0.1 dev tun0 peer 10.1.0.2 nsenter --net=remote ip link add tun0 type ip6tnl mode ipip6 local fd00::2 remote fd00::1 nsenter --net=remote ip link set tun0 up nsenter --net=remote ip addr add 10.1.0.2 dev tun0 peer 10.1.0.1 touch foreign unshare --net=foreign true ip link add name en_f type veth peer en_l ip link set en_f netns ./local ip link set en_l netns ./foreign nsenter --net=foreign ip link set en_l up nsenter --net=foreign ip addr add 10.2.0.3/24 dev en_l nsenter --net=local ip link set en_f up nsenter --net=local ip addr add 10.2.0.2/24 dev en_f nsenter --net=local sysctl net.ipv4.conf.all.forwarding=1 for x in local remote foreign; do nsenter --net=$x tmux -S $x.tmux new-session -d bird -d -c $x.conf -s $x.bird done tmux

2 1

Issues running BMP protocol in v3.0.1
by admin＠nxthdr.dev 26 May '25

26 May '25

Hey, I've migrated from 2.16.1 to 3.0.1 and I'm facing some issues with the BMP protocol. The TCP session goes up but I don't receive all peers up notifications. I receive some (but not all it seems) when I restart bird after have started my BMP collector. If I do the opposite, I get none. Also, I don't receive route monitoring messages. To be precise, I receive only one route monitoring message when I receive a peer up notification. But this one is empty (meaning no announced/withdrawn prefixes in it). Also I receive it just just before the peer up, which is a bit weird. I should receive a tons of them, with announced prefixes in it, right after the peer up. Here is my BMP configuration: protocol bmp { station address ip 2a06:de00:50:cafe:100::c port 4000; monitoring rib in pre_policy; monitoring rib in post_policy;} bird> show protocols all bmp1 Name Proto Table State Since Info bmp1 BMP --- up 18:08:26.528 Established Created: 18:08:16.105 Station address: 2a06:de00:50:cafe:100::c Station port: 4000 Pending TX: 0 B (limit 1024.0 MB) Session TX: 789 B Total TX: 789 B Do you experience the same behavior? Please let me know if you need more information, I'm happy to make some other tests if needed. Best,Matthieu.

1 1

<ERR> filters, line 1: Missing AS_PATH attribute
by ushiroz＠ate-mahoroba.jp 23 May '25

23 May '25

Hi, In our BIRD 2.14 we’re running roa_check like this: if (net.type = NET_IP4) then { case roa_check(r4, net, bgp_path.last) { However, the BIRD logs show the following error: <ERR> filters, line 1: Missing AS_PATH attribute would it be advisable to add a check to determine whether the route is a BGP route before proceeding?

2 2

[2.16.1 on FreeBSD] Automatic RPKI reload not active...
by Elmar K. Bins 21 May '25

21 May '25

Hi folks, again, In my logs, I'm seeing a lot of <peer>: Automatic RPKI reload not active for import I could not find any explanation what that would mean, or whether it is a problem... Can somebody help? Thanks, Elmar.

3 10

[BUG?] Segv with latest 3.1.1
by Nicolas Lorin 21 May '25

21 May '25

Hi, I've tried to upgrade from 3.1.0 to 3.1.1 but bird daemon is crashing with a segv after some seconds. I haven't made any change to my config. Reverting to 3.1.0 fixes the problem. Running Ubuntu 24.04.02. I'm using BGP/OSPF/Kernel/Static/Direct/RPKI. I haven't had the time yet to narrow the problem down but wanted to let you know. I'll try to investigate with a limited config if I find time. Regards, -- Nicolas Lorin

4 4