- Bird-users - Mailing Lists

Suppressing "Malformed AS_PATH attribute" and "Invalid route ... withdrawn"?
by Robert Scheck 02 Jun '26

02 Jun '26

Hello all, after updating a system to BIRD 3.x, I see lots of such log messages: Jun 02 11:52:34 bird[2664336]: transit6: Malformed AS_PATH attribute - AS_SET segment (1) at 26 Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7453::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7426::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7444::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7435::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:12a:7425::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Invalid route 2608:14a:7523::/48 withdrawn Jun 02 11:52:34 bird[2664336]: transit6: Malformed AS_PATH attribute - AS_SET segment (1) at 14 As I personally less care about the invalid routes the US DoD (and others) push into the DFZ, I would like to suppress them (~ 26k log lines within 8 hours) - while still keeping regular BIRD warnings, errors etc. Maybe I'm overlooking something, but based on the documentation I did not see how I could suppress just "Malformed AS_PATH attribute" and "Invalid route ... withdrawn" log messages? Any pointers? Thank you. Regards, Robert

2 1

misleading documentation for the "direct" protocol
by Lexi Winter 02 Jun '26

02 Jun '26

hello, the BIRD documentation says for the "direct" protocol[0]: > The question is whether it is a good idea to have such device routes > in BIRD routing table. OS kernel usually handles device routes for > directly connected networks by itself so we don't need (and don't > want) to export these routes to the kernel protocol. OSPF protocol > creates device routes for its interfaces itself and BGP protocol is > usually used for exporting aggregate routes. But the Direct protocol > is necessary for distance-vector protocols like RIP or Babel to > announce local networks. [0] https://bird.network.cz/?get_doc&v=30&f=bird-6.html#ss6.7 as i read this, it is suggesting that if BIRD is only running OSPF, then the "direct" protocol is not needed. however, i've tested this and i'm not sure it's true. without direct, and with a basic OSPF configuration with no peers, BIRD will flag the OSPF interface routes with '!': root@witch:/usr/local/etc # birdc show route BIRD 3.2.0 ready. Table master4: 81.2.96.160/28 unicast [core4 22:45:00.630] ! I (150/10) [198.18.2.4] dev genet0 Table master6: 2001:8b0:aab5:c401::/64 unicast [core6 22:45:00.630] ! I (150/10) [198.18.2.4] dev genet0 it will also log very much some netlink errors: May 31 22:51:04 witch bird[31390]: Netlink: File exists May 31 22:51:04 witch syslogd: last message repeated 1 times May 31 22:52:04 witch bird[31390]: Netlink: Address already in use May 31 22:52:04 witch bird[31390]: Netlink: File exists May 31 22:52:04 witch syslogd: last message repeated 1 times after configuring BIRD with: protocol direct { ipv4; ipv6; }; the OSPF interface routes are correctly installed (or rather, not installed, since the kernel already installed them): root@witch:/usr/local/etc # birdc show route BIRD 3.2.0 ready. Table master4: 81.2.96.160/28 unicast [direct1 22:53:29.436] * (240) dev genet0 unicast [core4 22:53:29.529] I (150/10) [198.18.2.4] dev genet0 Table master6: 2001:8b0:aab5:c401::/64 unicast [direct1 22:53:29.436] * (240) dev genet0 unicast [core6 22:53:29.529] I (150/10) [198.18.2.4] dev genet0 and BIRD does not log anymore the netlink-related errors. i tested this on FreeBSD 15.0, so possibly this is a FreeBSD-specific behaviour that isn't present on Linux; i don't have any Linux systems to test with. but, i think the documentation of the "direct" protocol could be changed to indicate that configuring it may be necessary in at least some situations.

2 2

bird_exporter: Inconsistent state label for BIRD 2 BGP protocol with multiple AF channels
by Mikhail Mayorov 01 Jun '26

01 Jun '26

Hello. This is not directly related to BIRD itself. BIRD appears to work correctly in this case. The question is about how |bird_exporter|exposes metrics for a BIRD 2 BGP protocol with multiple address-family channels. I am using |bird_exporter| with BIRD 2 and noticed confusing behavior when a single BGP protocol has more than one address-family channel enabled, for example both |ipv4| and |ipv6|. Versions: |bird_exporter: 1.5.0 BIRD: 2.19.0 | Exporter is started like this: |bird_exporter \ -web.listen-address=localhost:9325 \ -bird.v2 \ -bird.socket=/path/to/bird.ctl | BIRD shows one established BGP session with both IPv4 and IPv6 channels up: |Name Proto State Info example_peer BGP up Established BGP state: Established Neighbor address: 2001:db8::1 Source address: 2001:db8::2 Local capabilities: Multiprotocol AF announced: ipv4 ipv6 Neighbor capabilities: Multiprotocol AF announced: ipv4 ipv6 Channel ipv4 State: UP Table: master4 Routes: 10 imported, 0 filtered, 6000 exported, 10 preferred Channel ipv6 State: UP Table: master6 Routes: 0 imported, 0 filtered, 200 exported, 0 preferred | Actual |bird_exporter| output: |bird_protocol_up{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP",state="Established"} 1 bird_protocol_up{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP",state=""} 1 bird_protocol_uptime{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP"} 397 bird_protocol_uptime{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP"} 397 bird_protocol_prefix_export_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP"} 6000 bird_protocol_prefix_export_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP"} 200 bird_protocol_prefix_import_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP"} 10 bird_protocol_prefix_import_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP"} 0 bird_protocol_prefix_preferred_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="4",name="example_peer",proto="BGP"} 10 bird_protocol_prefix_preferred_count{export_filter="(unnamed)",import_filter="(unnamed)",ip_version="6",name="example_peer",proto="BGP"} 0 | The important part is that both |ip_version="4"| and |ip_version="6"| are exported for the same BGP protocol, but only one series has the BGP FSM state: |bird_protocol_up{ip_version="4",name="example_peer",proto="BGP",state="Established"} 1 bird_protocol_up{ip_version="6",name="example_peer",proto="BGP",state=""} 1 | The IPv6 series has |state=""|, although the BGP protocol is established and the IPv6 channel is UP. Expected behavior: Either |state="Established"| should be present on all |bird_protocol_up| series generated from the same established BGP protocol: |bird_protocol_up{ip_version="4",name="example_peer",proto="BGP",state="Established"} 1 bird_protocol_up{ip_version="6",name="example_peer",proto="BGP",state="Established"} 1 | or |state| should not be attached to per-AF |bird_protocol_up| series at all, and a separate protocol-level metric should expose the BGP FSM state. The current behavior is confusing for monitoring systems, because the same BGP protocol appears as partly established and partly without state, although both address-family channels are UP. It would also be useful to distinguish clearly between: * protocol/session state, for example |BGP state: Established|; * channel state, for example |Channel ipv4: UP|, |Channel ipv6: UP|; * address-family label, currently exposed as |ip_version|. A cleaner model could be something like: |bird_protocol_up{name="example_peer",proto="BGP",state="Established"} 1 bird_protocol_channel_up{name="example_peer",proto="BGP",channel="ipv4"} 1 bird_protocol_channel_up{name="example_peer",proto="BGP",channel="ipv6"} 1 | This would avoid ambiguity when one BIRD 2 protocol serves multiple address families. Thank you.

1 0

Setting bgp_next_hop in EVPN resets VNI
by André Grüneberg 28 May '26

28 May '26

Hi all, Yesterday I was partying that I was able to inject static MAC-IP routes into EVPN on Bird 3.3.0 with the correct VNI using the mpls_label attribute. The joy was disturbed today, when I tried to set a different bgp_next_hop than the local host. As soon as I set the bgp_next_hop this forces the VNI/mpls_label to be encoded as 0. While the local export table shows the configured mpls_label, the remote side receives VNI=0. >From reading the code, I suspect that https://gitlab.nic.cz/labs/bird/-/blob/v3.3.0/proto/bgp/packets.c#L1321 is triggering this behaviour. I have no real clue how to get values into nhloc->labels (statically). I found a workaround in explicitly setting next hop address in the BGP protocol's evpn channel. Yet my expectation would be that explicitly setting bgp_next_hop does not have any influence on treating the VNI/mpls_label. Abbreviated config: evpn table t_evpn; protocol static { evpn { table t_evpn; }; route evpn mac 172.25.110.202:100 0 c0:12:34:56:78:9a 2001:db8::1 drop; } filter export_evpn { if ( net.evpn_type = NET_EVPN_MAC ) then { bgp_ext_community.add((generic, 0x30c0000, 0x8)); bgp_ext_community.add((rt, 10, my_vlan)); bgp_ext_community.add((generic, 0x6000000, 0x0)); mpls_label = 100100; bgp_next_hop = 10.49.0.0; } accept; } protocol bgp core01 { local as my_asn; evpn { table t_evpn; import none; export filter export_evpn; next hop address 10.49.0.0; }; neighbor 172.25.110.201 as my_asn; } With this configuration the VNI in outbound UPDATE is set to 0. Without bgp_next_hop in the filter the BGP UPDATE contains VNI 100100. Best wishes, André -- André Grüneberg, Managing Director andre.grueneberg(a)bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B

2 2

EVPN static IMET route on Bird 3.3.0
by André Grüneberg 28 May '26

28 May '26

Hi bird users, I am currently experimenting with Bird 3.3.0 and EVPN. I do not need/want a local termination, but want to inject static EVPN routes only. Despite missing documentation (hint!), I found the necessary syntax to define mac-ip and imet routes. I also managed to manually set the required ext communities (tunnel type, MAC mobility, RT) as well as the VNI (mpls_label) in the filter. What remains open is the bgp_pmsi_tunnel attribute. According to the documentation it's not available in filters. Is there any alternative way to statically set it? Maybe a custom attribute and a binary string? Thanks, André -- André Grüneberg, Managing Director andre.grueneberg(a)bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B

3 5

[PATCH v2 0/4] Modernize Netlink code
by Asbjørn Sloth Tønnesen 27 May '26

27 May '26

These patches tweaks the netlink code, bringing it closer to best practice. Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- v2: - Rework patch 4 to handle conflict with commit e3ee1a97f2c6 ("Bridge: Linux bridge interface - preliminary support") v1: https://trubka.network.cz/pipermail/bird-users/2026-February/018618.html Asbjørn Sloth Tønnesen (4): Netlink: Enable strict checking on nl_req Netlink: Skip request payload in acknowledgements Netlink: Enable and decode extended acknowledgements Netlink: Skip stats in device dumps sysdep/linux/netlink.c | 101 ++++++++++++++++++++++++++++++++--------- 1 file changed, 79 insertions(+), 22 deletions(-) base-commit: 1d7f3e564e257d4fd345129b26af4dd9a1dd8bb1 -- 2.53.0

3 3

BIRD 3.3.0 and 2.19.0 released
by Maria Matejka 25 May '26

25 May '26

Dear BIRD users, we are releasing BIRD versions 3.3.0 and 2.19.0. Both versions include all relevant fixes applied in versions 3.2.1, 3.1.6, 2.18.1 and 2.17.4. Downloads are possible at <https://bird.nic.cz/get-bird/> and in our upstream repositories. We have merged BGP autospawn based on received router advertisements. Also, we changed the disabled BGP protocol behavior in 3.3.0 to align with BIRD 2, so that disabled protocol actively blocks incoming connections for that peer. These versions contain BGP/EVPN/VXLAN support. Please check, and if you find anything weird, please tell us. We also did an EVPN tutorial at RIPE 92: <https://ripe92.ripe.net/programme/meeting-plan/sessions/59/7JB8K9/> We have reworked BGP export tables in BIRD 3, so that they eat significantly less memory. We have fixed `show route for` in BIRD 3 to do the longest prefix match again. There are also some more minor changes and fixes. There are some outstanding bugs (in all versions) reported, and we're working on fixing them. Some of these involve crashes in corner cases, and therefore, in filters, we recommend to sanity-check lengths of the data you are working with before running more complex operations. This applies mostly to community lists and bgp paths, and it's a good practice anyway to drop routes with enormously long paths or community lists. Officially supported versions are now: - 3.3.0 and 2.19.0 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, so that you can get help with configuration, priority access to critical bug fixes, and better influence the overall development directions. It's the users paying for these services, who keep the development running. 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.

1 0

Custom thread group for BFD causes error - <FATAL> Express thread group not configured and "express" not found
by Justin Cattle 21 May '26

21 May '26

Hi, I've been testing migrating to bird3. I preferred to redefine the default threading configs so that everything is explicit, rather than implicit. But, when I defined the ¬eress" group, I got the following warning logged: <WARN> Symbol 'express' overrides existing keyword Rather than create create needless log lines, I though I would fix that by creating my own custom thread group instead, and use that for BFD. I created: thread group responsive { threads 1; max latency 10 ms; min time 1 ms; max time 10 ms; wakeup time 60 s; } protocol bfd { thread group responsive; interface "net0" { interval 1000 ms; multiplier 4; }; interface "net1" { interval 1000 ms; multiplier 4; }; } However, the config validation then throws the following error: <FATAL> Express thread group not configured and "express" not found Is this a bug, or something I'm doing wrong ? Thanks! Cheers, Just -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. Ocado Polska Sp. z o.o. posiada status dużego przedsiębiorcy w rozumieniu ustawy o przeciwdziałaniu nadmiernym opóźnieniom w transakcjach handlowych. / Ocado Polska Sp. z o.o. holds the status of a large enterprise under the Act on Counteracting Excessive Delays in Commercial Transactions.

2 5

[PATCH v2 4/4] Netlink: Skip stats in device dumps
by Asbjørn Sloth Tønnesen 18 May '26

18 May '26

Gathering interface statistics can be a relatively expensive operation on certain systems as it requires iterating over all the cpus. This patch instructs the kernel to omit device statistics, when scanning devices, as the statistics aren't used by BIRD. Kernel-side support for this was added in Linux v4.4 in commit d5566fd72ec1 ("rtnetlink: RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats"), this saves 368 bytes of statistics. In the Linux v6.19 commit 105bae321862 ("rtnetlink: honor RTEXT_FILTER_SKIP_STATS in IFLA_STATS"), it is expanded to skip more statistics bringing the savings to 800 bytes per device. Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 02efa0f6d..5b437b0e6 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -1412,7 +1412,7 @@ kif_do_scan(struct kif_proto *p UNUSED) if_start_update(); - nl_request_dump_link(AF_UNSPEC, 0); + nl_request_dump_link(AF_UNSPEC, RTEXT_FILTER_SKIP_STATS); while (h = nl_get_scan()) if (h->nlmsg_type == RTM_NEWLINK || h->nlmsg_type == RTM_DELLINK) nl_parse_link(h, 1); @@ -2557,7 +2557,8 @@ kbr_do_vlan_scan(struct kbr_proto *p) struct nlmsghdr *h; - nl_request_dump_link(AF_BRIDGE, RTEXT_FILTER_BRVLAN); + nl_request_dump_link(AF_BRIDGE, RTEXT_FILTER_BRVLAN | + RTEXT_FILTER_SKIP_STATS); while (h = nl_get_scan()) { if (h->nlmsg_type == RTM_NEWLINK || h->nlmsg_type == RTM_DELLINK) -- 2.53.0

1 0

[PATCH v2 2/4] Netlink: Skip request payload in acknowledgements
by Asbjørn Sloth Tønnesen 18 May '26

18 May '26

Set NETLINK_CAP_ACK, as we don't need a full copy of the request payload, so it's "rather wasteful"[1] to not set NETLINK_CAP_ACK. We don't check the return value of setsockopt(), as any capped message will have NLM_F_CAPPED set in nlmsg_flags. NETLINK_CAP_ACK was introduced in Linux v4.3 commit 0a6a3a23ea6e ("netlink: add NETLINK_CAP_ACK socket option"), and so AFAICT it doesn't need to be added to netlink-sys.h. [1] https://docs.kernel.org/userspace-api/netlink/intro.html Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 9c519adb6..68f075fc0 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -70,6 +70,14 @@ static linpool *nl_linpool; static struct nl_sock nl_scan = {.fd = -1}; /* Netlink socket for synchronous scan */ static struct nl_sock nl_req = {.fd = -1}; /* Netlink socket for requests */ +static void +nl_set_cap_ack(struct nl_sock *nl UNUSED, int val UNUSED) +{ +#ifdef SOL_NETLINK + setsockopt(nl->fd, SOL_NETLINK, NETLINK_CAP_ACK, &val, sizeof(val)); +#endif +} + static void nl_open_sock(struct nl_sock *nl) { @@ -82,6 +90,8 @@ nl_open_sock(struct nl_sock *nl) nl->rx_buffer = xmalloc(NL_RX_SIZE); nl->last_hdr = NULL; nl->last_size = 0; + + nl_set_cap_ack(nl, 1); } } -- 2.53.0

1 0