October 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

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

BIRD crashes on OSPF reconfiguration
by Nicolas Devos 03 Nov '25

03 Nov '25

Hello, I am here to report a crash encountered upon reconfiguration of bird. The crash is reproducible using the `birdc reconfigure soft` command. In this example I changed the OSPF link type (from pointopoint to broadcast). However, I have seen the crash with other reconfigurations as well. Below I entering the configurations, log and stack trace. This hopefully helps in debugging the issue. If more information is needed, let me know. I am happy to help where I can. The tested version is v3.1.4. ``` # bird -u bird -g bird -c /opt//bird/bird.conf -d bird: 2025-10-28 12:37:48.107 [0001] Chosen router ID 10.89.112.123 according to interface enp6s0 bird: 2025-10-28 12:37:48.107 [0001] Started bird: 2025-10-28 12:37:50.621 [0001] Reconfiguring bird: 2025-10-28 12:37:50.621 [0001] Adding protocol ospf1 bird: 2025-10-28 12:37:50.621 [0001] Reconfigured bird: 2025-10-28 12:37:53.885 [0001] Reconfiguring bird: 2025-10-28 12:37:53.886 [0001] ospf1: Restarting interface enp11s0.3676 (172.21.8.0/28) in area 0.0.0.1 bird: 2025-10-28 12:37:53.886 [0001] Trying to lock in a bad order: 00007ffed0528670 00007f9a66c1a3b8 Aborted (core dumped) ``` ``` # birdc 'configure soft "/tmp/ospf/ospf-2.conf"' BIRD 3.1.4 ready. Reading configuration from /tmp/ospf/ospf-2.conf Reconfigured # birdc 'configure soft "/tmp/ospf/ospf-1.conf"' BIRD 3.1.4 ready. Connection closed by server ``` ``` # cat /tmp/ospf/ospf-1.conf router id 10.89.112.123; protocol device {} protocol kernel { learn; scan time 20; ipv4 {}; } protocol ospf v2 { area 1 { interface "enp11s0.3676" { dead 40; type broadcast; }; }; } ``` ``` # cat /tmp/ospf/ospf-2.conf router id 10.89.112.123; protocol device {} protocol kernel { learn; scan time 20; ipv4 {}; } protocol ospf v2 { area 1 { interface "enp11s0.3676" { dead 40; type pointopoint; }; }; } ``` ``` Thread 1 "bird" received signal SIGABRT, Aborted. 0x00007ffff7c8bedc in __pthread_kill_implementation () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff7c8bedc in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x00007ffff7c3eb46 in raise () from /lib64/libc.so.6 #2 0x00007ffff7c28833 in abort () from /lib64/libc.so.6 #3 0x0000555555636e1f in bug () #4 0x0000555555638b83 in do_lock () #5 0x00005555555969f9 in olock_free.lto_priv () #6 0x000055555558b85a in pool_free () #7 0x000055555559712f in rfree.part () #8 0x0000555555600265 in ospf_reconfigure.lto_priv () #9 0x00005555555a7581 in protos_do_commit.lto_priv () #10 0x00005555555786e4 in config_do_commit () #11 0x0000555555579bf3 in config_commit () #12 0x000055555563dc12 in cmd_reconfig () #13 0x0000555555654f6a in cf_parse.isra () #14 0x0000555555571e12 in cli_parse () #15 0x000055555559e6d9 in cli_command () #16 0x000055555559e93b in cli_event.lto_priv () #17 0x000055555558d953 in ev_run_list_limited () #18 0x000055555556bf4e in main () ``` Kind regards, Nicolas This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately and delete this message and any attachment from your system. Do not copy them or disclose the contents to any other person.

2 2

Re: [PATCH v5] Babel: Replace internal route selection by bird's nest
by nick 26 Oct '25

26 Oct '25

Hello, We're still waiting for any feedback on this useful patch. We've been running it in our mesh network with nearly 200 nodes. I'm also considering submitting it to the routing feed (cc @Toke), and I hope the patch will be adapted for BIRD 3 as well. For reference, here's the original post: https://bird.network.cz/pipermail/bird-users/2023-February/016705.html Tested-by: Nick Hainke <vincent(a)systemli.org> Best regards, Nick

3 3

[PATCH] BGP: Do not start connect retry timer if connect immediately succeeds
by Ze Xia 18 Oct '25

18 Oct '25

BGP connect retry timer is unconditionally started in bgp_connect(), which will be stopped by bgp_send_open() in bgp_connected() with successful connection. However, if the sk_connect() in sk_open() immediately succeeds, this code path will be immediately called. This happens before the timer is even started, thus the timer will never be stopped again. Signed-off-by: Ze Xia <billxia135(a)gmail.com> --- proto/bgp/bgp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c index ad51e626..6358afc6 100644 --- a/proto/bgp/bgp.c +++ b/proto/bgp/bgp.c @@ -1628,8 +1628,10 @@ bgp_connect(struct bgp_proto *p) /* Enter Connect state and start establishing c s->ao_keys_num = 0; s->ao_keys_init = NULL; - DBG("BGP: Waiting for connect success\n"); - bgp_start_timer(conn->connect_timer, p->cf->connect_retry_time); + if (s->type == SK_TCP_ACTIVE) { + DBG("BGP: Waiting for connect success\n"); + bgp_start_timer(p, conn->connect_timer, p->cf->connect_retry_time); + } return; err: -- 2.45.2

4 4

Question: statistics column rejected vs. filtered
by Maiyun Zhang 17 Oct '25

17 Oct '25

Hello all, I am sorry if this is already documented somewhere. I have a question regarding the output of `birdc show protocol all xxx`: what is the difference between the "rejected" and the "filtered" columns? Regards, Maiyun Zhang (he/him)

2 1

Syntax of 'show babel' commands?
by Chris Webb 16 Oct '25

16 Oct '25

I have a router with a simple babel protocol announced on an interface: protocol babel babel { interface "eth2" { next hop prefer ipv6; }; ipv4 { export where net ~ [0.0.0.0/0]; import none; }; ipv6 { export where net ~ [::/0]; import none; }; randomize router id; } bird> show proto babel Name Proto Table State Since Info babel Babel --- up 17:32:00.497 Out of interest, I tried the 'show babel' commands, but couldn't work out the syntax: bird> show babel ? show babel interfaces [<name>] ["<interface>"] Show information about Babel interfaces show babel neighbors [<name>] ["<interface>"] Show information about Babel neighbors show babel entries [<name>] Show information about Babel prefix entries show babel routes [<name>] Show information about Babel route entries bird> show babel interfaces "eth2" syntax error, unexpected CF_SYM_KNOWN bird> show babel interfaces babel syntax error, unexpected CF_SYM_KNOWN bird> show babel routes babel syntax error, unexpected CF_SYM_KNOWN What would be a correct argument to supply to these commands? In case it's relevant, I'm running 2.17.1 on Linux, which is the latest 2.x version on https://bird.network.cz/ https://bird.network.cz/download/ although I've just spotted there was a 2.17.2 announced on the mailing list in September. Best wishes, Chris.

4 5

SRv6 support
by Sébastien PARISOT 15 Oct '25

15 Oct '25

Hello BIRD team, Is there interest for SRv6 support in BIRD? We have an internal fork with SRv6 L3VPN support that we have been using for several years in our network, we can upstream the patches. It is not a 100% complete support (at least the SID allocator is missing: we use static routes to bind the routes to a specific SID), but it is enough to act as a PE, there is BGP support and it installs remote SRv6 routes in the Linux kernel SRv6 using netlink. Please let me know what you think. If anyone would like to have a look, I attach the patches (for master branch) to implement SRv6 SID stack support in the nest and static protocol. Any comments are welcome. Example: protocol static { vpn4 { table vpntab4; }; route 10:42 10.0.0.0/24 via "eth0" srv6 fc::42; } bird> show route table vpntab4 Table vpntab4: 10:42 10.0.0.0/24 unicast [static1 14:17:42.184] * (200) dev eth0 srv6 <fc::42> I still have some clean-up work to do before I can share the rest of the patches (mainly netlink and bgp). Thanks. -- Sébastien

2 4

L3VPN: Adding support for import/export target none and import target all
by Sébastien PARISOT 14 Oct '25

14 Oct '25

Hello BIRD team, This patch (for master branch) contains two commits for L3VPN protocol: - 0001: It adds support for "import/export target none" (or "[]" to specify an empty set, which is the same). For example it can be used when we do not want to import/export any route from/to the VRF, of if we prefer to set the RT it in filters (adding different RT for different IP prefixes for example). - 0002: It adds support for "import target all", ie all VPN routes are imported in the VRF IP table regardless of the RTs. Useful when we need to import any route or we want to have a more complex policy implemented in filters. Thanks! -- Sébastien

3 6

bird 3.1.4 Assertion 'heea' failed at nest/rt-table.c:4120
by Matt Corallo 07 Oct '25

07 Oct '25

Thanks for all the work on bird3. It looks like 3.1.4 is much more stable than past releases, however I still get a crash if I start it while a routing table that bird is responsible for has stale entries left over from a past run which crashed. I now see #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007ffff7dd99ff in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89 #2 0x00007ffff7d84cc2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff7d6d4ac in __GI_abort () at ./stdlib/abort.c:73 #4 0x000055555566044c in bug (msg=msg@entry=0x555555670ee0 "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:412 #5 0x00005555555ebd92 in rt_next_hop_update_rte (old=0x7fffc74f2038, new=0x7ffff6a5d160) at nest/rt-table.c:4120 #6 rt_next_hop_update_net (tab=<optimized out>, ni=<optimized out>, n=<optimized out>) at nest/rt-table.c:4357 #7 rt_next_hop_update (_tab=<optimized out>) at nest/rt-table.c:4579 #8 0x00005555555ac0a4 in ev_run_list_limited (l=l@entry=0x5555557da288, limit=4294967294, limit@entry=4294967295) at lib/event.c:338 #9 0x000055555565d64c in birdloop_run (_loop=0x5555557da1b0) at sysdep/unix/io-loop.c:1836 #10 0x00005555555ac0a4 in ev_run_list_limited (l=0x5555558cce78, limit=4294967283, limit@entry=4294967295) at lib/event.c:338 #11 0x000055555565b40f in bird_thread_main (arg=0x5555558cd0d0) at sysdep/unix/io-loop.c:952 #12 0x00007ffff7dd7b7b in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448 #13 0x00007ffff7e557b8 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

2 1