- Bird-users - Mailing Lists

Setting BGP Aggregator Attribute in Filters
by Pavel Trefný 15 Apr '26

15 Apr '26

Hi, I have a question regarding BIRD. Is it possible to set the BGP aggregator attribute for a prefix using filters? This would be useful in our anycast setup, where it can be difficult to determine the origin of a prefix. Using communities is unfortunately not a viable option for us — some of our hardware does not support extended communities, and upstream networks often filter them. To clarify, I am not looking for route aggregation itself, but specifically a way to set the aggregator attribute. Thank you for any insights. Best regards, Pavel Trefny

2 2

IPv4 transit not routed into Wireguard tunnel (IPv6 works)
by VS 12 Apr '26

12 Apr '26

Good afternoon, need to state I am no routing expert, so bear with me if this is a dumb fault on my side. I am running bird 2.17.1 on Trixie (myASN), announcing a IPv6/48 and a IPv4/24 to upstream ASN via myASN. MyASN is running on a VPS which has a Wireguard tunnel to me here. On this side is a Pfsense with FRR announcing my 1.2.3.0/25 on vtnet6 (128 IPs should be here) through the Wireguard Tunnel to myASN. On myASN the the IPv6 Traffic works fine. Coming in from Upstream and is routed into the tunnel and traffic coming through the tunnel is routed out to the internet. In the case of IPv4 with stopped bird, I can ping e.g. 1.2.3.10 through the tunnel, which is setup using 172.16.150.8/30 using .9 and .10 on the tunnel ends. I also can ping the internet using the default gateway and the eth0 IP. When I start bird the IPv4/24 is announced to upstream and traffic comes in via eth0. Also if the 1.2.3.10 host behind the Pfsense pings e.g. 8.8.8.8, the traffic comes up to myASN through the tunnel. But the the package is lost, not routed out to the Internet, nor is incoming traffic routed into the tunnel. I already set multihop 3 on IBGP definition because 1.2.3.0/25 is not directly connected to myASN and traffic needs to use the route into the tunnel. birdc show routes and other commands show the route are there and also ip route get shows the routes are in the kernel table master4 after bird starts. No firewall active so nothing blocks any traffic on this level. I am sure I am blind, but sitting since days searching for a solution. An link to a cool tutorial for a kinda transit traffic setup (I checked lots of them) or any hint for a possible problem in my setup would be greatly appreciated. Thank you very much!

2 1

sorted route advertisements from bird bgp session.
by gautham devalapalli 08 Apr '26

08 Apr '26

Hello, When advertising the routes from BGP to an nxos switch, we are noticing the routes come in random order instead of sequential order. I tried using `sorted` option but doesnt seem to work. Using bird 2.0.8 version. Is there a way to force an order of routes like how Ixia traffic generator does this. ipv4 table ebgp1 sorted;; protocol bgp ebgp_1_node01 { local 10.0.0.2 as 65000; neighbor 10.0.0.1 as 100; ipv4 { table ebgp1; import none; export where source = RTS_STATIC; }; } protocol static v4static{ ipv4 { table ebgp1; }; route 50.0.1.1/32 via 10.0.0.2; route 50.0.1.2/32 via 10.0.0.2; route 50.0.1.3/32 via 10.0.0.2; route 50.0.1.4/32 via 10.0.0.2; route 50.0.1.5/32 via 10.0.0.2; route 50.0.1.6/32 via 10.0.0.2; } E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.1/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.5/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.2/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.6/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.3/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.4/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 Sincerely Gautham

2 3

Extracting octets/quads from IP addresses in filter expressions
by Stefan Pisjak 08 Apr '26

08 Apr '26

Hi fellow bird users! I've searched through the documentation/this mailing list, but I haven't found anyone trying to build a similar filter so far. I'm trying to build a filter to only allow BGP routes if the "host part" of `ip from` matches the route that is being announced, e.g.: 10.0.1.2 is allowed to announce 10.100.1.2/32 10.0.1.3 is allowed to announce 10.100.1.3/32 [...] 10.0.X.Y is allowed to announce 10.100.X.Y/32 But as far as I can tell, it's not possible to somehow convert the type ip to type quad or something like that. Is there a better way to build this filter, or can you somehow create a new variable of the type ip and modify it or convert the ip to a quad and then do the manipulations? Kind regards, Stefan DISCLAIMER: This communication may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message by mistake, please advise the sender by reply email and delete the message. Thank you.

2 1

BMP in 2.18.1
by Srdjan Markovic 07 Apr '26

07 Apr '26

Hi! Bird2 fails to start after upgrade to 2.18.1 with the following error message: /etc/bird/bird.conf.d/bird-pmacctd.conf:1:10 syntax error, unexpected CF_SYM_UNDEFINED Content of the file is: protocol bmp pmacctd { station address ip 127.0.0.1 port 17917; monitoring rib in pre_policy; monitoring rib in post_policy; tx buffer limit 64; } Downgrading back to 2.18 (apt-get install bird2=2.18-cznic.1~trixie), without touching the config, lets bird2 start again. I can't find the build log in Gitlab to check if the configure option was omitted, nor anything in the NEWS file. Kind regards, Srdjan

3 2

Reconfiguring MPLS channel while down causes segfault on bird 3.2.0
by Max Hearnden 07 Apr '26

07 Apr '26

Hello, I've found an issue with bird 3.2.0 which can be reproduced with the following configuration (no peer required). Just run configure after starting bird. router id 1; mpls table mtab; mpls domain mdom; protocol bgp test { local 192.0.2.2 port 8179 as 65000; neighbor 192.0.2.1 as 65001; mpls {label policy aggregate;}; } It appears that this issue is caused because c->mpls_map is only set in mpls_channel_start instead of mpls_channel_init which would also match the deallocation in mpls_channel_cleanup. This means that before the channel is first up c->mpls_map is null and would cause a null pointer dereference as part of mpls_fec_map_reconfigure (called in mpls_channel_reconfigure).

2 2

BGP reload routes issue
by Derco Sportel 02 Apr '26

02 Apr '26

Hello, We've been relying on bird heavily in our DC and basically all of our servers use bird. All server advertise /32 addresses using BGP toward the network and we use BFD for fast-fail. Lately we have observed some issues with bird reloads where some neighbors report reload failed. After investigation it looks as if the reload fails if the following conditions have been met: 1. BGP sessions were established 2. BGP flapped for $reason (router reload, BFD flap, other) After this, even though the BGP sessions are there, the Route refresh capability is no longer possible. A restart of bird solves the problem. After investigation we suspect this is caused by the combination of these parts of the code: https://github.com/CZ-NIC/bird/blob/9d509f232eaf04f707f51fd2368841d899ab8af… and https://github.com/CZ-NIC/bird/blob/9d509f232eaf04f707f51fd2368841d899ab8af… Our current install is version 3.2.0, though we have also observed route refresh issues with prior 3.x versions. The bgp_init creates the object with reload routes, but a bgp_stop makes it NULL. A bgp_start just starts the BGP session, but as the reload_routes is NULL we loose the Route refresh capability. We might be completely off track here, and this might very well be intended behavior, though we do suspect this to be wrong. Can someone have a look at this and tell us if this is a bug or a feature? Regards, Derco Sportel | System Engineer Networking | https://bol.com<https://bol.com/>

2 1

Subject: Bird3 - Establishing a BGP session over IPv6 LL addresses
by Lucas da Vila 31 Mar '26

31 Mar '26

Hi! I'm a member of the DN42 network, and I have a mikrotik router connected to it, I've only have 1 peer and I'm receiving over MP-BGP IPv4 and IPv6 prefixes. Also on the mikrotik I'm running a route-reflector. With my bird3 (3.2.0 from debian repo) instance I'm trying to connect to the route reflector over a couple of IPv6 LL addresses. But it doesn't seem to be working. This is my bird3 config: ``` router id 192.168.1.200; log "/var/log/bird/bird.log" all; protocol bgp mkt01_dn42_rr { description "mkt01 dn42 RR"; # local 192.168.1.200 as 64512; local fe80::42e2:30ff:fe60:edbb%wlp2s0 as 64512; # neighbor 192.168.1.201 as 64512; neighbor fe80::2805%wlp2s0 as 64512; interface "wlp2s0"; direct; strict bind yes; ipv4 { import all; }; ipv6 { import all; }; } protocol bmp { station address ip 127.0.0.1 port 5000; monitoring rib in pre_policy; monitoring rib in post_policy; } ``` After trying adding and removing params liks strict bind, interface, etc I was not able to land a configuration that finally worked. I must say that over IPv4 the session was established, but over IPv6 stills in Idle. Is anyone out there with a similar config? Any ideas why this happens? Regards, Lucas

3 8

Bird 3.2.0 crashing with "Assertion 'DG_IS_LOCKED(orig->domain)' failed at lib/resource.c:208"
by Buchberger, Carsten (WiTCOM) 27 Mar '26

27 Mar '26

Hi, after upgrading from Bird 3.1.4 to 3.2.0 (EPEL RPM package) bird is crashing shortly after starting it with the following error Assertion 'DG_IS_LOCKED(orig->domain)' failed at lib/resource.c:208 The issue was reported back in january on this list (https://bird.network.cz/pipermail/bird-users/2026-January/018551.html) but there was no real follow-up. We confirm the behaviour - bird crashes shortly after processing the first BGP requests and generates he following core-dump Stack trace of thread 6573: #0 0x00007f191f08d02c __pthread_kill_implementation (libc.so.6 + 0x8d02c) #1 0x00007f191f03fb86 raise (libc.so.6 + 0x3fb86) #2 0x00007f191f029873 abort (libc.so.6 + 0x29873) #3 0x0000559400a21d5f bug (bird + 0xe9d5f) #4 0x0000559400978bd7 rmove (bird + 0x40bd7) #5 0x00005594009d3809 bgp_start.lto_priv.0 (bird + 0x9b809) #6 0x000055940098b48e proto_rethink_goal.lto_priv.0 (bird + 0x5348e) #7 0x000055940097611e defer_execute (bird + 0x3e11e) #8 0x0000559400972323 ev_run_list_limited (bird + 0x3a323) #9 0x0000559400950556 main (bird + 0x18556) #10 0x00007f191f02a610 __libc_start_call_main (libc.so.6 + 0x2a610) #11 0x00007f191f02a6c0 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a6c0) #12 0x0000559400950c75 _start (bird + 0x18c75) Stack trace of thread 6574: #0 0x00007f191f088540 __GI___lll_lock_wait (libc.so.6 + 0x88540) #1 0x00007f191f08e6d2 __pthread_mutex_lock@GLIBC_2.2.5<mailto:__pthread_mutex_lock@GLIBC_2.2.5> (libc.so.6 + 0x8e6d2) #2 0x0000559400a22a92 do_lock (bird + 0xeaa92) #3 0x0000559400a1c0e0 bird_thread_main (bird + 0xe40e0) #4 0x00007f191f08b2ea start_thread (libc.so.6 + 0x8b2ea) #5 0x00007f191f1103d0 __clone3 (libc.so.6 + 0x1103d0) Stack trace of thread 6575: #0 0x00007f191f1030cf __poll (libc.so.6 + 0x1030cf) #1 0x0000559400a1c436 bird_thread_main (bird + 0xe4436) #2 0x00007f191f08b2ea start_thread (libc.so.6 + 0x8b2ea) #3 0x00007f191f1103d0 __clone3 (libc.so.6 + 0x1103d0) ELF object binary architecture: AMD x86-64 We reverted to Bird 3.1.5 - no issues here. The issue occurs with the following configuration (slightly anonymized) Bird.conf # Configure logging log syslog all; # Include constants include "/etc/bird/constants.conf"; router id rs_ipv4; protocol bfd BFD_DCFABRIC { multihop { interval 300 ms; multiplier 3; }; } protocol direct { disabled; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table } protocol kernel { ipv4 { }; } protocol kernel { ipv6 { }; } protocol static { disabled; ipv4; # Again, IPv4 channel with default options } include "/etc/bird/rs-peerings.conf"; constants.conf define rs_ipv4 = x.y.y.z; rs-peerings.conf # FILTER filter only_serviceips { if net ~ [ 192.168.20.0/24{32,32} ] then accept; if net ~ [ 10.127.64.0/19{32,32} ] then accept; reject; } # HOSTS template bgp SERVICENODE { local as 4200010004; ipv4 { import filter only_serviceips; export none; }; rs client; hold time 6; multihop 10; bfd on; source address rs_ipv4; } protocol bgp rack_XYZ from SERVICENODE { neighbor range 192.168.y.y/26 as 4200010003; dynamic name "rack_XYZ_"; } template bgp DCFABRIC { ipv4 { import none; export all; add paths tx; }; local as 4200010004; rs client; multihop 10; bfd on; source address rs_ipv4; } # DC-Fabric nodes protocol bgp R_DCI_01 from DCFABRIC { neighbor x.x.x.x as 4200001201; }

2 1

Bird and keepalived.
by Mike Neo 26 Mar '26

26 Mar '26

Hi all, I’m looking for best practices and design recommendations for using Keepalived (VRRP) in a setup with two BIRD-based routers running iBGP between each other. Setup overview - Two routers (R1 and R2), both running BIRD based on debian repo - Direct interconnection via eno1 (1GE Base-T) used for iBGP session - Each router has its own uplink and independent eBGP session - There is a single IX service currently connected to R1 - Goal: ensure failover to R2 (via Keepalived/VRRP) if R1 goes down Questions 1. VRRP traffic design What is the recommended approach for VRRP packets in this kind of setup? - Should VRRP run over a dedicated VLAN on the inter-router link (eno1)? - Or is it better to run VRRP on the same interface where the VIP is configured (e.g., gateway interface for downstream hosts), possibly using a separate VLAN there? I’m trying to understand what is considered cleaner and more robust in production environments. 2. Track scripts – best practices What are the best practices when using track_script in Keepalived? - What should be monitored in a BGP/BIRD context? - BGP session state? - Reachability (e.g., upstream via ping)? - Interface/link state? - IX availability? - How do you typically avoid false positives / flapping? - Any recommended patterns for integrating BIRD state with Keepalived? 3. Failover strategy for IX service Given that: - Only R1 is physically connected to the IX - Both routers participate in BGP and exchange routes via iBGP What is the recommended way to ensure that: • Traffic and VIP failover cleanly to R2 • And ideally, the IX connectivity (logically) follows to R2 during failure? Is this typically handled purely via VRRP + routing changes, or are there additional mechanisms commonly used? Any real-world examples, configuration snippets, or design insights would be greatly appreciated. Thanks! Mike

4 3