- Bird-users - Mailing Lists

bird 2.17 on NetBSD and directly connected networks
by Mark Davies 24 Apr '25

24 Apr '25

I've just replaced an archlinux system running 2.14 with a NetBSD system running 2.17. Everything seems to be working fine except that every 20 seconds it complains: KRT: Error sending route XX.XX.XX.XX/XX to kernel: File exists for each directly connected network. ie it tries to write the directly connected network entries out to the kernel routing socket and gets told they already exist. Whats going wrong here? Should it have determined that they are directly connected and not try to write them out or is it expecting the write shouldn't fail or what? cheers mark

2 1

Bird 3.1.0 tarball missing version info
by Svenne Krap 24 Apr '25

24 Apr '25

Hi all, I stumbled over, that Bird 3.1.0 in Arch Linux is missing all version information. Having peeked at the PKGBUILD it seems to do nothing weird, so I have reproduced it by hand. Steps: $ wget <https://gitlab.nic.cz/labs/bird/-/archive/v3.1.0/bird-v3.1.0.tar.gz> $ tar axvf bird-v3.1.0.tar.gz $ cd bird-v3.1.0 $ autoreconf -vif $ ./configure $ make $ ./bird --version The latter shows (like "show status" on the real Arch package) BIRD version +detached. It seems like the error is in tools/version, that only works in a git repo. The following patch is a suggestion for a fix --- ../bird-v3.1.0-failed/tools/version 2025-04-03 20:39:22.000000000 +0200 +++ tools/version 2025-04-24 11:02:58.276023973 +0200 @@ -1,5 +1,12 @@ #!/bin/bash +# Are we in a release tarball? +git status >& /dev/null +if [ $? -eq 128 ]; then + realpath . | awk -F/ '{print $NF}' | cut -dv -f 2 + exit 0 +fi + # Aren't we directly at version? TAG=$(git tag | grep -F $(git describe))if [ -n "$TAG" ]; then Otherwise, the Arch package seems to work fine. Regards, Svenne

2 2

BIRD 2.17 crash on Debian 12 / kernel 6.1.0-33 apparently related to TCP-AO ocde
by Radu-Adrian Feurdean 22 Apr '25

22 Apr '25

Hello, Just found this morning a condition that crashes BIRD 2.17 (nic.cz <http://nic.cz/> .deb version for Debian 12) on today’s up-to-date Deb12. The issue seems to be related to the TCP-AO code. GDB tells me this: (gdb) bt full #0 0x0000556005dcd7f0 in bgp_incoming_connection (sk=0x55603a779860, dummy=<optimized out>) at proto/bgp/bgp.c:1705 p = 0x55603a79c750 acc = <optimized out> hops = <optimized out> #1 0x0000556005e04e61 in sk_passive_connected (s=0x55603a7c5aa0, type=type@entry=2) at sysdep/unix/io.c:1337 loc_sa = {sa = {sa_family = 2, sa_data = "\000\263\271\001\220\001\000\000\000\000\000\000\000"}, padding = "\005\030\020\000\000y{\\ \000\000\000\314Q\000"} rem_sa = {sa = {sa_family = 2, sa_data = "\215-\271\001\220\022\000\000\000\000\000\000\000"}, padding = "\000\000\000\000\000\000\000\000\000+ \"\257\371", <incomplete sequence \354\270>} loc_sa_len = 16 rem_sa_len = 16 fd = 27 t = 0x55603a779860 #2 0x0000556005e05ce2 in sk_read_noflush (revents=<optimized out>, s=0x55603a7c5aa0) at sysdep/unix/io.c:2105 No locals. #3 sk_read (s=s@entry=0x55603a7c5aa0, revents=<optimized out>) at sysdep/unix/io.c:2165 e = <optimized out> #4 0x0000556005e06907 in io_loop () at sysdep/unix/io.c:2626 s = 0x55603a7c5aa0 count = 3 poll_tout = <optimized out> timeout = <optimized out> nfds = <optimized out> events = <optimized out> pout = <optimized out> t = <optimized out> s = <optimized out> n = <optimized out> fdmax = 256 pfd = 0x55603a7c5190 next = <optimized out> next2 = <optimized out> #5 0x0000556005d550df in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:1089 use_uid = <optimized out> use_gid = <optimized out> conf = 0x7fa680793010 Please let mw know how should I send you a coredump (I actually have 2), if needed. I have also identified the pice of config that turns on the behaviour. 2.16.2 seems to be fine, which is kind of normal, since the piece of code pointed to by gdb is not there in 2.16.2. Regards, -- Radu-Adrian FEURDEAN Web : www.franceix.net

2 1

[PATCH] sysdep/linux: fix IPv4-via-IPv6 with disabled MPLS kernel
by Fabian Bläse 22 Apr '25

22 Apr '25

When support for IPv4-via-IPv6 was added, the MPLS functions for adding the RTA_VIA attribute were reused. However, instead of moving nl_add_attr_via() out of the HAVE_MPLS_KERNEL ifdep block, the IPv4-via-IPv6 feature was added into a HAVE_MPLS_KERNEL block, despite being a distinct non-MPLS feature. This leads to netlink errors when IPv4-via-IPv6 routes are installed, because the IPv6 VIA is added to a RTA_GATEWAY attribute. The RTA_GATEWAY attribute does not support IPv4-via-IPv6 resulting in an invalid length error. Move the nl_add_attr_via() function and calls to it out of the HAVE_MPLS_KERNEL blocks and merge duplicate code into a single if-else distinction. Fixes: 53401bef63013dfee01b65d071ffbd88e457539f Signed-off-by: Fabian Bläse <fabian(a)blaese.de> --- sysdep/linux/netlink.c | 44 +++++++++++++++++++----------------------- 1 file changed, 20 insertions(+), 24 deletions(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 299f132f..18af6014 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -601,25 +601,6 @@ nl_add_attr_ipa(struct nlmsghdr *h, uint bufsize, int code, ip_addr ipa) nl_add_attr_ip6(h, bufsize, code, ipa_to_ip6(ipa)); } -#ifdef HAVE_MPLS_KERNEL -static inline void -nl_add_attr_mpls(struct nlmsghdr *h, uint bufsize, int code, int len, u32 *stack) -{ - char buf[len*4]; - mpls_put(buf, len, stack); - nl_add_attr(h, bufsize, code, buf, len*4); -} - -static inline void -nl_add_attr_mpls_encap(struct nlmsghdr *h, uint bufsize, int len, u32 *stack) -{ - nl_add_attr_u16(h, bufsize, RTA_ENCAP_TYPE, LWTUNNEL_ENCAP_MPLS); - - struct rtattr *nest = nl_open_attr(h, bufsize, RTA_ENCAP); - nl_add_attr_mpls(h, bufsize, RTA_DST, len, stack); - nl_close_attr(h, nest); -} - static inline void nl_add_attr_via(struct nlmsghdr *h, uint bufsize, ip_addr ipa) { @@ -638,6 +619,25 @@ nl_add_attr_via(struct nlmsghdr *h, uint bufsize, ip_addr ipa) nl_add_attr(h, bufsize, RTA_VIA, via, sizeof(struct rtvia) + 16); } } + +#ifdef HAVE_MPLS_KERNEL +static inline void +nl_add_attr_mpls(struct nlmsghdr *h, uint bufsize, int code, int len, u32 *stack) +{ + char buf[len*4]; + mpls_put(buf, len, stack); + nl_add_attr(h, bufsize, code, buf, len*4); +} + +static inline void +nl_add_attr_mpls_encap(struct nlmsghdr *h, uint bufsize, int len, u32 *stack) +{ + nl_add_attr_u16(h, bufsize, RTA_ENCAP_TYPE, LWTUNNEL_ENCAP_MPLS); + + struct rtattr *nest = nl_open_attr(h, bufsize, RTA_ENCAP); + nl_add_attr_mpls(h, bufsize, RTA_DST, len, stack); + nl_close_attr(h, nest); +} #endif static inline struct rtnexthop * @@ -669,6 +669,7 @@ nl_add_nexthop(struct nlmsghdr *h, uint bufsize, struct nexthop *nh, int af UNUS nl_add_attr_mpls(h, bufsize, RTA_NEWDST, nh->labels, nh->label); else nl_add_attr_mpls_encap(h, bufsize, nh->labels, nh->label); +#endif if (ipa_nonzero(nh->gw)) { @@ -677,11 +678,6 @@ nl_add_nexthop(struct nlmsghdr *h, uint bufsize, struct nexthop *nh, int af UNUS else nl_add_attr_via(h, bufsize, nh->gw); } -#else - - if (ipa_nonzero(nh->gw)) - nl_add_attr_ipa(h, bufsize, RTA_GATEWAY, nh->gw); -#endif } static void -- 2.49.0

1 0

ASPA result when ASPA table is empty? (disconnected or 0 entries supplied)
by Jeroen Massar 15 Apr '25

15 Apr '25

Hi, I was checking the ASPA possibilities, and the is_upstream option of aspa_check definitely is confusing. The downstream/upstream variant also, as the logic seems reverse to what one would expect. A better example would be rather welcome, though, I think I have it correct now with details from the list. It would also be useful if we could do something like we can do for RPKI: print roa_check(rpki4, 84.205.83.0/24, 12654) = ROA_UNKNOWN; print roa_check(rpki4, 93.175.146.0/24, 12654) = ROA_VALID; print roa_check(rpki4, 93.175.147.0/24, 12654) = ROA_INVALID; and that we could run a similar: print aspa_check(aspas, "54874 970", false) = ASPA_INVALID; Currently though there is no datatype that would allow one to provide the BGP path thus that test would not be possible. But, I do think there might be a bug (though I might just understand the whole thing wrong). If we simply define: ``` aspa table aspas; ``` and then call a `aspa_check(aspas, ...., ...)` then I sometimes receive a ASPA_VALID back, especially for paths with only 1 ASN. This, while that table is really empty. Checking the code: https://gitlab.nic.cz/labs/bird/-/blob/master/nest/rt-table.c#L356 There is a !found for the upstream edition, but in the end, the logic does not account for a empty ASPA table, which could simply be because one lost the connection to the RTR that supplies is (or stayrtr not providing currently any entries...) Which might cause an ASPA_VALID to come out, even though not a single ASPA entry has been defined and as there are no entries the path cannot be 'surely valid'... should that situation not be ASPA_UNKNOWN? Maybe a meree check if 'tab' is empty at the top would be sufficient to determine that it will always be unknown as we have no positive or negative entries? net_roa_check has a 'anything' variable to cover that situation it seems, which causes ROA_INVALID : ROA_UNKNOWN which is the correct way IMHO. (correct and nice use of inline macros there btw :) ) Greets, Jeroen

3 3

Assertion '!bmap_test(&c->export_rejected_map, old->id)' failed at nest/rt-table.c:1571
by Alexey Boldyrev 13 Apr '25

13 Apr '25

Bird log: Apr 13 12:32:29 router bird[692]: No protocol for 0 BFD requests Apr 13 12:32:29 router bird[692]: No protocol for 0 BFD requests Apr 13 16:51:40 router bird[692]: AS4200220007: Received: Administrative shutdown Apr 13 16:51:40 router bird[692]: No protocol for 0 BFD requests Apr 13 16:51:40 router bird[692]: No protocol for 0 BFD requests Apr 13 16:51:43 router bird[692]: Assertion '!bmap_test(&c->export_rejected_map, old->id)' failed at nest/rt-table.c:1571 Apr 13 16:51:44 router systemd-coredump[1475866]: [🡕] Process 692 (bird) of user 967 dumped core. Stack trace of thread 693: #0 0x000074202a4ff624 n/a (libc.so.6 + 0x97624) #1 0x000074202a4a5ba0 raise (libc.so.6 + 0x3dba0) #2 0x000074202a48d582 abort (libc.so.6 + 0x25582) #3 0x00005ea4f196859f n/a (/usr/bin/bird + 0xda59f) #4 0x00005ea4f18eb3a8 n/a (/usr/bin/bird + 0x5d3a8) #5 0x00005ea4f18bfd6f n/a (/usr/bin/bird + 0x31d6f) #6 0x00005ea4f196c20a n/a (/usr/bin/bird + 0xde20a) #7 0x00005ea4f18bfd6f n/a (/usr/bin/bird + 0x31d6f) #8 0x00005ea4f196b530 n/a (/usr/bin/bird + 0xdd530) #9 0x000074202a4fd70a n/a (libc.so.6 + 0x9570a) #10 0x000074202a581aac n/a (libc.so.6 + 0x119aac) Stack trace of thread 692: #0 0x000074202a505be2 n/a (libc.so.6 + 0x9dbe2) #1 0x000074202a4f9e33 n/a (libc.so.6 + 0x91e33) #2 0x000074202a4f9e74 n/a (libc.so.6 + 0x91e74) #3 0x000074202a574a3e read (libc.so.6 + 0x10ca3e) #4 0x00005ea4f1962dc0 n/a (/usr/bin/bird + 0xd4dc0) #5 0x00005ea4f1894625 n/a (/usr/bin/bird + 0x6625) #6 0x000074202a48f488 n/a (libc.so.6 + 0x27488) #7 0x000074202a48f54c __libc_start_main (libc.so.6 + 0x2754c) #8 0x00005ea4f1895055 n/a (/usr/bin/bird + 0x7055) Stack trace of thread 697: #0 0x000074202a505be2 n/a (libc.so.6 + 0x9dbe2) #1 0x000074202a4f9e33 n/a (libc.so.6 + 0x91e33) #2 0x000074202a4f9e74 n/a (libc.so.6 + 0x91e74) #3 0x000074202a57453e __poll (libc.so.6 + 0x10c53e) #4 0x00005ea4f196b5cf n/a (/usr/bin/bird + 0xdd5cf) #5 0x000074202a4fd70a n/a (libc.so.6 + 0x9570a) #6 0x000074202a581aac n/a (libc.so.6 + 0x119aac) ELF object binary architecture: AMD x86-64 Apr 13 16:51:44 router systemd[1]: bird.service: Main process exited, code=dumped, status=6/ABRT Apr 13 16:51:44 router systemd[1]: bird.service: Failed with result 'core-dump'. Apr 13 16:51:44 router systemd[1]: bird.service: Consumed 3min 18.943s CPU time, 5.9M memory peak. Version: 3.0.1 Distribution: arch linux

1 0

EBGP Multihop /w Directly Connected Peer
by Anthony Hoppe 09 Apr '25

09 Apr '25

Hello, I have a situation where I need to enable EBGP multihop even though the peer is directly connected. Backstory: I have hosts running BIRD peered with MLAG paired switches and there are instances where BGP ECMP and LACP hashing don't align. BGP packets destined to one peer (Switch A) will land on the other switch in the pair (Switch B). In this case, the switch in which the packet landed (Switch B) will route the packet to the correct switch (Switch A) causing TTL to decrement. When I configure multihop in BIRD, it seems BIRD assumes that the next-hop address is unreachable and expects there to be a static route to the peer before it will consider accepted routes reachable. I can't add a static route that points to itself, so in my testing environment I ended up adding a /128 to the loopback interface on both switches and configured BIRD peer with that address. Then I was able to add the static route BIRD is expecting (and is now actually necessary), and multihop works fine. However, if possible, I'd like to avoid having to do this. Is there a way? Thanks! ~ Anthony -- This email, including its contents and any attachment(s), may contain confidential and/or proprietary information and is solely for the review and use of the intended recipient(s). If you have received this email in error, please notify the sender and permanently delete this email, its content, and any attachment(s). Any disclosure, copying, or taking of any action in reliance on an email received in error is strictly prohibited.

2 5

[PATCH] Babel: allow enabling link quality estimation manually
by Nick Cao 09 Apr '25

09 Apr '25

Link quality estimation is useful for link types other than wireless, especially when using babel with tunnels where packet losses do occur. --- doc/bird.sgml | 6 ++++++ proto/babel/babel.c | 19 ++++++------------- proto/babel/babel.h | 1 + proto/babel/config.Y | 5 ++++- 4 files changed, 17 insertions(+), 14 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 8041faa9..417ec030 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2032,6 +2032,12 @@ protocol babel [<name>] { hardware drivers or platforms do not implement this feature. Default: yes. + <tag><label id="babel-link-quality">link quality <m/switch/</tag> + If set, link quality estimation is performed on this interface. + Link quality is measured by packet loss and is used for computing + metrics of routes going through this interface. Default: yes for + wireless interfaces, otherwise no. + <tag><label id="babel-next-hop-ipv4">next hop ipv4 <m/address/</tag> Set the next hop address advertised for IPv4 routes advertised on this interface. Default: the preferred IPv4 address of the interface. diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 7f0cca73..6a238d75 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -593,21 +593,15 @@ babel_update_cost(struct babel_neighbor *nbr) if (!rcv || !nbr->ifa->up) goto done; - switch (cf->type) - { - case BABEL_IFACE_TYPE_WIRED: - case BABEL_IFACE_TYPE_TUNNEL: + if (!cf->link_quality) { /* k-out-of-j selection - Appendix 2.1 in the RFC. */ /* Link is bad if less than cf->limit/16 of expected hellos were received */ - if (rcv * 16 < cf->limit * max) - break; - - rxcost = cf->rxcost; - txcost = nbr->txcost; - break; - - case BABEL_IFACE_TYPE_WIRELESS: + if (!(rcv * 16 < cf->limit * max)) { + rxcost = cf->rxcost; + txcost = nbr->txcost; + } + } else { /* * ETX - Appendix 2.2 in the RFC. * @@ -622,7 +616,6 @@ babel_update_cost(struct babel_neighbor *nbr) */ rxcost = MIN( cf->rxcost * max / rcv, BABEL_INFINITY); txcost = MIN(nbr->txcost * max / rcv, BABEL_INFINITY); - break; } if (cf->rtt_cost && nbr->srtt > cf->rtt_min) diff --git a/proto/babel/babel.h b/proto/babel/babel.h index edde4cab..d152d099 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -145,6 +145,7 @@ struct babel_iface_config { u8 type; u8 limit; /* Minimum number of Hellos to keep link up */ u8 check_link; + u8 link_quality; uint port; uint hello_interval; /* Hello interval, in us */ uint ihu_interval; /* IHU interval, in us */ diff --git a/proto/babel/config.Y b/proto/babel/config.Y index b8af0267..cbf873c5 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -26,7 +26,7 @@ CF_KEYWORDS(BABEL, INTERFACE, METRIC, RXCOST, HELLO, UPDATE, INTERVAL, PORT, TYPE, WIRED, WIRELESS, RX, TX, BUFFER, PRIORITY, LENGTH, CHECK, LINK, NEXT, HOP, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE, - EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS) + EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS, QUALITY) CF_GRAMMAR @@ -72,6 +72,7 @@ babel_iface_start: BABEL_IFACE->rtt_decay = BABEL_RTT_DECAY; BABEL_IFACE->rtt_send = 1; BABEL_IFACE->check_link = 1; + BABEL_IFACE->link_quality = 0; BABEL_IFACE->ext_next_hop = 1; }; @@ -84,6 +85,7 @@ babel_iface_finish: BABEL_IFACE->hello_interval = BABEL_HELLO_INTERVAL_WIRELESS; if (!BABEL_IFACE->rxcost) BABEL_IFACE->rxcost = BABEL_RXCOST_WIRELESS; + BABEL_IFACE->link_quality = 1; } else { @@ -156,6 +158,7 @@ babel_iface_item: | TX tos { BABEL_IFACE->tx_tos = $2; } | TX PRIORITY expr { BABEL_IFACE->tx_priority = $3; } | CHECK LINK bool { BABEL_IFACE->check_link = $3; } + | LINK QUALITY bool { BABEL_IFACE->link_quality = $3; } | NEXT HOP IPV4 ipa { BABEL_IFACE->next_hop_ip4 = $4; if (!ipa_is_ip4($4)) cf_error("Must be an IPv4 address"); } | NEXT HOP IPV6 ipa { BABEL_IFACE->next_hop_ip6 = $4; if (!ipa_is_ip6($4)) cf_error("Must be an IPv6 address"); } | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4; } -- 2.41.0

4 14

area 0 interface in a non-default FIB
by Eugene M. Zheganin 07 Apr '25

07 Apr '25

Hello, I'm using bird mostly for OSPF suppor. On one of my OSPF-connected sites (running bird 1.6.8 on a FreeBSD 13.2-RELEASE-p12) I needed to put my bcast area0 interface into non-default FIB (the purpose is to make 192.168.31.0/24 use a default gateway radically other that the main FIB is using): ===Cut=== igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether 9c:8e:99:31:b1:ba inet 192.168.31.30 netmask 0xffffff00 broadcast 192.168.31.255 inet 192.168.31.2 netmask 0xffffff00 broadcast 192.168.31.255 inet 192.168.31.52 netmask 0xffffff00 broadcast 192.168.31.255 fib: 1 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> ===Cut=== Almost everything continued to work fine, except two things: 1) now bird complains about a socket on this interface: calypso bird[79957]: ospfv4: Socket error on igb0: Network is unreachable 2) now the igb0-neighbors are stuck in ExtStart phase (this is obviously related to the previous issue): Router ID Pri State DTime Interface Router IP 192.168.31.1 1 ExStart/DR 00:36 igb0 192.168.31.1 How can I fix this, probably without massive configuration changes, like putting 192.168.31.0/24 on a separate vlan and assigning this vlan to a FIB 1 ? Thanks.

1 0

bird 3.0.1 doesn’t compile on FreeBSD
by Olivier Cochard-Labbé 04 Apr '25

04 Apr '25

Hi, bird 3.0.1 include this patch: "Netlink: Handle onlink flag on BSD-Netlink" https://gitlab.nic.cz/labs/bird/-/commit/f9c7861e116ad8dc5e5a2314d0f976bf8c… But this broke FreeBSD build with this error: sysdep/bsd-netlink/netlink.c:1868:10: error: no member named 'nh' in 'struct ea_list Regards, Olivier

3 4