December 2025 - Bird-users

[PATCH 0/4] BGP unnumbered automatic peering based on IPv6 ND
by Matteo Perin 02 Mar '26

02 Mar '26

Dear BIRD dev-team and community, This is a patch proposal spawned from the discussion in a previous mailing list thread [0], regarding how to achieve automatic BGP peering establishment using the IPv6 Neighbor Discovery mechanism. Over the last few weeks, I worked on implementing the feature with the outline Maria Matejka kindly provided. As expected, it proved to be quite challenging, especially when it came to integrate the peer discovery approach with the current dynamic BGP implementation. To briefly summarize the implemented automatic peering mechanism and added capabilites: - The ability for the RAdv protocol to receive and read incoming ICMPv6 RAs was added. - Route-like objects, containing RAs data are created, based on advertisments detections. These are stored in a new kind of routing table. - Lifetime of the objects in the table is determined by the ICMPv6 RA Router Lifetime field. RA expiration will remove the object from the table. - The discovery process is enabled only if a new neighbor discovery option is enabled in the RAdv protocol configuration. - A new channel was added to the BGP protocol called peers. - When present in the BGP configuration, an export to this BGP channel (allowed only in dynamic BGP) will trigger the spawn of a new session. - Withdrawal the object from the peers routing table will trigger the corresponding BGP session shutdown. - An automatic BGP session can be made permanent via configuration with a persist option in the peers channel. To test the main functionality of this feature it I used multiple VMs linked by a bridge with BIRD setup on all of them. BGP session establishment is successful between all routers even with a very minimal configuration. I will provide an example, so you can also see the new configuration parameters in action: protocol device { } peer table nd_peers; protocol radv radv1 { peer { table nd_peers; }; interface "enp5s0" { max ra interval 60; min ra interval 20; # Enable neighbor discovery on this interface # When enabled, BIRD will parse incoming RAs and store router info neighbor discovery yes; }; } protocol bgp bgp1 { dynamic name "bgp_peer"; dynamic name digits 3; local as 65000; neighbor range fe80::/12 external; # Link-local range for BGP unnumbered # Peers channel for importing peer discoveries and spawning sessions peers { # Interface for BGP session establishment from "enp5s0"; # Persist sessions on route withdrawal persist yes; table nd_peers; import all; export all; }; ipv4 { import all; export all; }; ipv6 { import all; export all; }; } Of course, I have some concerns about some design choices and code optimization, I tried to find the best solution that did not involve major refactorings or moving code around and some comments on how to improve rough edges from people more experienced on the current codebase would be really appreciated. Mostly, the two main points I am not entirely happy about are: - How I handled the RAs staleness mechanism based on router lifetime. I looked for it but there does not seem to be a per-route staleness mechanism already in place, so I resorted to adding a check for expired entries when the RAdv protocol timer is triggerd, which is not ideal. - The mechanism to avoid spawning multiple sessions when both dynamic BGP and this new feature are both configured. For now, I try looking for BGP session with the same remote peer address and give precedence to the ones spawned by the dynamic BGP mechanism, but I am quite sure it is possible to find a better solution for this. I tried to make the commit messages both informative and concise, but please ask if something is unclear or missing. I am still working on adding documentation and automated testing, but since I think the discussion about the implemetation is more useful with actual code in hand, I decided to send the main bulk of the patch right now and amend this later along with changes addressing incoming reviews. I hope you will appreciate the work done. Best Regards, Matteo [0] https://bird.network.cz/pipermail/bird-users/2025-November/018482.html Matteo Perin (4): Nest: Add net_peer route type to track discovered peers RAdv: Add neighbor discovery based on incoming RAs to RAdv proto BGP: Move postponed socket reloop logic from start to start_locked to achieve locking requirements BGP: Add peers channel and sessions spawn on export to achieve automatic peering lib/net.c | 16 ++++ lib/net.h | 31 ++++++- nest/config.Y | 3 +- nest/proto.c | 2 +- proto/bgp/attrs.c | 57 +++++++++++++ proto/bgp/bgp.c | 187 +++++++++++++++++++++++++++++++++++++++---- proto/bgp/bgp.h | 28 ++++++- proto/bgp/config.Y | 15 +++- proto/bgp/packets.c | 11 +++ proto/radv/config.Y | 3 +- proto/radv/packets.c | 41 +++++++++- proto/radv/radv.c | 163 ++++++++++++++++++++++++++++++++++++- proto/radv/radv.h | 4 + 13 files changed, 533 insertions(+), 28 deletions(-) -- 2.43.0

2 15

iBGP config.
by Mike Neo 29 Jan '26

29 Jan '26

Hi, I have one operator with a full BGP table (one BGP session) and one IX (two BGP sessions, one BGP session each, to two different ISP routers). I need to configure two BGP routers based on Ubuntu + Bird 2/3 with iBGP. Could someone share this configuration and point out what to watch out for when traffic is ~1-2 Gbps? Thanks in advance.

4 5

BIRD 3.1.5 crash: Assertion failure in do_lock / if_find_by_index
by Moraxyc 06 Jan '26

06 Jan '26

Hi BIRD Team, I wanna report a crash with BIRD 3.1.5 running on NixOS. The crash triggers a `bug()` assertion failure related to locking mechanisms during interface lookup (`if_find_by_index`). I have successfully reproduced this issue locally with a minimal configuration. Environment: - BIRD Version: 3.1.5 - OS: NixOS unstable (glibc 2.40) - Kernel: Linux 6.17.9 #1-NixOS SMP PREEMPT_DYNAMIC x86_64 GNU/Linux Reproduction Steps: 1. Configure a BGP protocol using an IPv6 Link-Local neighbor on a physical interface. 2. Start BIRD. Wait for the protocol to enter 'Active' or 'Connect' state so the port is listening. 3. Initiate a TCP connection to the BGP port: $ nc -6 -v <Link-Local-IP>%<interface> <port> 4. BIRD crashes immediately upon receiving the connection. Crash Summary (from GDB): The main thread (Thread 1) hits a bug() assertion: #3 0x000056536f6ef97a in bug (msg=<optimized out>) at sysdep/unix/log.c:412 #4 0x000056536f6fa9a1 in do_lock (dg=0x5653774ace60, lsp=0x7fba0208a2a8) at sysdep/unix/domain.c:116 #5 0x000056536f64c8ac in if_find_by_index (idx=23) at nest/iface.c:721 #6 0x000056536f6e4ac8 in sockaddr_read6 ... at sysdep/unix/io.c:583 #8 0x000056536f6ecfd7 in sk_passive_connected ... at sysdep/unix/io.c:1451 Attachments: 1. backtrace.txt: Full GDB backtrace. 2. config_snippet.txt: The minimal config used to reproduce the crash. Best regards, Moraxyc

2 2

EPVN MPLS label parsing error
by William 26 Dec '25

26 Dec '25

Hi BIRDians, Been tinkering with EPVN in (built from git on Debian 13.1) hooked into an Arista vEOS-LAB network, with an IPv6 underlay. Have all the BGP sessions up and running, pushing MACs and their next hops, receiving traffic on the VXLAN interface, all good. But I'm not seeing the traffic coming out of the linux bridge to the respective VLAN subinterface for processing. Digging round I see this in the bridge FDB: <snip> 00:50:00:00:12:01 dev vxlan100 vlan 40 extern_learn master br1 42:a5:d1:11:88:4b dev vxlan100 vlan 40 master br1 permanent 42:a5:d1:11:88:4b dev vxlan100 master br1 permanent 00:00:00:00:00:00 dev vxlan100 dst 2001:db8:ffff:1ad::403 vni 10040 self extern_learn permanent 00:50:00:00:12:01 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni 627 self extern_learn permanent 627? the VNI is 10040. root@eve-deb:~# bridge vlan show port vlan-id br1 1 PVID Egress Untagged vxlan100 40 root@eve-deb:~# bridge vni show dev vni group/remote root@eve-deb:~# checking evpntab and etab: bird> sh route table evpntab Table evpntab: evpn mac 1004003:10040 0 fe:40:19:7e:2a:79 * unicast [SPINE1_EVPN 18:21:59.435 from 2001:db8:ffff:1aa::1] * (100/?) [AS4201004001i] via 2001:db8:ffff:1f3::8 on ens4 mpls 627 evpn imet 5001:10040 0 2001:db8:ffff:1ad::501 [evpn1 18:11:30.067] * (120) evpn imet 1004003:10040 0 2001:db8:ffff:1ad::401 [SPINE1_EVPN 18:07:31.985 from 2001:db8:ffff:1aa::1] * (100) [AS4201004001i] evpn imet 1004003:10040 0 2001:db8:ffff:1ad::403 [SPINE1_EVPN 18:07:31.987 from 2001:db8:ffff:1aa::1] * (100) [AS4201004003i] evpn mac 1004003:10040 0 00:50:00:00:12:01 * unicast [SPINE1_EVPN 18:21:43.590 from 2001:db8:ffff:1aa::1] * (100/?) [AS4201004001i] via 2001:db8:ffff:1f3::8 on ens4 mpls 627 bird> sh route table etab Table etab: 00:00:00:00:00:00 vlan 40 unicast [evpn1 18:11:30.067] * (80) via 2001:db8:ffff:1ad::403 on vxlan100 mpls 10040 42:a5:d1:11:88:4b unicast [bridge1 16:58:39.461] * L (0) dev vxlan100 fe:40:19:7e:2a:79 vlan 40 unicast [evpn1 18:21:59.434] * (80) via 2001:db8:ffff:1ad::401 on vxlan100 mpls 627 00:50:00:00:12:01 vlan 40 unicast [evpn1 18:21:43.590] * (80) via 2001:db8:ffff:1ad::401 on vxlan100 mpls 627 06:06:4f:2b:a5:e6 unicast [bridge1 16:54:40.358] * L (0) dev br1 bird> Where's it coming from? On the single (so far) attached Arista spine we see this: dc1-spine-1#sh bgp evpn BGP routing table information for VRF default Router identifier 192.168.1.10, local AS number 4201003001 Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selection Origin codes: i - IGP, e - EGP, ? - incomplete AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 1004003:10040 mac-ip 0050.0000.1201 2001:db8:ffff:1ad::401 - 100 0 4201004001 i * > RD: 1004003:10040 imet 2001:db8:ffff:1ad::401 2001:db8:ffff:1ad::401 - 100 0 4201004001 i * > RD: 1004003:10040 imet 2001:db8:ffff:1ad::403 2001:db8:ffff:1ad::403 - 100 0 4201004003 i * > RD: 5001:10040 imet 2001:db8:ffff:1ad::501 2001:db8:ffff:1aa::501 - 100 0 4201005001 i dc1-spine-1# 2001:db8:ffff:1ad::501 is the loopback that the vxlan interface is using. Something going on weird with the RT processing. Having a look at a packet dump of an EVPN update on the wire: 18:21:59.434664 IP6 (class 0xc0, flowlabel 0x59dd9, hlim 3, next-header TCP (6) payload length: 151) 2001:db8:ffff:1aa::1.40949 > 2001:db8:ffff:1aa::501.179: Flags [P.], cksum 0x107d (correct), seq 4225498746:4225498865, ack 3651948816, win 498, options [nop,nop,TS val 3223710250 ecr 3856730090], length 119: BGP Update Message (2), length: 119 Origin (1), length: 1, Flags [T]: IGP 0x0000: 00 AS Path (2), length: 10, Flags [T]: 4201003001 4201004001 0x0000: 0202 fa66 37f9 fa66 3be1 Multi-Protocol Reach NLRI (14), length: 56, Flags [OE]: AFI: VPLS (25), SAFI: EVPN (70) no AFI 25 / SAFI 70 decoder 0x0000: 0019 4610 2001 0db8 ffff 01ad 0000 0000 0x0010: 0000 0401 0002 2100 0200 0f51 e327 3800 0x0020: 0000 0000 0000 0000 0000 0000 0030 fe40 0x0030: 197e 2a79 0000 2738 Extended Community (16), length: 16, Flags [OT]: target (0x0202), Flags [none]: 1004003:10040 encapsulation (0x030c), Flags [none]: Tunnel type: VXLAN 0x0000: 0202 000f 51e3 2738 030c 0000 0000 0008 The RT there is showing correctly. Hang on... 627 HEX is 273... looks like the 2 bytes of the latter half of the RT is being trimmed by 4 bits. I couldn't get a hang of the code to try and ID where it's playing up so sorry, no patch. Also, I'm not able to use 4-byte ASNs in the first part of the RT. The docs indicate that we should be able to, but the config barfs with out-of-range (was trying to use 1005001 - a subset of the ASNs being used). Config: filter SPINE_LO { if net.len = 128 then accept; reject; } evpn table evpntab; protocol bgp SPINE1_BGP { ipv6 { import all; export filter SPINE_LO; }; local 2001:db8:ffff:1f3::9 as 4201005001; neighbor 2001:db8:ffff:1f3::8 as 4201003001; } protocol bgp SPINE1_EVPN { evpn { import all; export all; }; local 2001:db8:ffff:1aa::501 as 4201005001; neighbor 2001:db8:ffff:1aa::1 as 4201003001; multihop; } eth table etab; protocol bridge { eth { table etab; export all; }; bridge device "br1"; debug all; }; protocol evpn { eth { table etab; }; evpn { }; rd 5001:10040; import target (rt, 1004001, 10040); import target (rt, 1004003, 10040); export target (rt, 5001, 10040); tunnel device "vxlan100"; router address 2001:db8:ffff:1ad::501; vni 10040; vid 40; debug all; }; Took a bit to work it all out based on a previous thread and the testing config, but got there in the end, then found this :( If you're able to spin up a patch I can re-compile with it and test. Regards, William -- This email has been checked for viruses by Avast antivirus software. www.avast.com

2 6

BIRD 3.1.5 weird crashes - followup
by Łukasz Jarosz 19 Dec '25

19 Dec '25

Hello everyone, I guess this one is on me (I blame severe sleep deprivation ;) ). Turns out VPP was the culprit. Somewhere inbetween config generation my statseg definition went MIA. Still, I find fact that BIRD was constantly crashing very surprising and sole reason why I went on wild goose chase after "which route crashes my BIRD" instead of looking into flapping issue first. Pozdrawiam, Łukasz Jarosz

2 1

BIRD 3.1.5 weird crashes
by Łukasz Jarosz 18 Dec '25

18 Dec '25

Hello, I am coming to you with a weird one. I have simple iBGP setup between two routers which are interconnect through VLAN on IPv4 (/30) PtP link. For now RTR1 has all of the BGP feeds. I wanted to pass it to RTR2. Config on RTR2 is pretty simple: filter bgp_in { preference = bgp_local_pref; accept; } filter bgp_out { if proto = "CORE" then accept; reject; } protocol bgp RTR1 { local xx.xx.xx.xx as PUBLICAS; neighbor xx.xx.xx.xx as PUBLICAS; ipv4 { table master4; next hop self; import filter bgp_in; export filter bgp_out; }; } As soon as session starts up it loads routes, then unloads them and resets bird process. And it happens again and again and again... Logs doesn't seem very helpful: Dec 18 12:36:14 RTR2 bird[2009]: Started Dec 18 12:37:20 RTR2 systemd-journald[474]: [🡕] Suppressed 110623 messages from dataplane-bird.service Dec 18 12:37:20 RTR2 bird[2009]: RTR1.ipv4: Export state changed from DOWN to FEEDING Dec 18 12:37:20 RTR2 bird[2009]: RTR1.ipv4: Export state changed from FEEDING to PARTIAL Dec 18 12:37:20 RTR2 bird[2009]: RTR1: State changed to up Dec 18 12:37:20 RTR2 bird[2009]: RTR1.ipv4: Export state changed from PARTIAL to READY Dec 18 12:37:20 RTR2 bird[2009]: RTR1.ipv4: Fed up Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: Netlink: Network is unreachable Dec 18 12:37:23 RTR2 bird[2009]: ... Dec 18 12:37:23 RTR2 bird[2009]: Kernel dropped some netlink messages, will resync on next scan. Dec 18 12:37:23 RTR2 bird[2009]: Shutting down Dec 18 12:37:23 RTR2 systemd[1]: Stopping dataplane-bird.service - BIRD Internet Routing Daemon... Dec 18 12:37:23 RTR2 bird[2009]: RTR1: Shutting down Dec 18 12:37:23 RTR2 bird[2009]: RTR1.ipv4: Export state changed from READY to DOWN Dec 18 12:37:23 RTR2 bird[2009]: RTR1.ipv4: stop import: rr 2 set 0 valid 0 pruning 0 pruned 0 Dec 18 12:37:23 RTR2 bird[2009]: RTR1: State changed to stop Dec 18 12:37:23 RTR2 bird[2009]: RTR1: State changed to flush Dec 18 12:37:24 RTR2 bird[2009]: RTR1: State changed to down Dec 18 12:37:24 RTR2 bird[2009]: Shutdown completed I also tried running the same config, but by starting BIRD processes manually as a root in foreground. It was able to load the routes, but only if pointed ipv4 channel of bgp protocol to custom separate table. As soon as I passed it into my master4 table process crashed with segfault. Unfortunately without meaningful traceback. I don't know if is important, but I use VPP as my dataplane. Pozdrawiam, Łukasz Jarosz

1 0

Writing filters that detect intersection between a prefix and a prefix set
by zx＠zxinc.org 16 Dec '25

16 Dec '25

Hello, I have a prefix set like [ 192.168.1.0/24+, 192.168.2.0/24+ ] and I want to write a filter that filters all prefixes intersects with the prefix set and accepts all others, that is, accepts 192.168.0.0/24, 192.168.3.0/24, 10.0.0.0/8, rejects 192.168.1.1/32, 192.168.1.0/24, 192.168.2.0/24, 192.168.2.0/23, 192.168.0.0/16, 192.0.0.0/8, Anyone who knows how to write such a filter? Is it possible? Thanks. ---- zx

2 2

BIRD 3.1.5 and 2.17.3 released
by Maria Matejka 11 Dec '25

11 Dec '25

Dear BIRD users, we are releasing BIRD versions 3.1.5 and 2.17.3. In 2.17.3, we have fixed a bug in RAdv prefix deprecation and a crash in BMP. In 3.1.5, we have fixed the same bug in RAdv, several crashes in MRT, some filter misbehavior, a reconfiguration crash in Babel, OSPF and RIP, included a thread group configuration and a fix for a very stupid bug causing the BSD kernel export to reject everything. Big thanks to all of you who helped us find and fix these issues! 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>. We are working on upstream RPM repositories as well. Happy routing! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

BGP Add-path multiplication
by Jon Langemak 11 Dec '25

11 Dec '25

Hi folks, I was doing some testing with BIRD in a hierarchical route reflector configuration. Something that looks like this... +--------+ +--------+ +--------+ +--------+ | Left | | Left | | Right | | Right | | Tier 2 | | Tier 1 | | Tier 1 | | Tier 2 | | RR | | RR | | RR | | RR | +-----------+ | | | | | | | | | | +--------+ +--------+ +--------+ +--------+ +------------+ | | | | | Sending | | Receiving | | PE Router | | PE Router | | | | | +-----------+ +--------+ +--------+ +--------+ +--------+ +------------+ | Left | | Left | | Right | | Right | | Tier 2 | | Tier 1 | | Tier 1 | | Tier 2 | | RR | | RR | | RR | | RR | | | | | | | | | +--------+ +--------+ +--------+ +--------+ Basically we have two PEs that are connected to local tier 2 RRs which then connect to the tier 1 RRs to form a mesh. I couldn't get the lines to not look a mess on the diagram but the peering looks as follows... * PE routers peer to both local tier 2 RRs (left or right side) * Tier 2 RRs peer to both tier 1 RRs (within left or right) * Tier 1 RRs peer to both tier 1 RRs (between left and right) The only peering exception in terms of a full mesh peering is that RRs of the same type do not peer together in the same area (left or right). In terms of the diagram that means that vertical peering between nodes does not exist. What I'm seeing is that in a peering configuration with BGP add-path BIRD is sending all of the paths it is aware of to all of its peers. For instance... * A prefix originated from the PE on the left side of the diagram shows up as one path in each left side tier 2 RR it is peered with (1 path in each left side tier 2 RR) * The left side tier 2 RRs both peer to each left side tier 1 RRs so they each send a path to each of the left side tier 1 RRs (2 paths in each left side tier 1 RR) * The left side tier 1 RRs both peer to each of the right side tier 1 RRs so they send both paths they are aware of to each right side tier 1 RR (4 paths in each right side tier 1 RR) * The right side tier 1 RRs both peer to each of the right side tier 2 RRs so they send their 4 paths to each right side tier 2 RR (8 paths in each right side tier 2 RR) * The right side (receiving) PE ends up getting 8 paths from each right side tier 2 RR meaning it has a total of 16 paths for one prefix. Put more simply - a single path originating in the left side ends up getting multiplied by a factor of two at each route reflector "layer". >From my basic understanding of the code I believe this happens because BIRD considers paths unique on a per neighbor basis. Because of this - identical paths learned from unique neighbors can get assigned unique path IDs and therefore be propagated through the topology. From my understanding of RFC 7911 - this sort of topology was not discussed so there is no defined means for how to handle add-path and the deduplication of these paths in this kind of hierarchical route reflector setup. However I believe that in some other BGP implementations you can configure the route reflectors to only send paths with unique next-hops which would effectively deduplicate the paths in this kind of topology. I was curious if other folks had run into this before and if there has been any talk about possible solutions for BIRD to work with add-path in a hierarchical route reflector model without the path multiplication occurring. Thanks! - Jon

1 1

RFC 4684 implementation in Bird
by Jerome Tollet (jtollet) 10 Dec '25

10 Dec '25

Hello Bird community, I was wondering if someone already considered the implementation of RFC 4684 in Bird. It's rather old but still helpful for some highly multi-tenant environments. Any advice on this would be much appreciated. Regards, Jerome

2 2