June 2026 - 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