June 2026 - Bird-users - Mailing Lists

Re: CentOS 7 repo not work
by Maria Matejka 13 Jun '26

13 Jun '26

Hi Zhang Xun, the reason was that my scripting missed some renaming, and therefore the exception for createrepo, which must run with `--compatibility` for centos 7, was not hit. After re-running `createrepo` and reuploading, it looks fixed on my side. Please note that CentOS 7 may get discontinued without notice when we find out that our tooling breaks beyond repair. Iŧ's hard to keep the build machinery running for a discontinued distro. Thank you for your report! Maria On Sat, Jun 13, 2026 at 10:33:43PM +0800, zx--- via Bird-users wrote: > Hi there, > > Some of my servers are still using CentOS 7 and I'm following https://bird.nic.cz/get-bird/ to install bird, but it looks like CentOS 7 repo is broken? > > [root@localhost ~]# yum-config-manager --add-repo https://pkg.labs.nic.cz/rpm/bird/centos/7/x86_64/bird.repo > Loaded plugins: elrepo, fastestmirror > adding repo from: https://pkg.labs.nic.cz/rpm/bird/centos/7/x86_64/bird.repo > grabbing file https://pkg.labs.nic.cz/rpm/bird/centos/7/x86_64/bird.repo to /etc/yum.repos.d/bird.repo > repo saved to /etc/yum.repos.d/bird.repo > [root@localhost ~]# yum update > Loaded plugins: elrepo, fastestmirror > Determining fastest mirrors > base | 3.6 kB 00:00:00 > bird | 1.5 kB 00:00:00 > epel | 4.3 kB 00:00:00 > extras | 2.9 kB 00:00:00 > updates | 2.9 kB 00:00:00 > bird/primary | 11 kB 00:00:02 > > > One of the configured repositories failed (Unknown), > and yum doesn't have enough cached data to continue. At this point the only > safe thing yum can do is fail. There are a few ways to work "fix" this: > > 1. Contact the upstream for the repository and get them to fix the problem. > > 2. Reconfigure the baseurl/etc. for the repository, to point to a working > upstream. This is most often useful if you are using a newer > distribution release than is supported by the repository (and the > packages for the previous distribution release still work). > > 3. Run the command with the repository temporarily disabled > yum --disablerepo=<repoid> ... > > 4. Disable the repository permanently, so yum won't use it by default. Yum > will then just ignore the repository until you permanently enable it > again or use --enablerepo for temporary usage: > > yum-config-manager --disable <repoid> > or > subscription-manager repos --disable=<repoid> > > 5. Configure the failing repository to be skipped, if it is unavailable. > Note that yum will try to contact the repo. when it runs most commands, > so will have to try and fail each time (and thus. yum will be be much > slower). If it is a very temporary problem though, this is often a nice > compromise: > > yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true > > Parsing primary.xml error: Start tag expected, '<' not found > > [root@localhost ~]# cat /etc/os-release > NAME="CentOS Linux" > VERSION="7 (Core)" > ID="centos" > ID_LIKE="rhel fedora" > VERSION_ID="7" > PRETTY_NAME="CentOS Linux 7 (Core)" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:centos:centos:7" > HOME_URL="https://www.centos.org/" > BUG_REPORT_URL="https://bugs.centos.org/" > > CENTOS_MANTISBT_PROJECT="CentOS-7" > CENTOS_MANTISBT_PROJECT_VERSION="7" > REDHAT_SUPPORT_PRODUCT="centos" > REDHAT_SUPPORT_PRODUCT_VERSION="7" > > > > > Zhang Xun > -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

Releases on bird.network.cz no longer updated
by Leon Grasmeijer 11 Jun '26

11 Jun '26

Hi there, Are https://bird.network.cz/?download and ftp://bird.network.cz/pub/bird/ no longer being updated? I see there are some versions missing that have been announced and are present on https://bird.nic.cz/get-bird/. Kind regards, Leon

2 1

Crash with `Assertion 'BIT32_TEST(cur->used_bits, idx)' failed at lib/islab.c:678` on 3.3.1
by Matt Corallo 10 Jun '26

10 Jun '26

Sadly I don't have a useful coredump since I was running against a package that I don't have symbols for. Matt

2 1

BIRD 3.3.1, 3.2.2, 3.1.7, 2.19.1, 2.18.2, 2.17.5 released
by Maria Matejka 09 Jun '26

09 Jun '26

Dear BIRD users, we're, as promised, releasing patch versions for all the supported branches. Downloads are possible at <https://bird.nic.cz/get-bird/> and in our upstream repositories. There are some security-relevant fixes this time with a varying degree of relevance. We have fixed a lot of BGP in BIRD 3, most notably several nasty bugs in graceful restart behavior, labelled NLRI parsing and other MPLS stuff. (There are still more MPLS bugs pending in BIRD 3.) We have fixed several flowspec parser flaws in all versions, which were there for years. We have fixed the no-refeed bug of BMP in BIRD 3, and also a cornercase off-by-one in all versions. We have fixed a bunch of corner case OSPF bugs. We have fixed a bunch of race conditions in internal reading the routing tables. We have also fixed the infamous remote code execution bug happening when the path mask feature is used on a gargantuan AS Path (in all versions). There are some outstanding bugs (in all versions) reported, and we've prioritized expediting this release which is already quite beefy, over doing it all at once. If your bug report has been reported as fixed, we would love if you confirmed that from your side. If not, it will most probably get fixed in the next patch release. Officially supported versions are now: - 3.3.x and 2.19.x until 6 months after 3.4.0 and 2.20.0 get released - 3.2.x and 2.18.x until end of November 2026 - LTS 3.1.x and 2.17.x tracking Debian Trixie Also, on commercial note, we offer BIRD Support, so that you can get help with configuration, priority access to critical bug information and fixes, and better influence the overall development directions. It's the users paying for these services, who keep the development running. More on that at our website: <https://bird.nic.cz/commercial-services/> Happy routing! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

bird: Assertion 'birdloop_inside(sl->loop)' failed at lib/event.c:161
by Lexi Winter 09 Jun '26

09 Jun '26

hello, running BIRD 3.2.1 on OpenBSD/arm64 7.9, i changed the router-id in bird.conf, then ran 'birdc reload', and bird crashed: Jun 9 07:02:56 ragweed bird: Reconfiguring Jun 9 07:02:56 ragweed bird: Restarting protocol core4 Jun 9 07:02:56 ragweed bird: Restarting protocol core6 Jun 9 07:02:56 ragweed bird: Assertion 'birdloop_inside(sl->loop)' failed at lib/event.c:161 after restarting bird, it appears to be working fine. unfortunately, the generated core file does not seem to be very useful: (lldb) thread list Process 0 stopped * thread #1: tid = 0, 0x00000011e2b302d4 libc.so.103.0`_thread_sys_setsockopt at -:3, stop reason = signal SIGABRT (lldb) bt * thread #1, stop reason = signal SIGABRT * frame #0: 0x00000011e2b302d4 libc.so.103.0`_thread_sys_setsockopt at -:3 frame #1: 0x0000000d19648050 bird`sk_join_group at sysio.h:101:7 (lldb) i can provide the bird executable and core file privately if that's any use.

2 1

Races in birdc causing daemon to crash on low spec routers
by Yifei Sun 03 Jun '26

03 Jun '26

Hello all, I'm hitting crash in BIRD 3.3.0 on several routers. The machines are running - NixOS x86_64-linux 7.0.10 - 2-5 BGP IPv4/IPv6 peers per affected host - prometheus-bird-exporter 1.4.5, scraping every 30s prometheus-bird-exporter runs `show protocols all` over /run/bird/bird.ctl every ~30s, and on hosts with active BGP churn that crashes bird inside bgp_show_proto_info(). systemd restarts it, the next scrape kills it again, and NRestarts climbs ~120/hr... toompea and timah took 14 and 13 cores in their last ~20 minutes of uptime, highline took 4 over a slower span. The other seven routers (butte, cradle, baldy, kongo, lantau, roraima, rysy) run the same build and exporter with no cores (most likely because these machines are only getting default routes). The crash needs concurrent BGP state changes. For example: ```console $ colmena exec --verbose --on @router -- 'sudo coredumpctl list || true' timah | highline | kongo | toompea | butte | cradle | baldy | rysy | lantau | roraima | rysy | No coredumps found. rysy | Succeeded toompea | TIME PID UID GID SIG COREFILE EXE SIZE toompea | Thu 2026-05-28 15:41:25 UTC 1185401 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 98.9M toompea | Thu 2026-05-28 15:41:53 UTC 1265107 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 100.3M toompea | Thu 2026-05-28 15:42:22 UTC 1265317 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 100.9M toompea | Thu 2026-05-28 15:42:54 UTC 1265529 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 106.1M toompea | Thu 2026-05-28 15:43:23 UTC 1265740 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 101.8M toompea | Thu 2026-05-28 15:43:54 UTC 1265952 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 105.9M toompea | Thu 2026-05-28 15:44:22 UTC 1266165 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 90.2M toompea | Thu 2026-05-28 15:44:53 UTC 1266380 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 100.6M toompea | Thu 2026-05-28 19:45:24 UTC 1266590 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 102.9M toompea | Thu 2026-05-28 19:45:53 UTC 1355754 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 88.6M toompea | Thu 2026-05-28 19:46:22 UTC 1355959 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 87.4M toompea | Thu 2026-05-28 19:46:53 UTC 1356167 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 100.8M toompea | Thu 2026-05-28 19:47:22 UTC 1356371 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 88.8M toompea | Thu 2026-05-28 19:47:54 UTC 1356389 993 991 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 104.8M toompea | Succeeded butte | No coredumps found. butte | Succeeded timah | TIME PID UID GID SIG COREFILE EXE SIZE timah | Thu 2026-05-28 15:36:51 UTC 1268745 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 96.9M timah | Thu 2026-05-28 15:37:17 UTC 1268960 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 98.6M timah | Thu 2026-05-28 15:37:52 UTC 1268974 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 95.9M timah | Thu 2026-05-28 15:38:18 UTC 1269382 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 89.2M timah | Thu 2026-05-28 15:38:53 UTC 1269397 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 95.4M timah | Thu 2026-05-28 19:39:27 UTC 1269828 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 131.6M timah | Thu 2026-05-28 19:39:48 UTC 1359330 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 76.2M timah | Thu 2026-05-28 19:40:20 UTC 1359346 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 99.8M timah | Thu 2026-05-28 19:40:49 UTC 1359574 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 94.1M timah | Thu 2026-05-28 19:41:20 UTC 1359832 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 98.9M timah | Thu 2026-05-28 19:41:51 UTC 1360097 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 93.9M timah | Thu 2026-05-28 19:42:22 UTC 1360320 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 88.9M timah | Thu 2026-05-28 19:42:48 UTC 1360526 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 78.8M timah | Succeeded highline | TIME PID UID GID SIG COREFILE EXE SIZE highline | Thu 2026-05-28 11:34:31 UTC 1203740 999 999 SIGSEGV present /nix/store/afhrc47kar31rwmvbj0qrymm6xcpglvk-bird-3.3.0/bin/bird 99.4M highline | Thu 2026-05-28 11:37:02 UTC 1204447 999 999 SIGSEGV present /nix/store/afhrc47kar31rwmvbj0qrymm6xcpglvk-bird-3.3.0/bin/bird 81.9M highline | Thu 2026-05-28 11:40:00 UTC 1205349 999 999 SIGSEGV present /nix/store/afhrc47kar31rwmvbj0qrymm6xcpglvk-bird-3.3.0/bin/bird 108.9M highline | Thu 2026-05-28 12:15:56 UTC 1220240 999 999 SIGSEGV present /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird 80.3M highline | Succeeded baldy | No coredumps found. baldy | Succeeded kongo | No coredumps found. kongo | Succeeded roraima | No coredumps found. roraima | Succeeded lantau | No coredumps found. lantau | Succeeded cradle | No coredumps found. cradle | Succeeded | All done! ``` ```console $ sudo coredumpctl info PID: 1356389 (bird) UID: 993 (bird) GID: 991 (bird) Signal: 11 (SEGV) Timestamp: Thu 2026-05-28 19:47:42 UTC (1h 37min ago) Command Line: /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird -c /etc/bird/bird.conf Executable: /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird Control Group: /system.slice/bird.service Unit: bird.service Slice: system.slice Boot ID: fd4c001e44dc44e1a05cbc5d60440ecb Machine ID: 77293224076f4ff7845c2358cb35a4c0 Hostname: toompea Storage: /var/lib/systemd/coredump/core.bird.993.fd4c001e44dc44e1a05cbc5d60440ecb.1356389.1779997662000000.zst (present) Size on Disk: 104.8M Message: Process 1356389 (bird) of user 993 dumped core. Module /nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird without build-id. Module libz.so.1 without build-id. Module libssh.so.4 without build-id. Stack trace of thread 1356389: #0 0x000059d538758d08 bgp_show_proto_info.lto_priv.0 (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0xdcd08) #1 0x000059d538706fb2 proto_cmd_show (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x8afb2) #2 0x000059d5387077c1 proto_apply_cmd.isra.0 (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x8b7c1) #3 0x000059d5386a2de8 cf_parse.isra.0 (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x26de8) #4 0x000059d5386ac462 cli_parse (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x30462) #5 0x000059d5386f96e5 cli_command (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x7d6e5) #6 0x000059d5386f9980 cli_event.lto_priv.0 (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x7d980) #7 0x000059d5386dff35 ev_run_list_limited (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x63f35) #8 0x000059d538693c8c main (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x17c8c) #9 0x00007ae37602b285 __libc_start_call_main (libc.so.6 + 0x2b285) #10 0x00007ae37602b338 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2b338) #11 0x000059d538694885 _start (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x18885) Stack trace of thread 1356391: #0 0x00007ae3760a6922 __syscall_cancel_arch (libc.so.6 + 0xa6922) #1 0x00007ae37609a00c __internal_syscall_cancel (libc.so.6 + 0x9a00c) #2 0x00007ae37609a084 __syscall_cancel (libc.so.6 + 0x9a084) #3 0x00007ae37611778e __poll (libc.so.6 + 0x11778e) #4 0x000059d5387b3bfe bird_thread_main.lto_priv.0 (/nix/store/230z9nyndgbn265mqlbyvf20z5wdciwy-bird-3.3.0/bin/bird + 0x137bfe) #5 0x00007ae37609dd53 start_thread (libc.so.6 + 0x9dd53) #6 0x00007ae37612563c __clone3 (libc.so.6 + 0x12563c) ELF object binary architecture: AMD x86-64 ``` I temporarily worked around this by removing the prefix count showed when invoking `birdc show proto all`. But I’m not sure if this type of patches are acceptable for upstreaming (please see reasoning in the commit message in the patch): https://raw.githubusercontent.com/stepbrobd/inc/refs/heads/master/pkgs/bird… Best, Yifei

1 3

Fw: [oss-security] BIRD/BIRD2: stack buffer overflow in BGP AS_PATH mask matching, CVE pending
by Bruce Duncan 03 Jun '26

03 Jun '26

Hi, Long time lurker, first time poster. FYI, since I didn't see anything about this, I thought operators might want to be aware that a "vulnerability" has been disclosed on the oss-security list today, and this might cause managers/auditors to ask you probing questions. Hope that's helpful to someone. Bruce The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

2 1

Suppressing "Malformed AS_PATH attribute" and "Invalid route ... withdrawn"?
by Robert Scheck 02 Jun '26

02 Jun '26

Hello all, after updating a system to BIRD 3.x, I see lots of such log messages: Jun 02 11:52:34 bird[2664336]: transit6: Malformed AS_PATH attribute - AS_SET segment (1) at 26 Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7453::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7426::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7444::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7435::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7425::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:14a:7523::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Malformed AS_PATH attribute - AS_SET segment (1) at 14 As I personally less care about the invalid routes the US DoD (and others) push into the DFZ, I would like to suppress them (~ 26k log lines within 8 hours) - while still keeping regular BIRD warnings, errors etc. Maybe I'm overlooking something, but based on the documentation I did not see how I could suppress just "Malformed AS_PATH attribute" and "Invalid route ... withdrawn" log messages? Any pointers? Thank you. Regards, Robert

2 1

misleading documentation for the "direct" protocol
by Lexi Winter 02 Jun '26

02 Jun '26

hello, the BIRD documentation says for the "direct" protocol[0]: > The question is whether it is a good idea to have such device routes > in BIRD routing table. OS kernel usually handles device routes for > directly connected networks by itself so we don't need (and don't > want) to export these routes to the kernel protocol. OSPF protocol > creates device routes for its interfaces itself and BGP protocol is > usually used for exporting aggregate routes. But the Direct protocol > is necessary for distance-vector protocols like RIP or Babel to > announce local networks. [0] https://bird.network.cz/?get_doc&v=30&f=bird-6.html#ss6.7 as i read this, it is suggesting that if BIRD is only running OSPF, then the "direct" protocol is not needed. however, i've tested this and i'm not sure it's true. without direct, and with a basic OSPF configuration with no peers, BIRD will flag the OSPF interface routes with '!': root@witch:/usr/local/etc # birdc show route BIRD 3.2.0 ready. Table master4: 81.2.96.160/28 unicast [core4 22:45:00.630] ! I (150/10) [198.18.2.4] dev genet0 Table master6: 2001:8b0:aab5:c401::/64 unicast [core6 22:45:00.630] ! I (150/10) [198.18.2.4] dev genet0 it will also log very much some netlink errors: May 31 22:51:04 witch bird[31390]: Netlink: File exists May 31 22:51:04 witch syslogd: last message repeated 1 times May 31 22:52:04 witch bird[31390]: Netlink: Address already in use May 31 22:52:04 witch bird[31390]: Netlink: File exists May 31 22:52:04 witch syslogd: last message repeated 1 times after configuring BIRD with: protocol direct { ipv4; ipv6; }; the OSPF interface routes are correctly installed (or rather, not installed, since the kernel already installed them): root@witch:/usr/local/etc # birdc show route BIRD 3.2.0 ready. Table master4: 81.2.96.160/28 unicast [direct1 22:53:29.436] * (240) dev genet0 unicast [core4 22:53:29.529] I (150/10) [198.18.2.4] dev genet0 Table master6: 2001:8b0:aab5:c401::/64 unicast [direct1 22:53:29.436] * (240) dev genet0 unicast [core6 22:53:29.529] I (150/10) [198.18.2.4] dev genet0 and BIRD does not log anymore the netlink-related errors. i tested this on FreeBSD 15.0, so possibly this is a FreeBSD-specific behaviour that isn't present on Linux; i don't have any Linux systems to test with. but, i think the documentation of the "direct" protocol could be changed to indicate that configuring it may be necessary in at least some situations.

2 2

bird_exporter: Inconsistent state label for BIRD 2 BGP protocol with multiple AF channels
by Mikhail Mayorov 01 Jun '26

01 Jun '26

Hello. This is not directly related to BIRD itself. BIRD appears to work correctly in this case. The question is about how |bird_exporter|exposes metrics for a BIRD 2 BGP protocol with multiple address-family channels. I am using |bird_exporter| with BIRD 2 and noticed confusing behavior when a single BGP protocol has more than one address-family channel enabled, for example both |ipv4| and |ipv6|. Versions: |bird_exporter: 1.5.0 BIRD: 2.19.0 | Exporter is started like this: |bird_exporter \ -web.listen-address=localhost:9325 \ -bird.v2 \ -bird.socket=/path/to/bird.ctl | BIRD shows one established BGP session with both IPv4 and IPv6 channels up: |Name Proto State Info example_peer BGP up Established BGP state: Established Neighbor address: 2001:db8::1 Source address: 2001:db8::2 Local capabilities: Multiprotocol AF announced: ipv4 ipv6 Neighbor capabilities: Multiprotocol AF announced: ipv4 ipv6 Channel ipv4 State: UP Table: master4 Routes: 10 imported, 0 filtered, 6000 exported, 10 preferred Channel ipv6 State: UP Table: master6 Routes: 0 imported, 0 filtered, 200 exported, 0 preferred | Actual |bird_exporter| output: |bird_protocol_up{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP",state="Established"} 1 bird_protocol_up{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP",state=""} 1 bird_protocol_uptime{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP"} 397 bird_protocol_uptime{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP"} 397 bird_protocol_prefix_export_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP"} 6000 bird_protocol_prefix_export_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP"} 200 bird_protocol_prefix_import_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP"} 10 bird_protocol_prefix_import_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP"} 0 bird_protocol_prefix_preferred_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP"} 10 bird_protocol_prefix_preferred_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP"} 0 | The important part is that both |ip_version="4"| and |ip_version="6"| are exported for the same BGP protocol, but only one series has the BGP FSM state: |bird_protocol_up{ip_version="4",name="example_peer",proto="BGP",state="Established"} 1 bird_protocol_up{ip_version="6",name="example_peer",proto="BGP",state=""} 1 | The IPv6 series has |state=""|, although the BGP protocol is established and the IPv6 channel is UP. Expected behavior: Either |state="Established"| should be present on all |bird_protocol_up| series generated from the same established BGP protocol: |bird_protocol_up{ip_version="4",name="example_peer",proto="BGP",state="Established"} 1 bird_protocol_up{ip_version="6",name="example_peer",proto="BGP",state="Established"} 1 | or |state| should not be attached to per-AF |bird_protocol_up| series at all, and a separate protocol-level metric should expose the BGP FSM state. The current behavior is confusing for monitoring systems, because the same BGP protocol appears as partly established and partly without state, although both address-family channels are UP. It would also be useful to distinguish clearly between: * protocol/session state, for example |BGP state: Established|; * channel state, for example |Channel ipv4: UP|, |Channel ipv6: UP|; * address-family label, currently exposed as |ip_version|. A cleaner model could be something like: |bird_protocol_up{name="example_peer",proto="BGP",state="Established"} 1 bird_protocol_channel_up{name="example_peer",proto="BGP",channel="ipv4"} 1 bird_protocol_channel_up{name="example_peer",proto="BGP",channel="ipv6"} 1 | This would avoid ambiguity when one BIRD 2 protocol serves multiple address families. Thank you.

1 0