- Bird-users - Mailing Lists

BIRD 3.3.1 persist option (proto kernel) not working
by artem＠bonzo.me 31 Jul '26

31 Jul '26

After upgrade 3.2.2 -> 3.3.1 the ability to leave routes is broken. When stop Bird, all routes are removed from the linux kernel. Conf sample: protocol static { ipv4; route 172.16.0.0/12 blackhole; } protocol kernel { persist; scan time 5; learn off; ipv4 { import none; export all; }; }

3 3

Disable Sender Side Loop Protections
by Charles Rumford 20 Jul '26

20 Jul '26

Hello - I ‘m currently building a lab mockup of our network and using Bird the fake routers for the “internet”. A part of this mockup is having two to routers peer into the internet with the same AS and be able to receive the routes from the other. Juniper has this ability with the configuration option “advertise-peer-as”. I have read through the documentation, but can’t seem to find a configuration option to achieve the same thing. Is this possible with Bird? Charles Rumford Principal Infrastructure Architect charlesr(a)summithq.com<mailto:charlesr@summithq.com> O (312) 268-9342 [Summit]<https://www.summithq.com>

2 2

[3.3.1] How to debug excessive memory usage
by Mariusz Gronczewski 18 Jul '26

18 Jul '26

Hi, I've been observing some memory leak (slowly gets to ~30GB across 18 hours then dies to oomkiller, ~500kB/s growth), how can I debug it furter ? # birdc BIRD 3.3.1 ready. bird> show memory BIRD memory usage Effective Overhead Routing tables: 6059.3 MB 564.4 MB Route attributes: 9510.1 MB 565.8 MB Protocols: 22.3 MB 82.9 kB Current config: 60.8 kB 1232.0 B Standby memory: 0.0 B 32.7 MB Total: 15.2 GB 1163.0 MB Active pages: 16.2 GB Kept free pages: 32.7 MB Cold free pages: 194.2 MB Hot page cache depleted while in RCU: 66929 bird> show route count 2098594 of 2098594 routes for 1051498 networks in table master4 0 of 0 routes for 0 networks in table master6 it's relatively simple config with 2 peers like this: protocol bgp ispX { local as 12345; graceful restart; bfd; allow as sets; neighbor 1.2.3.4 as 65432; ipv4 { import table; export table; export filter bgp_ext_out; import filter bgp_ext_in; import keep filtered on; }; # kernel and OSPF }; protocol kernel kcore { kernel table 1002; learn all; ipv4 { export filter core_to_kernel; import filter kernel_to_core; }; }; protocol ospf core { vrf "core"; ecmp; tick 2; ipv4 { import keep filtered on; import filter ospf_core_in; export filter ospf_core_out; }; area 0 { interface "b-swcore.3000" { type pointopoint; }; interface "b-swcore.3011" { type pointopoint; }; interface "b-swcore.3012" { type pointopoint; }; interface "core" { stub; }; }; }; version from current Debian Testing It only started happening once router was enabled (before it was peered but did not push the routes to kernel table), tho it coincided with upgrade from 3.1 to 3.3.1 as I hit different bug there . I have also tried to disable "export/import table", "import keep filtered on" and "allow as sets" just to narrow it down but appears there is no change Regards, Mariusz -- Mariusz Gronczewski (XANi) <xani%2Bbird(a)devrandom.pl> GnuPG: 0xEA8ACE64 https://devrandom.eu

4 11

BIRD Blogpost: ASPA
by Maria Matejka 16 Jul '26

16 Jul '26

Dear BIRD users, after some discussions, we decided to write a blog post about ASPA. You may find and read the blog post here: https://en.blog.nic.cz/2026/07/16/aspa-explainer/ You'll find there: - an explanation how ASPA verification is performed - a link to a vibecoded ASPA simulator where one can try it out and see the partial results - a bunch of operational recommendations by the team As always, we appreciate you using BIRD. If you appreaciate us maintaining BIRD, we'd love to see a contract with you, so that we can safely continue with that. You may also buy some merch: https://bird-daemon.myspreadshop.co.uk/ Have a nice summer, winter, or whatever season you are currently in! -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

6VPE (VPNv6 over IPv4 MPLS): IPv6 route with IPv4 next-hop rejected by kernel — root cause found, patch attached
by Aleš Kopecký 13 Jul '26

13 Jul '26

Hello, While preparing a question about this symptom, I found the root cause and put together a working, tested patch against sysdep/linux/netlink.c. Posting the fix directly rather than just the question, since a patch is more actionable than a symptom report. Happy to open this as a GitLab MR if that's useful — wanted to get feedback from the list / maintainers first, since I'm not fully sure this is the right layer to fix it at. == Environment == BIRD: 3.3.1 (bird3 3.3.1-cznic.1~trixie, Debian 13 test box) Kernel: 6.12.86 (Debian test), production runs Gentoo Role: egress PE, seamless-MPLS BGP L3VPN (AS 197296), IPv4-only underlay (OSPFv2 + BGP-LU), adding IPv6 as 6VPE (RFC 4659) over the IPv4 transport, extended next hop capability enabled on the vpn6 channel, no IPv6 IGP / LDPv6 anywhere in the underlay. == Symptom (unchanged from the original report) == Control plane resolution is complete and correct — BIRD resolves the VPNv6 route recursively via the IPv4 labeled table and builds the correct double MPLS label stack: show route table vpntab6 all 2a02:d280:201::/64 mpls 1207 unicast [proto_bgp_rr] * (100/?) [?] via 172.21.1.1 on lan mpls 24482/16 hostentry: via 100.127.1.26 table master4_lu mpls 16 But kernel export fails for these routes: show route table table_vpn6_overlay 2a02:d280:201::/64 unicast [l3_overlay] ! (80/?) via 172.21.1.1 on lan mpls 24482/16 <bird>: Netlink: Invalid argument (repeated, once per scan cycle) == Root cause == Confirmed by manual reproduction outside BIRD: # ip -6 route add 2a02:d280:300::/40 encap mpls 24481/1033 via inet 172.21.1.1 dev lan table 20 Error: IPv6 does not support RTA_VIA attribute. net/ipv6/route.c in mainline Linux does not accept RTA_VIA (the netlink attribute for a cross-family nexthop) on an IPv6 route, full stop — regardless of whether the address is a raw IPv4 address or an IPv4-mapped IPv6 address. Since our underlay is IPv4-only, every VPNv6 route we import resolves (via the IPv4-labeled IGP table) to a physically IPv4-family adjacency, so every such route hits this kernel limitation. In sysdep/linux/netlink.c, nl_add_nexthop() is exactly where this happens: if (ipa_nonzero(nh->gw)) { if (af == (ipa_is_ip4(nh->gw) ? AF_INET : AF_INET6)) nl_add_attr_ipa(h, bufsize, RTA_GATEWAY, nh->gw); /* same family, OK */ else nl_add_attr_via(h, bufsize, nh->gw); /* cross-family -> rejected for v6 */ } The MPLS encap (nl_add_attr_mpls_encap(), a few lines above) is completely independent of this gateway-family branch — it's already correctly built from the hostentry-resolved label stack before the gateway is even considered. So fixing the gateway encoding does not touch the label stack at all. This looks like the mirror case of RFC 8950 (v4-via-v6, "IPv6 next hop for IPv4 NLRI", which the kernel does support): what we need here is the opposite direction, v6-via-v4, for which the kernel intentionally has no FIB representation. For an MPLS-encapsulated route, though, the gateway is only used to pick the L2 adjacency (the packet leaves as an MPLS frame, so the address family of the nexthop is otherwise irrelevant to forwarding), which means we don't actually need the kernel to support v6-via-v4 in general — we just need *some* valid on-link IPv6 address for that neighbor. == Two things I ruled out first (documenting so nobody re-treads this) == 1. Overriding gw in a kernel export filter (`if ifname = "lan" then gw = fe80::1;`): the route becomes installable, but overriding gw forces BIRD to recompute the nexthop as non-recursive/explicit, which drops the label stack from the hostentry resolution. Installable but non-forwarding. 2. BGP-side "next hop address" / extended-nexthop config changes: these only affect what *we* advertise for routes *we* originate. They have no effect on how imported routes (from the RR, next-hop = remote PE loopback) get resolved — that resolution goes through our IPv4-only IGP table (master4_lu) regardless of how our own next-hop attribute is encoded. Also, disabling extended-nexthop entirely makes BIRD reject the config outright ("Mismatched IGP table type") since it then requires the next-hop family to match the IGP table family. Verified both variants live against production traffic; neither changes the kernel-export outcome. == The patch == Confirmed the neighboring router already sends IPv6 Router Advertisements on the segment (independent of any IPv6 IGP — RA is link-scoped), so the kernel already keeps a working ND cache entry for it: ip -6 neigh show dev lan fe80::1 lladdr dc:68:0c:32:ed:b2 router STALE The attached patch adds a small on-link-router cache to netlink.c (mirrors the existing AF_BRIDGE FDB cache/parsing that's already in the file, just generalized to AF_INET6 neighbors flagged NTF_ROUTER), refreshed once per KRT scan cycle. In nl_add_nexthop(), when exporting an IPv6 route whose resolved gateway is IPv4-family, it looks up this cache by egress interface and substitutes the neighbor's real link-local address for RTA_GATEWAY instead of building the (rejected) RTA_VIA — the MPLS encap is untouched. No interface name or address is hardcoded anywhere; it's fully derived from what the kernel already knows via ND. If the cache has no entry yet for that interface, behavior is unchanged from today (route stays uninstalled, self-heals on the next scan) — no regression. Diff attached: 0001-netlink-ipv6-onlink-router-cache-for-6vpe-mpls-nexthop.diff (against v3.3.1, 4 hunks, all confined to sysdep/linux/netlink.c). == Test results (live, on a production-representative PE) == show route table table_vpn6_overlay -> routes now "*" (were "!") ip -6 route show table 20 2a02:d280:201::/64 encap mpls 24482/16 via fe80::1 dev lan proto bird ip -6 route get 2a02:d280:200::1 ... encap mpls 24481/1032 via fe80::1 dev lan ... (correct FIB lookup) ip -6 neigh show dev lan fe80::1 lladdr dc:68:0c:32:ed:b2 router REACHABLE journalctl -u bird -> no more "Netlink: Invalid argument" End-to-end ping from a live CPE through the fixed path: 171/171 received, 0% loss. == Questions for the list / maintainers == 1. Is this an acceptable place/approach to fix this, or would you rather see it handled differently (e.g. in rt-table.c nexthop resolution itself, or as an explicit config knob rather than automatic ND-based discovery)? 2. Known edge case: if a segment ever has more than one NTF_ROUTER neighbor on the same interface, the cache currently keeps whichever one was last seen in the dump (non-deterministic ordering). Not an issue in our topology (always exactly one router per segment), but worth flagging. 3. Cache refresh is tied to the existing KRT scan interval rather than the async netlink notification path, to avoid touching the shared AF_BRIDGE dispatch code. Happy to change this if an event-driven refresh is preferred upstream. Willing to open this as a merge request, test further, or provide more captures/config context — just let me know the preferred path. Thanks a lot for BIRD. Aleš Kopecký AS 197296 ales.kopecky(a)u-n.cz Attachments: 0001-netlink-ipv6-onlink-router-cache-for-6vpe-mpls-nexthop.diff

2 2

HTML archive of bird-users not generating
by Lars Gierth 13 Jul '26

13 Jul '26

Hi, I noticed the HTML archive at https://bird.network.cz/pipermail/bird-users/2026-June/subject.html hasn't been regenerating since ~1 month ago. Last message there is from Thu Jun 11 17:43:35 CEST 2026 Cheers, Lars

2 1

Fwd: [Battlemesh] Battlemesh v18 Announcement
by Linus Lüssing 12 Jul '26

12 Jul '26

Hi, I hope it's not rude forwarding emails to this ML / advertising as a first post. But I thought maybe some people here could be interested in this event. Regards, Linus ----- Forwarded message from "Chester A. Unal via Battlemesh" <battlemesh(a)ml.ninux.org> ----- Date: Mon, 1 Jun 2026 06:51:02 +0000 (UTC) From: "Chester A. Unal via Battlemesh" <battlemesh(a)ml.ninux.org> To: battlemesh(a)ml.ninux.org Cc: "Chester A. Unal" <chester.a.unal(a)arinc9.com> Subject: [Battlemesh] Battlemesh v18 Announcement Hello everyone! We're announcing the 18th edition of the Wireless Battle of the Mesh! Date: 7-13 September 2026, 7 days Venue: Pueblo Escondido at Gornji Karin, Croatia Battlemesh features a variety of talks and workshops on technical and political issues related to mesh networking, wireless community networks and OpenWrt firmware development. The purpose of the event is to further topics such as right to connectivity, community-owned infrastructure and related free open source projects. The event is free of charge and open for all. Registering: Add yourself to the participants list. If you'd rather not have your name there, please send an email to the organisation team with the same information displayed on the participants list. https://www.battlemesh.org/BattleMeshV18/Participants Accomodation: The event space allows for camping on site either in your own tent or camper vans. The charge is 15 EUR per night per person. For those preferring indoor accommodation, numerous small hotels and/or privately owned apartments are available in the near vicinity. Booking can be arranged individually or via recommendation by the Karin team. More information: https://www.battlemesh.org/BattleMeshV18 Please help us spread the word by sharing this announcement. Battlemesh v18 Organisers _______________________________________________ Battlemesh mailing list Battlemesh(a)ml.ninux.org https://ml.ninux.org/mailman/listinfo/battlemesh ----- End forwarded message -----

1 0

And AI-based bug hunters have arrived at BIRD
by Douglas Fischer 10 Jul '26

10 Jul '26

This has become a common occurrence across various open-source projects. It seems like there’s a massive investment in tokens—a desperate scramble to find any opening to shoehorn a patch into the codebase, just to post about it on LinkedIn. I’ve seen a range of attitudes toward this: from code maintainers fully embracing it (which is actually a bit unsettling) to outright blocking anything AI-generated (sometimes discarding potentially interesting contributions in the process). I think the best suggestion I’ve seen is a middle-ground approach. Projects could build the necessary infrastructure internally to support AI-driven activities, treating them as native to the project rather than the work of an external entity simply scouring for opportunities. This would allow interested individuals to contribute their tokens to run whatever tests they deem appropriate. I don't believe the current volume justifies the effort. But once it starts to become excessive, that idea might be worth considering. -- Douglas Fernando Fischer Engº de Controle e Automação

2 1

BGP AGGREGATOR / AS4_AGGREGATOR with AS=0 is accepted and may be propagated
by xinzhe liu 09 Jul '26

09 Jul '26

Hello BIRD maintainers, I would like to report a possible issue in BIRD. ### Summary BIRD appears to accept a BGP UPDATE containing `AS4_AGGREGATOR` with AS number 0 from a non-AS4 peer. When the same UPDATE also contains `AGGREGATOR` with `AS_TRANS`, BIRD's AS4 transition processing converts the `AS4_AGGREGATOR` value into the effective `AGGREGATOR` attribute. In dynamic testing, BIRD installed the route with: ```text BGP.aggregator: 192.0.2.9 AS0 ``` and then exported the route to a downstream non-AS4 peer with: ```text AGGREGATOR flags=0xc0 as=0 addr=192.0.2.9 ``` I am reporting this as an RFC 7607 conformance / input-validation issue, not as a high-impact security vulnerability. ### Expected Behavior RFC 7607 Section 2 says that a BGP speaker MUST NOT originate or propagate a route with AS number zero in the `AS_PATH`, `AS4_PATH`, `AGGREGATOR`, or `AS4_AGGREGATOR` attributes. An UPDATE containing AS 0 in `AS4_AGGREGATOR` should cause the `AS4_AGGREGATOR` attribute to be considered malformed under RFC 7607 and handled according to RFC 6793. In other words, the attribute should be discarded and the UPDATE may continue to be processed. However, the `AS4_AGGREGATOR` value must not become the effective `AGGREGATOR` attribute, and BIRD must not install or export the route with `AGGREGATOR AS=0`. ### Actual Behavior BIRD continues processing the UPDATE, but the malformed `AS4_AGGREGATOR` value becomes the effective `AGGREGATOR` attribute. The route is installed with `BGP.aggregator: 192.0.2.9 AS0`, and BIRD exports an `AGGREGATOR` attribute whose AS field is 0. ### Steps to Reproduce 1. Start BIRD with a dynamic BGP listener: ```bird router id 127.0.0.1; protocol device { } protocol bgp as4agg_as0 { local 127.0.0.1 port 11918 as 65001; neighbor range 127.0.0.0/8 external; dynamic name "poc"; multihop; ipv4 { import all; export all; }; } ``` 2. Connect an upstream peer from `127.0.0.2`, AS 65002, without advertising AS4 capability. 3. Send an UPDATE for `203.0.113.0/24` containing: ```text ORIGIN = IGP AS_PATH = 65002 NEXT_HOP = 127.0.0.2 AGGREGATOR = AS_TRANS / 192.0.2.9 AS4_AGGREGATOR = AS 0 / 192.0.2.9 ``` 4. Query the local RIB: ```text birdc show route 203.0.113.0/24 all ``` 5. Connect a downstream peer from `127.0.0.3`, AS 65003, also without AS4 capability, and inspect the UPDATE exported by BIRD. ### Dynamic Verification This was reproduced against: ```text BIRD version 2.19.0+branch.master.880200b1f94c ``` Local RIB: ```text 203.0.113.0/24 unreachable [poc1 ... from 127.0.0.2] * (100) [AS65002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 65002 BGP.next_hop: 127.0.0.2 BGP.local_pref: 100 BGP.aggregator: 192.0.2.9 AS0 ``` Downstream export: ```text [+] Exported AGGREGATOR flags=0xc0 as=0 addr=192.0.2.9 VERDICT: NON_COMPLIANT_REPRODUCED_ACCEPTED_AND_PROPAGATED ``` ### Source Analysis `AS4_AGGREGATOR` decoding checks whether the session is already AS4-capable and whether the attribute length is 8, but it does not check whether the AS field is 0: ```c static void bgp_decode_as4_aggregator(...) { if (s->as4_session) DISCARD(NEW_BGP, "AS4_AGGREGATOR"); if (len != 8) DISCARD(BAD_LENGTH, "AS4_AGGREGATOR", len); bgp_set_attr_data(to, s->pool, BA_AS4_AGGREGATOR, flags, data, len); } ``` During AS4 transition processing, if both `AGGREGATOR` and `AS4_AGGREGATOR` are present and `AGGREGATOR` has `AS_TRANS`, BIRD uses `AS4_AGGREGATOR` as the effective `AGGREGATOR`: ```c if (a2 && a4) { u32 a2_asn = get_u32(a2->u.ptr->data); if (a2_asn != AS_TRANS) return; /* Use AS4_AGGREGATOR instead of AGGREGATOR */ a2->u.ptr = a4->u.ptr; } ``` There appears to be no AS 0 validation on either `AGGREGATOR` or `AS4_AGGREGATOR`. ### Comparison FRR checks AS 0 for both `AGGREGATOR` and `AS4_AGGREGATOR`. If the AS is 0, FRR logs the condition and does not mark the attribute as present for propagation. ### Impact The practical impact is interoperability and malformed route propagation. BIRD may propagate a route with invalid AS 0 aggregator metadata, which can cause downstream implementations with stricter RFC 7607 handling to reject, withdraw, or otherwise handle the route inconsistently. This does not directly imply route hijacking. `AGGREGATOR` is not the primary AS loop detection input; `AS_PATH` and `AS4_PATH` are. ### Suggested Fix Direction Add AS 0 validation for `AGGREGATOR` and `AS4_AGGREGATOR` during decode or before AS4 transition reconstruction. In particular, an `AS4_AGGREGATOR` whose first four bytes decode to ASN 0 should not be allowed to become the effective `AGGREGATOR` attribute or be propagated downstream.

2 1

OSPFv2: PtP stub interface
by Lexi Winter 09 Jul '26

09 Jul '26

hello, i'm using BIRD 3.2.0 on FreeBSD 15.0. i have a PPPoE interface with a point-to-point IPv4 address configured: ng0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=0 inet 81.187.73.117 --> 81.187.81.187/32 inet6 2001:8b0:aab5:1::1/128 inet6 fe80::227c:14ff:fef3:d8f7%ng0/64 scopeid 0x12 groups: arpa nd6 options=1<PERFORMNUD> i would like to advertise this in OSPF as a passive interface, so i configured the OSPF protocol: define OSPF_V6_EXPORT = [ ]; define OSPF_V4_EXPORT = [ 0.0.0.0/0 ]; filter ospf_export { if (net ~ OSPF_V6_EXPORT) then accept; if (net ~ OSPF_V4_EXPORT) then accept; reject; }; protocol ospf v2 core4 { ipv4 { export filter ospf_export; import all; }; area 0 { interface "ng0" { stub yes; }; [... other config elided ...] }; } however, BIRD does not advertise 81.187.73.117/32 in OSPF. it *does* advertise 81.187.81.187/32, which is the remote side of the interface. the interface looks fine in BIRD: bird> show ospf interface "ng0" core6: core4: Interface ng0 (peer 81.187.81.187) Type: ptp Area: 0.0.0.0 (0) State: PtP (stub) Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 the route: bird> show route for 81.187.73.117/32 Table master4: 0.0.0.0/0 unicast [kernel4 2026-07-04] ! (10) via 81.187.81.187 on ng0 81.187.73.117/32 unicast [kernel4 2026-07-04] ! (10) dev lo0 if i add 81.187.73.117/32 to OSPF_V4_EXPORT, then it is correctly advertised as an E2 route, which is fine as a workaround, but i would like to understand why the interface configuration doesn't work.

3 5