- Bird-users - Mailing Lists

BIRD crashes on FreeBSD with ipa_zero()/ipa_is_ip4() assertion
by Pouria Mousavizadeh Tehrani 27 Aug '26

27 Aug '26

Hi, I'm trying to switch a FreeBSD IXP router from another routing daemon to BIRD for BGP. I already have OSPF running on the same system, and BIRD works without any problems. However, after starting BIRD and establishing/attempting to establish BGP sessions, I get the following error multiple times in `bird.log`: [0001] <BUG> Assertion 'ipa_zero(s->saddr) || ipa_zero(s->daddr) || (ipa_is_ip4(s->saddr) == ipa_is_ip4(s->daddr))' failed at sysdep/unix/io.c:1767 Many seconds after these errors, BIRD crashes. BIRD version: 3.3.2 (the same issue also occurs with older versions) FreeBSD version: 16.0-CURRENT (same with 15.1-RELEASE) Thanks, -- Pouria

2 1

ECMP for BGP multihop vs. direct
by Christoph 26 Aug '26

26 Aug '26

Hi, we have 3 BGP upstreams a) direct b) multihop c) multihop a) always wins against b) and c) even if the AS path length is equal in all 3 cases. What is the recommended way to tell BIRD 3.3.x that it should consider them as if they were all direct and ignore the fact that some are multihop? goal: ECMP routes get installed for all 3 upstreams when their properties match. best regards, Christoph

2 1

Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562
by Christoph 26 Aug '26

26 Aug '26

Hi, on bird 3.3.2-cznic.1~trixie after adding: merge paths on limit 3; to the IPv6 protocol settings and reconfiguring I noticed this BUG line in the log running 'configure' a second time did not reproduce the same BUG log entry: <INFO> Reconfigured <TRACE> device1: Scanning interfaces <TRACE> kernel2: Scanning routing table <TRACE> kernel2.ipv6: Export state changed from DOWN to FEEDING <TRACE> kernel2.ipv6: Export state changed from FEEDING to PARTIAL <TRACE> kernel2.ipv6: route refresh begin: rr 13057 set 1 valid 0 pruning 0 pruned 0 <TRACE> kernel2: Pruning table master6 <TRACE> kernel2.ipv6: route refresh end: rr 13057 set 1 valid 1 pruning 0 pruned 0 <TRACE> kernel2.ipv6: table prune after refresh begin: rr 13057 set 1 valid 1 pruning 1 pruned 0 <TRACE> kernel2.ipv6: table prune after refresh end: rr 13056 set 1 valid 1 pruning 1 pruned 1 <WARN> I/O loop cycle took 6999.418 ms for 10 events <BUG> Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562 best regards, Christoph

2 1

[PATCH 0/3] filter: improve runtime error diagnostics
by Alice39s 12 Aug '26

12 Aug '26

Hi, Filter runtime errors (`F_ERROR`) currently share filtered counters and the `filtered out` route trace with intentional policy rejects (`F_REJECT`). The detailed interpreter error is rate-limited, which can make route-dependent filter failures difficult to classify. One example is constructing a standard-community pair from a 32-bit Large Community field. Configuration parsing succeeds because the concrete value is route-dependent, but a value above 65535 correctly fails the pair constructor at runtime. This series: 1. reports both evaluated values in pair range errors; 2. keeps the existing filtered aggregate, adds a runtime-error subset for import and export, and uses a distinct route trace; 3. documents runtime pair checks and a safe LC-field guard. The series does not change log rate limits or add another error-log source. Silent export evaluations do not alter the new counters, and import keep-filtered behavior is unchanged. Base: thread-next 06ca9bf5c588df6c0587eb64bd375eb0ade526ab Validation: - autoreconf, configure, full build, and make check; - BIRD user and programmer HTML documentation; - daemon-level import/export errors and explicit-reject controls; - keep-filtered and silent export-query behavior. An equivalent series for current master is available if this should also land in BIRD 2. Alice39s (3): filter: report values for out-of-range pair components nest: track filter runtime errors in channel statistics doc: explain pair construction range failures Thanks, Alice39s alice39s(a)xmsl.dev

2 6

[PATCH 3/3] doc: explain pair construction range failures
by Alice39s 11 Aug '26

11 Aug '26

Document that expression-based pair construction is checked at filter runtime and that failed route filters do not accept the affected update. Also show how to guard a 32-bit large-community field before using it as a 16-bit pair component. --- doc/bird.sgml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/doc/bird.sgml b/doc/bird.sgml index b97793f4..5a022540 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1848,6 +1848,13 @@ in the foot). Operators <cf/.asn/ and <cf/.data/ can be used to extract corresponding components of a pair: <cf>(<m/asn/, <m/data/)</cf>. + Pair construction from expressions is range-checked at filter runtime. + If either expression evaluates to a value greater than 65535, filter + evaluation fails with a runtime error. During route import or export, the + affected update is handled as filtered instead of being accepted. An + import configured to keep filtered routes may retain the update as a + filtered route. + <tag><label id="type-quad">quad</tag> This is a dotted quad of numbers used to represent router IDs (and others). Each component can have a value from 0 to 255. Literals of @@ -1990,6 +1997,18 @@ in the foot). to extract corresponding components of LCs: <cf>(<m/asn/, <m/data1/, <m/data2/)</cf>. + Large community fields are 32-bit, while pair components are 16-bit. + Therefore, check the range before using an LC field to construct a pair. + For example, given an LC value in <cf/op/: + <code> + if op.data2 <= 65535 then + bgp_community.add((64512, op.data2)); + else + reject; + </code> + The explicit <cf/reject/ is optional policy; a filter may instead ignore + an LC that cannot be represented as a pair. + <tag><label id="type-set">int|pair|quad|ip|prefix|ec|lc|rd|enum set</tag> Filters recognize several types of sets. Sets are similar to strings: you can pass them around but you cannot modify them. Literals of type <cf>int -- 2.47.3

1 0

[PATCH 1/3] filter: report values for out-of-range pair components
by Alice39s 11 Aug '26

11 Aug '26

Pair components are range-checked at runtime when constructed from expressions. Include both evaluated values in the error so operators can identify the input that failed without reproducing the route. --- filter/f-inst.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/filter/f-inst.c b/filter/f-inst.c index 967887f6..273dc293 100644 --- a/filter/f-inst.c +++ b/filter/f-inst.c @@ -338,7 +338,8 @@ uint u1 = v1.val.i; uint u2 = v2.val.i; if ((u1 > 0xFFFF) || (u2 > 0xFFFF)) - runtime( "Can't operate with value out of bounds in pair constructor" ); + runtime("Pair component out of range 0..65535 (got %u, %u)", + u1, u2); RESULT(T_PAIR, i, (u1 << 16) | u2); } base-commit: 06ca9bf5c588df6c0587eb64bd375eb0ade526ab -- 2.47.3

1 0

[PATCH] EVPN: Fix crash when the tunnel device does not exist yet
by Florian Bauer 09 Aug '26

09 Aug '26

The EVPN protocol is prepared to start before its VXLAN tunnel device exists: evpn_start() returns PS_START to wait for the interface and evpn_if_notify() brings the protocol up once it appears. But evpn_start() also attaches the VLAN request topic, which is keyed by the name of the bridge the tunnel device is enslaved to. The configuration parser resolves the tunnel device with if_get_by_name(), which returns a placeholder for an interface that does not exist yet. Such a placeholder has no master, so attaching the topic dereferences a NULL pointer and BIRD crashes during configuration commit. Attach the topic only once the bridge is known, and retry from evpn_started(), which already runs when the interface shows up. While the topic is unattached there is nothing to publish to, so skip publishing VLAN requests and re-issue them when attaching later. This also covers evpn_shutdown(), which withdraws VLANs unconditionally and would otherwise trip the assertion in ps_publish() on the way out. Reproducible on both branches with any evpn protocol whose tunnel device is created after BIRD starts, which happens with a restarted daemon or a rebuilt bridge. --- Rooted in thread-next; cherry-picks onto master without conflicts if you want it in 2.x as well. Reproducer, a bridge and an evpn protocol pointing at a VXLAN device that is never created: ip link add lo0 type dummy ip -6 addr add fd00::1/128 dev lo0 nodad ip link set lo0 up ip link add name br-red type bridge ip link set br-red up bird -f -c bird.conf protocol bridge bridge_red { eth { table etab_red; export all; }; bridge device "br-red"; } protocol evpn evpn_red { eth { table etab_red; }; evpn; encapsulation vxlan { tunnel device "vx-red"; router address fd00::1; }; rd 10.0.0.1:100; route target (rt, 1, 100); vni 100; } Without this commit, at configuration commit: #1 ps_get_topic (name=0x10 <error: Cannot access memory at address 0x10>) at lib/pubsub.c:94 #2 ps_attach_topic (name=0x10 ...) at ./lib/pubsub.h:64 #3 evpn_start (P=...) at proto/evpn/evpn.c:1092 #4 proto_start ... #13 main 0x10 is offsetof(struct iface, name) applied to a NULL master. Built and run at the branch heads of 2026-08-08, each against its own unpatched parent, with the device missing and with it appearing late: 3.3.0 and 2.19.0 segfault before the fix, run after it, and evpn_red reaches up when the device shows up. Tarballs 3.3.1 and 2.19.2 match their heads. Rebasing onto the current thread-next moved hunk offsets only. The path where the device exists at startup is unaffected: a three-leaf two-tenant fabric on patched 3.3.1 still passes its reachability, tenant isolation and MAC learning suite. Nothing added under netlab/ in bird-tools; happy to do so if you want this case covered there. proto/evpn/evpn.c | 41 ++++++++++++++++++++++++++++++++++++++++- proto/evpn/evpn.h | 1 + 2 files changed, 41 insertions(+), 1 deletion(-) diff --git a/proto/evpn/evpn.c b/proto/evpn/evpn.c index 32326ea..c8487d9 100644 --- a/proto/evpn/evpn.c +++ b/proto/evpn/evpn.c @@ -750,6 +750,13 @@ evpn_remove_vlan(struct evpn_proto *p, struct evpn_vlan *v) static void evpn_publish_vlan_request(struct evpn_proto *p, struct vlan_request *req, bool update, int vlan_count) { + /* The topic is attached only once the tunnel device and its bridge are known, + so there may be nothing to publish to yet. Requests skipped here are + re-issued from evpn_started(); the withdraw on shutdown has nothing to + withdraw. */ + if (!p->vlan_pub_attached) + return; + struct evpn_encap *encap = evpn_get_encap(p); /* Fill header */ @@ -1068,6 +1075,28 @@ evpn_init(struct proto_config *CF) return P; } +/* + * Attach the VLAN request topic, which is keyed by the name of the bridge the + * tunnel device is enslaved to. + * + * Neither the tunnel device nor its bridge has to exist when the protocol + * starts: evpn_start() returns PS_START precisely to wait for the interface, + * and evpn_if_notify() picks it up later. So this may be called before the + * bridge is known, and is a no-op until it is. + */ +static void +evpn_attach_vlan_topic(struct evpn_proto *p, struct evpn_encap *encap) +{ + if (p->vlan_pub_attached) + return; + + if (!encap->tunnel_dev || !encap->tunnel_dev->master) + return; + + ps_attach_topic(p->vlan_pub, &vlan_requests, encap->tunnel_dev->master->name); + p->vlan_pub_attached = true; +} + static int evpn_start(struct proto *P) { @@ -1089,7 +1118,8 @@ evpn_start(struct proto *P) struct evpn_encap *encap = evpn_get_encap(p); p->vlan_pub = ps_publisher_new(p->p.pool, evpn_vlan_subscribe_hook, p); - ps_attach_topic(p->vlan_pub, &vlan_requests, encap->tunnel_dev->master->name); + p->vlan_pub_attached = false; + evpn_attach_vlan_topic(p, encap); init_list(&p->vlans); memset(&p->vlan_tag_hash, 0, sizeof(p->vlan_tag_hash)); @@ -1123,6 +1153,15 @@ evpn_started(struct evpn_proto *p, struct iface *i) if (!evpn_validate_iface_attrs(p, i)) return; + /* The bridge may only become known now; VLAN requests made before the topic + was attached went nowhere, so re-issue them once it is. */ + if (!p->vlan_pub_attached) + { + evpn_attach_vlan_topic(p, evpn_get_encap(p)); + if (p->vlan_pub_attached) + evpn_request_vlans(p); + } + proto_notify_state(&p->p, PS_UP); evpn_announce_imet(p, EVPN_ROOT_VLAN(p), 1); diff --git a/proto/evpn/evpn.h b/proto/evpn/evpn.h index 8103dfb..3fe527b 100644 --- a/proto/evpn/evpn.h +++ b/proto/evpn/evpn.h @@ -81,6 +81,7 @@ struct evpn_proto { HASH(struct evpn_vlan) vlan_tag_hash; HASH(struct evpn_vlan) vlan_vid_hash; ps_publisher *vlan_pub; + bool vlan_pub_attached; /* VLAN topic attached (needs the bridge name) */ }; struct evpn_encap { base-commit: 06ca9bf5c588df6c0587eb64bd375eb0ade526ab -- 2.55.0

2 1

Current state of segment routing
by Erik Stomp 04 Aug '26

04 Aug '26

Hello, I'm currently experimenting with Segment Routing and was curious If there are any plans to support Segment Routing with BIRD. I found a message from Matyáš Kroupa on this mailing list regarding his diploma theses and he gave a talk at this years CSNOG. As the talk is in Czech, I'm struggling to understand it. Are there any public available information about his work (maybe a development branch) or current plans to merge his implementation to the official code of BIRD? -- Best regards Erik Stomp E mail(a)erik-stomp.de OpenPGP Key-ID: 4AD5DF6F63FE15E5

3 2

Excuse me
by zx l 31 Jul '26

31 Jul '26

Hello BIRD maintainers, I am a security researcher working on open-source routing software security. Previously, I submitted several security issue reports to bird-support(a)network.cz, including vulnerability analysis, reproduction steps, and technical details related to the BIRD routing daemon. However, I have not received any acknowledgement or feedback so far. I would like to confirm whether these reports have reached the appropriate development/security team, or whether there is another preferred channel for reporting security issues. Could you please help confirm the appropriate security reporting process and whether the previous reports have been received? Thank you very much for maintaining the BIRD routing project. Best regards leo [image: Mailsuite] Sender notified with Mailtrack · Opt out <https://u.list-preferences.com/en/privacy/opt-out/unsubscribe/712ab5bc6586d…> 26/07/31 20:46:00

3 2

BIRD 3.3.2, 3.2.3, 3.1.8, 2.19.2, 2.18.3, 2.17.6 released
by Maria Matejka 31 Jul '26

31 Jul '26

Dear BIRD users, we're releasing patch versions for all the supported branches. Downloads are possible at <https://bird.nic.cz/get-bird/> and in our upstream repositories. There are some slightly security-relevant fixes. We have fixed a bunch of bugs. There are still more bugs to fix. The selection of what is fixed has no particular rule. Mostly, somebody in the team just picked up *something* and fixed it. We are fixing: - minor bugs in BGP and some more bugs in our Flowspec parser - processing of routes with recursive nexthops in Pipe and L3VPN in BIRD 3 - handling of passwords with zero bytes in them - several CLI crashes in BIRD 3 - several race conditions and missed corner cases in BIRD 3 If your bug report has been reported as fixed, we would love if you confirmed that from your side. If not, it will most probably get fixed in the next patch release. Officially supported versions are now: - 3.3.x and 2.19.x until 6 months after 3.4.0 and 2.20.0 get released - 3.2.x and 2.18.x until end of November 2026 - LTS 3.1.x and 2.17.x tracking Debian Trixie Also, on commercial note, we offer BIRD Support services, so that you can get help with configuration, priority access to critical bug information and fixes, and better influence the overall development directions. It's the users paying for these services, who keep the development running, so thank you to all who is already doing so! More on that at our website: <https://bird.nic.cz/commercial-services/> Happy routing! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

2 1