November 2025 - Bird-users

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

[RADV] prefix deprecation
by Michael Saxl 29 Nov '25

29 Nov '25

Hello, I'm doing some experiments using radv and bird3. as expected it bird3 automatically sends prefix informations if not somehow disabled. when I dynamically add a prefix to an interface (ip a a address/64 dev eno1) it immediatly blasts out that prefix with the default parameters (hardcoded in radv.c as radv_prefix_config default_prefix). Now if that prefix is removed, this prefix is sent as valid_lifetime and preferred_lifetime = 0, but at least linux (NetworkManager) seems to ignore this deprecation, mainly because onlink and autonomous are not set. As soon as I modify the code to do that, the prefix gets deprecated (valid_lifetime gets lower-limited to 7200 on the os side, I think strictly rfc valid_lifetime should also count down on bird starting at 7200, but in practice 0 seems to work too). I've not tried all combinations, but the simplest fix for me is setting .onlink and .autonomous =1 in dead_prefix. I'm not sure if this does not break prefixes that are explicitly defined, so I did not modifiy dead_prefix but instead changed WALK_LIST_DELSAFE(pfx, next, ifa->prefixes) { if (pfx->valid && !pfx->mark) { RADV_TRACE(D_EVENTS, "Invalidating prefix %N on %s", &pfx->prefix, ifa->iface->name); pfx->valid = 0; pfx->changed = now; struct radv_prefix_config *pc = radv_prefix_match(ifa, &pfx->prefix); if(pc) pfx->cf = pc; else pfx-cv = &dead_prefix; } } and in packet.c funtion radv_prepare_prefix I changed if (!px->valid) { ifa->valid_time = MIN(ifa->valid_time, px->changed + ifa->cf->prefix_linger_time S); op->preferred_lifetime = 0; op->valid_lifetime = 0; // might need to be >7200s, see RFC4862 section 5.5.3 e } What do you think about this changes? Regards Michael

2 3

Access and mutation of routes' scope attribute
by Bertrand Petit 27 Nov '25

27 Nov '25

I'm in the process of upgrading a set of bird instances from v1 to v2. The running configurations of these nodes were written circa ten years ago, for a network that since has shrunk quite a lot, nethertheless I would like to change them as little as possible. During preparation work I've hit a snag: most of these configurations use routes scope as one of the filtering criterions but bird v2 experience some grammatical difficulties when parsing them. The user manual states that one can access and mutate a route scope through the "scope" symbol (section 5.5). Nonetheless, the configuration file parser rejects the following two functions---these are fictious functions written to concisely replicate the problem, they are accompanied by the error message produced by "bird -c <file> -p". function ScopeAccess () -> bool { return scope = SCOPE_HOST; } bird: 2025-11-26 10:30:02.631 [0001] <FATAL> scope-access.conf:3:10 syntax error, unexpected SCOPE function ScopeSet () -> bool { scope = SCOPE_HOST; return true; } bird: 2025-11-26 10:31:25.081 [0001] <FATAL> scope-set.conf:3:3 syntax error, unexpected SCOPE I had a quick look into "config.Y". I can't predend I fully understand how the grammar is constructed due to a cursory glance, however I suppose the constructions shown above are covered by the "term: ... static_attr ..." and "cmd: ... symbol_known '=' term ';'" productions. When using the manual and these productions as supporting material I think the two functions shown above are legit. Am I correct? Then I looked at "test.conf" where I found a construction involving "scope" used not as an attribute but as a type, a declaration that is not part of the documentation: "enum scope ev2 = SCOPE_UNIVERSE;". This construction, accepted by the parser, is contradicting the user manual. Quoting it, section 5.2: "Enumeration types are fixed sets of possibilities. You can't define your own variables of such type, but some route attributes are of enumeration type." With regard to this undocumented declarative form, at this stage, I'm wondering if a grammatical ambiguity could exist between "scope" the type and "scope" the attribute? -- %!PS -- Bertrand Petit /D{def}def/E{exch}D/G{get}D/I{2 div}D/U{dup}D/L{roll}D/Y{setgray}D/N{newpath}D /O{N 0 0 moveto}D/P{pop}D/T{translate}D currentpagedevice/PageSize G U 0 G/w E D 1 G /h E D w I h I T 0 Y 1 setlinewidth 0 1 2 { P 120 rotate 2 4 w U mul h U mul add sqrt I 50 add {N 50 0 3 2 L 0 360 arc stroke}for}for/s{O true charpath pathbbox exch 4 -1 L E sub I 3 1 L sub I} D /l(bp)D 0.94 Y /Helvetica findfont 22 scalefont setfont l s P(x)s exch P T O l show showpage

3 3

None
by Maiyun Zhang 23 Nov '25

23 Nov '25

>From 625b42a0d9f4157c59d90e25eaa56d9bf8b5090a Mon Sep 17 00:00:00 2001 From: Zhang Maiyun <me(a)maiyun.me> Date: Wed, 1 May 2024 12:37:16 -0700 Subject: [PATCH] BFD: remove unused spinlock 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.50.1 (Apple Git-155)

2 1

Re: Your message to Bird-users awaits moderator approval
by Marek Küthe 23 Nov '25

23 Nov '25

Hello, After changing the GRC from bird2 to bird3, the mrt dumps no longer work. Could someone take a look at this? I have attached a faulty MRT dump. peerindex and bgpgrep from ubgpsuite do not display any peers or attributes. My custom MRT parser can no longer read the MRT files. The mrt2json conversion from mrtparse looks strange. Best regards, Marek Küthe PS: Seems the mrt dump was too big. On Sun, 23 Nov 2025 00:10:50 +0100 bird-users-owner(a)network.cz wrote: > Your mail to 'Bird-users' with the subject > > mrt dumps are broken in bird3 (was: Re: [dn42] Route Collector > migration announcement) > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Message body is too big: 8010071 bytes with a limit of 400 KB > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > https://trubka.network.cz/mailman/confirm/bird-users/cab52e2503fb50edf42223… > -- Marek Küthe m.k(a)mk16.de er/ihm he/him

2 1

Missing route that is shown in filter used by eBGP
by Nico Schottelius 21 Nov '25

21 Nov '25

Hello, today I have a related issue with missing route export: - In a bgp instance I use the filter "from_our_place_to_internet" - If I run "show route filter from_our_place_to_internet" all correct routes match - However if I check on the other eBGP end, the route is actually *not* received (it's not filtered, it is really not received) - If I "hack" the filter as follows, bird DOES export the route: # Hack 2025-11-20 if ( net ~ [ 185.203.114.0/23+ ] ) then { print "Exporting 185.203.114.0 to internet"; accept; } - Some thoughts: - The route is direct, static and babel received - Our filter matches RTS_STATIC - However bird seems to "prefer" the direct route - We do not export direct marked routes, but static routes - Is that the cause of the problem? But it is also static... However it does not make sense to me, thus wondering: - Why does bird show the route in the filter output? - Why does bird show not export it via eBGP? - Why does my hack then make it work in the end? Details below, any help appreciated as this is driving me nuts. Best regards, Nico -------------------------------------------------------------------------------- a) the affected route bird> show route all 185.203.114.0/23 Table master4: 185.203.114.0/23 unicast [direct1 2025-11-07] * (240) dev eth4 Type: device univ unicast [place6_10_v4 2025-11-07] (200) dev eth4 Type: static univ unicast [babel1 12:47:44.565 from fe80::3eec:efff:fecb:d81b] (130/96) [00:00:00:00:93:4e:c2:43] via 147.78.194.67 on eth1 Type: Babel univ Babel.metric: 96 Babel.router_id: 00:00:00:00:93:4e:c2:43 bird> b) the show route output bird> show route filter from_our_place_to_internet Table master4: 185.203.114.0/23 unicast [place6_10_v4 2025-11-07] (200) dev eth4 ... c) the filter itself filter from_our_place_to_internet { if(!has_internet_length()) then reject; if(is_default_route()) then reject; if(is_from_local_asn() || is_emitted_by_one_of_our_asn_directly() || should_export_to_internet_from_customer() ) then accept; reject; } ... where the related functions are: function has_internet_length() -> bool { if ((net.type = NET_IP6 && net.len > 48) || (net.type = NET_IP4 && net.len > 24)) then { return false; } return true; } function is_v6_default() -> bool { if (net = ::/0) then return true; return false; } function is_v4_default() -> bool { if (net = 0.0.0.0/0) then return true; return false; } function is_default_route() -> bool { if(is_v6_default() || is_v4_default()) then return true; return false; } function is_from_local_asn() -> bool { if(source = RTS_STATIC) then return true; if(source = RTS_BGP && bgp_path.len = 0) then return true; return false; } function emitted_from_one_of_our_asn() -> bool { if(bgp_path.last ~ our_asn) then return true; return false; } function should_export_to_internet_from_customer() -> bool { # We don't consider non-internet networks if(!has_internet_length()) then return false; if ( (bgp_path.first ~ our_asn) && # received from one of our asn (bgp_path.len = 2) && # one of our ASNs received it (bgp_path.last ~ customer_asn) # one of our customers emitted it and we accept it ) then return true; if ( (bgp_path.len = 1) && # we ASNs received it directly (bgp_path.last ~ customer_asn) # one of our customers emitted it and we accept it ) then return true; return false; } -- Sustainable and modern Infrastructures by ungleich.ch

4 7

Strange route selection (defroute and specific)
by Nico Schottelius 20 Nov '25

20 Nov '25

Hello bird users, on one pop we have a "funky" routing selection by bird: bird> show route all for 185.203.114.92 Table master4: 0.0.0.0/0 unreachable [defroutev4 2025-10-30] * (200) preference: 200 source: static Internal route handling values: 0L 5G 0S id 1 185.203.114.0/23 unicast [incoming_server122 10:21:13.232] * (100) [AS213081i] via 2a0a:e5c0:74:1::2 on iserver122 preference: 100 igp_metric: 0 from: 2a0a:e5c0:74:1::2 source: BGP bgp_origin: IGP bgp_path: 213081 bgp_next_hop: 2a0a:e5c0:74:1::2 bgp_local_pref: 100 Internal route handling values: 0L 10G 2S id 227979 The strange thing is that the default route, that is only created for exporting to others, has a higher preference. The default route is defined as follows: protocol static defroutev4 { ipv4; route 0.0.0.0/0 unreachable; } Why is that the case? And what does it mean if bird has a "*" for both routes? I thought only the active one is selected with a *? Any hints appreciated, Nico -- Sustainable and modern Infrastructures by ungleich.ch

3 4

Segfault with ifname filter and RTD_UNREACHABLE
by Lars Gierth 19 Nov '25

19 Nov '25

Hi all, I'm migrating a bigger Babel network from Bird 2.17.x to 3.1.x. This is on OpenWrt snapshot x86_64 with latest Bird stable-v3.1 branch. Shortly after starting Bird, it segfaults. I tested all the individual filter statements in my config and confirmed it's those comparing against ifname, e.g.: if ifname = "ts_wg0" then It doesn't segfault if I first check for unreachable: if dest != RTD_UNREACHABLE && ifname = "ts_wg0" then The docs state that ifname returns an empty string for sink routes, and that's what worked for us in 2.17.x, but maybe that broke somehow? Anyway, with this workaround I can continue testing and rolling out. Here's the backtrace. The config is attached and binary+coredump can be downloaded here: https://github.com/user-attachments/files/23552707/bird-coredump.zip Let me know if the coredump is broken, gdb did say "memory read failed". #0 0x00007ffff7fabd80 in ?? () #1 0x000000000041f881 in val_same (v1=v1@entry=0x7fffffffdb90, v2=0x7fffffffdba8) at filter/data.c:281 #2 0x0000000000415bd7 in interpret (line=<optimized out>, argc=argc@entry=0, argv=argv@entry=0x0, resc=resc@entry=0, resv=resv@entry=0x0, fs=<optimized out>) at filter/f-inst.c:453 #3 0x000000000041efb6 in f_run_args (filter=0x7ffff7f31300, rte=rte@entry=0x7fffffffe8c0, argc=argc@entry=0, argv=argv@entry=0x0, flags=flags@entry=0) at filter/filter.c:232 #4 0x000000000041f01b in f_run (filter=<optimized out>, rte=rte@entry=0x7fffffffe8c0, flags=flags@entry=0) at filter/filter.c:215 #5 0x000000000045c328 in channel_rte_import (c=c@entry=0x7ffff7e61830, n=n@entry=0x7ffff7df6ea8, new=new@entry=0x7fffffffe8c0, src=0x7ffff7e6e1c0) at nest/rt-table.c:2348 #6 0x000000000046468f in babel_rte_update_unreachable (p=p@entry=0x7ffff7e61440, e=e@entry=0x7ffff7df6e30, announce=announce@entry=1 '\001') at proto/babel/babel.c:698 #7 0x0000000000466c7c in babel_rt_notify (c=<optimized out>, old=<optimized out>, P=0x7ffff7e61440, net=<optimized out>, new=0x0) at proto/babel/babel.c:2516 #8 babel_rt_notify (P=0x7ffff7e61440, c=<optimized out>, net=<optimized out>, new=0x0, old=<optimized out>) at proto/babel/babel.c:2408 #9 0x00000000004581b7 in rt_notify_basic (c=c@entry=0x7ffff7e61830, new=new@entry=0x0, old=old@entry=0x7ffff7d983b8) at nest/rt-table.c:1250 #10 0x00000000004593ab in channel_notify_basic (_channel=0x7ffff7e61830) at nest/rt-table.c:1661 #11 0x000000000043459b in ev_run_list_limited (l=0x53d860 <global_work_list>, limit=9, limit@entry=10) at lib/event.c:338 #12 0x00000000004a7f5d in io_loop () at sysdep/unix/io.c:2640 #13 0x00000000004037d7 in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:1106 Cheers, and thanks for your work! Lars Freifunk Berlin

2 2

[RFC] Unnumbered BGP automatic peering based on IPv6 ND
by Matteo Perin 18 Nov '25

18 Nov '25

Dear BIRD dev-team and community, By looking at the project code (and corroborated by this [0] earlier RFC) it seems that currently the feature of auto-discovering BGP neighbors leveraging the IPv6 ND protocol is not currently fully supported by BIRD. I would like to start working on a patch proposal to close this gap. Many of the required pieces seem to be already in-place, like support for IPv6 link-local peer addresses and support of RFC-8950 for extended next-hop. There is also the dynamic BGP implementation which seems useful for the purpose of achieving dynamic connections based on received RAs. The problem is that dynamic BGP works in a passive/reactive model only, as it waits for peers within a specified range to connect, an idea would be to integrate with this implementation but also trigger a peer connection on a RA arrival (after checking if the advertised IP is within the desired range). Since I am still new to the project codebase and contributing for the first time, I would like to outline the idea for the implementation of the feature and hear what you think of it before going through the implementation. Any suggestions on best practices, style and common pitfalls would be also very welcome. - Introduce a new configuration option (e.g. automatic_lladdr_peering, or similar) to trigger this feature. This will provide a way to avoid modifying the current behavior if not needed. The rest of the configuration will also have to contain a neighbour range of fe80::/12 and an interface for the link-local feature (both of these are already supported). The resulting configuration preamble would look something like this: local as 65532; neighbor range fe80::/12%eth0 as 65534; dynamic name "link_local_"; automatic lladdr peering on; To make the configuration tidier we could, alternatively, introduce a new value for neighbor, like “neighbor auto” or “neighbor discover” to enable the feature. - When the above configuration is found, open a L2 socket on the provided device during the bgp_startup phase. This socket will then be used to send a RS to ff02::2 (all-routers multicast) to trigger the RAs used for peer discovery on remote routers. Another option would be to start sending out unsolicited RAs for the other peers to receive for discovery, this will make sure that we are not dependent on the peer being able to answer RSs and can rely entirely on the BGP implementation. This method would require to keep sending unsolicited RAs with a certain cadence, which could be set as a timer parameter in the added configuration option. - On the rx_hook of this socket listen for incoming ICMPv6 packets with type 134 (RA) and check if they contain a link-local address (i.e. inside the range provided in the configuration). If so, initiate a new BGP connection, using the now discovered LL remote address. This will follow the same path as if the remote peer address was statically provided in the configuration (sets remote_ip, calls bgp_active). As an added failover, we could remain listening on the L2 socket and try connecting to a new peer if a new address is discovered and we are in state BS_IDLE. - After a connection is established, if it becomes stale (after hold timer elapses) we can then trigger a new RS and relative discovery as outlined above to try and connect to a new remote LL address. This will not be needed if using the unsolicited RAs variant. The rest of the connection management and BGP message handling via the TCP socket will remain the same. This idea for the implementation is the one that reuses as much of the current codebase while introducing as little new procedures as possible that I could come up with, but I think it can still be refined with more insight with the internals. One thing that I am not sure about is the introduction of a new socket and connected logic on the BGP module, but I cannot really find an alternative. There is already an implementation of a packet engine for RAs that could maybe be reused for the processing of the ICMPv6 packets, but I think it will be easier to decouple the logic and implement everything on the BGP state machine (even if it will mean some code duplication, which is not ideal). Another variant could be establishing a connection for every discovered address, as in the case of incoming connections for the dynamic BGP implementation. Maybe this is a more general solution, but since the current implementation expects an incoming request it will maybe introduce too much logic to try and fit it in. Let me know your opinion on if and if it seems a proper way to proceed (and, of course, if there is any interest in having this feature upstream). Thank you in advance for your time and feedback. Best Regards, Matteo 0: https://bird.network.cz/pipermail/bird-users/2022-July/016233.html

4 3

Bird 3 asynchronous processing and ospf delays
by Robert Story 14 Nov '25

14 Nov '25

Hello, We noticed a change from bird2 to bird3where route processing happens in a very different order. We’re running bird on a load balancer, and for us this change results in traffic drops for 1-2 minutes because our production service prefix is announced before we can reply because OSPF to the backends for the service address happens much later than before. We’re hoping to get feedback on if this change in bird3 is a bug, or if we should be using bird differently. The scenario is: transit-providers --- load-balancer w/bird --- several back-end servers - The balancer runs BGP to the transit and OSFP to the backends. - We get full routing tables from 3 transit providers. Bird OSPF configuration snippets are included at the end of this message. With bird1 and bird2, ospf would come up and both the local link addresses and the service addresses (on a stub dummy0 interface on the backends) would be exchanged within 5-10 seconds, before or shortly after BGP sessions with peers start. With bird3, ospf processes local link addresses, then starts BGP (including announcing service prefix to peers), and ospf processing of the dummy0 stub interface for the route to the service address doesn’t happen until BGP peers have sent their full BGP tables. So our questions are: - is there is a setting to make bird 3 use the old synchronous behavior? - is there a way to tweak ospf config to get dummy0 service address earlier (ie before or shortly after firewall announces static routes)? - is there a way to tweak bird config to delay static route announcement until after ospf gets service address (or after all peers have sent initial full tables)? - should we drop static service routes in the firewall, and drop ospf and just use BGP between backends and firewalls so that production route isn’t announced until at least one backend is available? Any other suggestions welcomed as well. The relevant snippets of setup which works with bird1/bird2 but not bird3 is: - relevant firewall/load balancer config: protocol ospf v3 ospfv6 { ecmp yes; area 0 { interface “eno*” { hello 1; dead 5; }; }; } protocol static sv4master { ipv4; route a.b.c.0/24 blackhole; # service prefix } - relevant backends config: protocol ospf v2 ospfv4 { ipv4; # service address a.b.c.N on dummy0 interface area 0 { interface “dummy0” { stub yes; }; interface “eno1” { hello 1; dead 5; }; }; } protocol ospf v3 ospfv6 { ipv6; area 0 { interface “dummy0” { stub yes; }; interface “eno1” { hello 1; dead 5; }; }; } protocol device { scan time 10; } Regards, Robert

3 3