June 2026 - Bird-users - Mailing Lists

[PATCH] BGP: Fix bucket assert when encoding BMP route monitoring messages
by Yifei Sun 07 Oct '26

07 Oct '26

Good afternoon, the 2 issues I reported last week (e038bf6 and 371531d) was resolved on my side in 3.3.1. Thank you! Today in CI, I'm seeing some assertion throws that affects both 3.3.0 and 3.3.1 with BMP (traces also in the linked CI log): - https://github.com/stepbrobd/rfm/actions/runs/27352866052/job/80819677363#s… - https://github.com/stepbrobd/rfm/actions/runs/27347885470/job/80814124422#s… Relevant config: - https://github.com/stepbrobd/rfm/blob/187c61620b3af6ec77e1cc730c6b6b37d174d… I applied the same patch on 3.3.1 locally to unblock CI, and the current patch is based on thread-next bgp_create_update_bmp() encodes routes for BMP using a temporary bucket allocated on stack. Such buckets are not allocated from the bucket slab and have no ID assigned, so the assert at the beginning of bgp_delete_from_bucket() fails as soon as the NLRI encoder pops the prefix, aborting the daemon on the first route monitoring message that carries a real prefix. On BIRD 3.3.1: > Assertion 'b->my_id' failed at proto/bgp/attrs.c:2020 Temporary BMP buckets always hold exactly one prefix and take the single-prefix path, which does not use the bucket ID at all, so allow them through the assert. Introduced in 9fa3e89476ed53b6a9d41931a8cdf9a8c675be27 "BGP: Compacting export prefix buckets" --- proto/bgp/attrs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index 6c38d4955..ee893d2c1 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -2063,7 +2063,7 @@ bgp_delete_from_bucket(struct bgp_ptx_private *c, struct bgp_bucket *b, u32 id) bgp_bucket_consistency(b); #endif - ASSERT_DIE(b->my_id); + ASSERT_DIE(b->my_id || b->bmp); u32 row_num = BUCKET_PREFIX_ROW(id); u32 pos = BUCKET_PREFIX_POS(id); ASSERT_DIE(b->last_pref_id); -- 2.54.0

3 5

BMP: no monitoring messages when enabled after BGP sessions (BIRD 3.2.1)
by Thomas Holterbach 01 Oct '26

01 Oct '26

Dear BIRD community, I am running a BMP collector and encountering an issue where no monitoring messages are exported over BMP, even though I am using the latest BIRD version (3.2.1), which should include the fix for the previous route export bug: https://gitlab.nic.cz/labs/bird/-/commit/2500b450b404ab41eeff3b2d92ba943d01… We tested this both in our lab and with a network operator, and consistently observe the following behavior: If the BMP session is activated before the BGP sessions, everything works as expected, and monitoring messages are exported. If the BGP sessions are established before enabling BMP, then BMP does not export monitoring messages at all. This suggests that BMP does not correctly pick up already-established BGP sessions. Below is a minimal configuration example. The behavior depends solely on the order in which the sessions are established : debug protocols all; router id 192.168.222.54; protocol kernel { ipv4 { export all; }; } protocol device { scan time 10; } filter ALLOW_ALL { accept; } protocol bmp { station address ip 192.168.222.1 port 4567; monitoring rib in pre_policy; tx buffer limit 1024; } protocol bgp peer_asn_10 { local 192.168.222.54 as 11; neighbor 192.168.222.52 as 10; multihop 255; ipv4 { import all; export all; next hop self; import table on; }; ipv6 { import all; export all; next hop self; import table on; }; } protocol bgp peer_asn_12 { local 192.168.222.54 as 11; neighbor 192.168.222.53 as 12; multihop 255; ipv4 { import all; export all; next hop self; }; ipv6 { import all; export all; next hop self; }; } Has anyone else experienced similar behavior? Could this be another bug related to BMP? Thanks in advance for your help. Best regards, Thomas

3 6

BIRD 3.3.0 Issue with bgp listen in VRF
by Arnaud Houdelette-Langlois 17 Sep '26

17 Sep '26

Hello. I’m currently trying to setup an EVPN SDN with proxmox (FRR) and bird for route reflectors and gateways. My RR BGP conf is like : template bgp vtep { vrf "vrf-underlay"; local as 65000; source address router_id; rr client; #rr cluster id 172.16.2.20; evpn { table evpnrr; igp table underlay; import all; export all; }; } protocol bgp uproxrtr1 from vtep { neighbor 172.16.2.21 internal; } This is working as long as bird is establishing the connexion. But the listening socket is opened in the default VRF. The issue disapear with bird 2.19.0, so I’ll stick with it for now. -- Arnaud HOUDELETTE-LANGLOIS Administrateur systèmes et réseaux informatiques Responsable de la sécurité des systèmes d'information Normandie-Université +33 2 31 56 69 54

2 2

Filtes "Destination address required" spam on wireguard links?
by Florian Klink 30 Jun '26

30 Jun '26

Hey, I spotted one of my bird installations being quite spammy with: > babel1: Socket error on <iface>: Destination address required Digging through the archives, I found this has previously already been reported in BFD contexts, in every occasion, wireguard being mentioned too: - 902d7906-00d5-44d0-af5a-f05a35d59195(a)mailbox.org - 87sevc6518.fsf(a)ungleich.ch - 877ccr6zio.fsf(a)ungleich.ch Now with me seeing this for babel, I took a closer look. It seems to be a generic behaviour with how wireguard links behave: If the peer the packet should be sent to is offline (or has not yet completed the handshake), the kernel sends a 'Destination address required' error: ``` root@flint2:~# ping fe80::5%wg_rock PING fe80::5%wg_rock (fe80::5%13): 56 data bytes ping: sendto: Destination address required ``` ``` root@flint2:~# wg show wg_rock interface: wg_rock public key: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY= private key: (hidden) listening port: 8447 peer: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= preshared key: (hidden) allowed ips: 0.0.0.0/0, ::/0 ``` This probably should get filtered out by babel if the interface is of wireguard type? Or in the babel case, such a message be considered as another signal that the link is down, similar to `check link yes;`? Thanks, Florian

2 2

Example configuration for ASPA with rpki-client?
by Robert Scheck 26 Jun '26

26 Jun '26

Hello, does somebody have an example configuration snippet for ASPA in BIRD with rpki-client? I've read https://bird.network.cz/?get_doc&v=20&f=bird-6.html but I'm still not sure how the configuration in BIRD for an AS with two transit providers (just upstreams, no downstreams) would look like... Regards, Robert

6 11

BFD control plane independency with bird2
by Jonas Reineke 23 Jun '26

23 Jun '26

Hi bird-users, as I couldn't find any documentation on this I would kindly ask if bird supports control plane independency (c bit) for bfd and, if the current answer is no, if there are ways and/or plans to implement it in the future. We are facing issues with bfd sessions not shutting down and therefore bgp routes not getting withdrawn. The only clue we currently have is that our bird routers are not sending the c bit, so we are kinda poking around in the dark with this one. Current bird2 version used: 2.17.1-1+deb13u2 Current Linux kernel used: 6.12.90+deb13.1-amd64 (Debian Trixie) Best regards Jonas Reineke

1 0

[PATCH 3.3] Proto: Allow channel start() to refuse DOWN->START
by me＠maiyun.me 18 Jun '26

18 Jun '26

From: Zhang Maiyun <me(a)maiyun.me> Signed-off-by: Zhang Maiyun <me(a)maiyun.me> --- nest/proto.c | 27 ++++++++++++++++++++------- proto/bgp/bgp.c | 2 +- 2 files changed, 21 insertions(+), 8 deletions(-) diff --git a/nest/proto.c b/nest/proto.c index 4472fe6f..2edbe142 100644 --- a/nest/proto.c +++ b/nest/proto.c @@ -1086,7 +1086,7 @@ channel_setup_in_table(struct channel *c) } -static void +static int channel_do_start(struct channel *c) { c->proto->active_channels++; @@ -1094,9 +1094,12 @@ channel_do_start(struct channel *c) if ((c->in_keep & RIK_PREFILTER) == RIK_PREFILTER) channel_setup_in_table(c); - CALL(c->class->start, c); + if (c->class->start) + if (c->class->start(c) != 0) + return -1; channel_start_import(c); + return 0; } static void @@ -1176,7 +1179,11 @@ channel_set_state(struct channel *c, uint state) ASSERT(cs == CS_DOWN || cs == CS_PAUSE); if (cs == CS_DOWN) - channel_do_start(c); + if (channel_do_start(c) != 0) { + // Reject the channel start and return to down state + c->channel_state = CS_DOWN; + c->last_state_change = current_time(); + } break; @@ -1184,12 +1191,18 @@ channel_set_state(struct channel *c, uint state) ASSERT(cs == CS_DOWN || cs == CS_START || cs == CS_PAUSE); if (cs == CS_DOWN) - channel_do_start(c); + if (channel_do_start(c) != 0) { + // Reject the channel start and return to down state + c->channel_state = CS_DOWN; + c->last_state_change = current_time(); + } - if (!c->gr_wait && c->proto->rt_notify) - channel_start_export(c); + if (c->channel_state != CS_DOWN) { + if (!c->gr_wait && c->proto->rt_notify) + channel_start_export(c); - channel_do_up(c); + channel_do_up(c); + } break; case CS_PAUSE: diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c index 8d04a05d..1923a80d 100644 --- a/proto/bgp/bgp.c +++ b/proto/bgp/bgp.c @@ -3257,7 +3257,7 @@ bgp_channel_start(struct channel *C) if (ipa_zero(c->next_hop_addr)) { log(L_WARN "%s: Missing next hop address", p->p.name); - return 0; + return -1; } /* Set link-local address for IPv6 single-hop BGP */ -- 2.54.0

3 3

Setting BGP metric based on OSPF cost to peer
by Lukas Haase 18 Jun '26

18 Jun '26

Hello, I have a network with 2 bird routers and one Mikrotik RouterOS router; internal routing via OSPF. The bird boxes announce a /24 prefix via eBGP and then there are 3 iBGP sessions: bird1<-->bird2, bird1<-->mikrotik and bird2<-->mikrotik. For now, both bird1 and bird2 send Mikrotik a default route (imported via eBGP; might be full table later on). Mikrotik should then make the default route active whose gateway has the shortest path via OSPF metric. To my understanding, this is "best practice" and the right way to do it: OSPF defines the best route within my network and on top, iBGP defines the best route to the internet (via the internal network). If my understanding is correct, when Mikrotik receives the two default routes and all BGP metrics are identical it should eventually resort to the underlying IGP metric (i.e., lowest OSPF cost to the gateway of the default route) as a tie breaker. (Please correct me if this is not the common case). Turns out Mikrotik is totally broken here and ignores IGP metric (OSPF cost) completely, resulting in sub-optimal installation of the default route. I could overwrite this STATICALLY (e.g. by setting bgp-igp-metric in a route filter) but the point is that the optimal path is defined DYNAMICALLY via the underlying IGP (OSPF). Super frustrating. Now my idea is if I could turn this around and let the birds prioritize the routing: Is it possible to attach a BGP metric on export that equals the OSPF cost of the BGP peer (i.e., Mikrotik)? How would I do this and is it a good idea? And if so, can it be done such that an update is sent anytime the underlying OSPF cost changes? Thanks, Luke

1 0

BIRD 3.3.0 crashes on "birdc show route for 209.24.0.0/24"
by Robert Scheck 16 Jun '26

16 Jun '26

Hello all, unfortunately, BIRD 3.3.0 as shipped by EPEL 9 crashes at the following: $ birdc show route for 209.24.0.0/24 BIRD 3.3.0 ready. Connection closed by server $ Jun 9 18:34:47 kernel: bird[17874]: segfault at 0 ip 0000562a987ed574 sp 00007ffed8687a30 error 4 in bird[562a987a1000+11d000] likely on CPU 18 (core 2, socket 0) Jun 9 18:34:52 systemd-coredump[17976]: Process 17874 (bird) of user 990 dumped core.#012#012Stack trace of thread 17874:#012#0 0x0000562a987ed574 rt_show_net (/usr/sbin/bird + 0x61574)#012#012Stack trace of thread 17876:#012#0 0x00007f18d1f032cf n/a (n/a + 0x0) #012ELF object binary architecture: AMD x86-64 Jun 9 18:34:52 systemd[1]: bird.service: Main process exited, code=dumped, status=11/SEGV The correct answer of above command should be "Network not found", which it is on at least BIRD 2.16. Btw, "birdc show route 209.24.0.0/24 filtered" crashes the same way on BIRD 3.3.0. The correct answer would also be "Network not found". But as "birdc show route for 1.1.1.1" and "birdc show route for 1.1.1.0/24" both work fine, this only seems to affect non-existing routes? Do you need anything else for debugging? Regards, Robert

4 3

Re: Releases on bird.network.cz no longer updated
by Leon Grasmeijer 15 Jun '26

15 Jun '26

On 13/06/2026 13:48, Ondrej Filip wrote: > On 11/06/2026 09:33, Leon Grasmeijer wrote: >> 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/. > > Hi! > Yes, we are migrating everything to bird.nic.cz. Do you still see a > need for FTP? Hi Ondrej, thank you for your response. I'll make sure that we'll pull from bird.nic.cz from now then. I don't see a need to keep using FTP. > > Ondrej > > >> >> Kind regards, >> Leon >

1 0