February 2025 - Bird-users

[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

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

[PATCH v2] Babel: Allow v6 next hop on interfaces with v4 addresses
by Chris Webb 28 Mar '25

28 Mar '25

By default, the Babel protocol will advertise an IPv6 extended next hop address on interfaces which don't have an IPv4 address. This is controlled by the 'extended next hop' option. Add support for 'extended next hop force' which advertises an extended next hop even when IPv4 addresses are present. (They may be temporary, for debugging or otherwise unsuitable for including in an advertisement.) --- v2: use an explicit enum for possible values of ext_next_hop doc/bird.sgml | 9 ++++++--- proto/babel/babel.c | 17 +++++++++++++---- proto/babel/babel.h | 6 ++++++ proto/babel/config.Y | 5 +++-- 4 files changed, 28 insertions(+), 9 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 0d1e6f49..cb5fa572 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2266,7 +2266,7 @@ protocol babel [<name>] { check link <switch>; next hop ipv4 <address>; next hop ipv6 <address>; - extended next hop <switch>; + extended next hop <switch>|force; rtt cost <number>; rtt min <time>; rtt max <time>; @@ -2377,10 +2377,13 @@ protocol babel [<name>] { source for Babel packets will be used. In normal operation, it should not be necessary to set this option. - <tag><label id="babel-extended-next-hop">extended next hop <m/switch/</tag> + <tag><label id="babel-extended-next-hop">extended next hop + <m/switch/|force</tag> If enabled, BIRD will accept and emit IPv4 routes with an IPv6 next hop when IPv4 addresses are absent from the interface as described in - <rfc id="9229">. Default: yes. + <rfc id="9229">. Use <cf/extended next hop force/ to emit IPv4 routes + with an IPv6 next hop even when IPv4 addresses are present on the + interface. Default: yes. <tag><label id="babel-rtt-cost">rtt cost <m/number/</tag> The RTT-based cost that will be applied to all routes from each neighbour diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4187d258..4db6bd04 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1836,8 +1836,12 @@ babel_iface_update_addr4(struct babel_iface *ifa) { struct babel_proto *p = ifa->proto; - ip_addr addr4 = ifa->iface->addr4 ? ifa->iface->addr4->ip : IPA_NONE; - ifa->next_hop_ip4 = ipa_nonzero(ifa->cf->next_hop_ip4) ? ifa->cf->next_hop_ip4 : addr4; + if (ipa_nonzero(ifa->cf->next_hop_ip4)) + ifa->next_hop_ip4 = ifa->cf->next_hop_ip4; + else if (ifa->cf->ext_next_hop != BABEL_EXT_NEXT_HOP_FORCE && ifa->iface->addr4) + ifa->next_hop_ip4 = ifa->iface->addr4->ip; + else + ifa->next_hop_ip4 = IPA_NONE; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel && !ifa->cf->ext_next_hop) log(L_WARN "%s: Missing IPv4 next hop address for %s", p->p.name, ifa->ifname); @@ -1912,8 +1916,13 @@ babel_add_iface(struct babel_proto *p, struct iface *new, struct babel_iface_con add_tail(&p->interfaces, NODE ifa); - ip_addr addr4 = new->addr4 ? new->addr4->ip : IPA_NONE; - ifa->next_hop_ip4 = ipa_nonzero(ic->next_hop_ip4) ? ic->next_hop_ip4 : addr4; + if (ipa_nonzero(ic->next_hop_ip4)) + ifa->next_hop_ip4 = ic->next_hop_ip4; + else if (ic->ext_next_hop != BABEL_EXT_NEXT_HOP_FORCE && new->addr4) + ifa->next_hop_ip4 = new->addr4->ip; + else + ifa->next_hop_ip4 = IPA_NONE; + ifa->next_hop_ip6 = ipa_nonzero(ic->next_hop_ip6) ? ic->next_hop_ip6 : ifa->addr; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel && !ic->ext_next_hop) diff --git a/proto/babel/babel.h b/proto/babel/babel.h index edde4cab..5b397b45 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -127,6 +127,12 @@ enum babel_ae_type { BABEL_AE_MAX }; +enum babel_ext_next_hop { + BABEL_EXT_NEXT_HOP_OFF = 0, + BABEL_EXT_NEXT_HOP_ON = 1, + BABEL_EXT_NEXT_HOP_FORCE = 2 +}; + struct babel_config { struct proto_config c; diff --git a/proto/babel/config.Y b/proto/babel/config.Y index d412a54b..bdfff203 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -24,7 +24,7 @@ CF_DECLS 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, + NEXT, HOP, FORCE, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE, EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS, COST, DELAY) @@ -158,7 +158,8 @@ babel_iface_item: | CHECK LINK bool { BABEL_IFACE->check_link = $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; } + | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4 ? BABEL_EXT_NEXT_HOP_ON : BABEL_EXT_NEXT_HOP_OFF; } + | EXTENDED NEXT HOP FORCE { BABEL_IFACE->ext_next_hop = BABEL_EXT_NEXT_HOP_FORCE; } | AUTHENTICATION NONE { BABEL_IFACE->auth_type = BABEL_AUTH_NONE; } | AUTHENTICATION MAC { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 0; } | AUTHENTICATION MAC PERMISSIVE { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 1; }

3 5

One bird VM (HA cluster) or two bird VMs (iBGP).
by Mike Neo 18 Mar '25

18 Mar '25

Hi, I have one global operator and one IX via BGP and I'm wondering whether to set up one bird VM based on vmware HA cluster or two bird VMs without vmware HA cluster but located on separate nodes and connected via iBGP. Of course, the iBGP connection allows for easy bird/VM updates but may generate potential problems with iBGP and VRRP. However, if there is one bird VM based on the vmware HA cluster, then in the event of a node failure, it is necessary to wait until the machine is restarted on the second node and until the prefixes from peers are loaded. What are your experiences with this? Thanks in advance, Mike

4 5

python library for generating bird configuration files
by Hendrik Wolff 03 Mar '25

03 Mar '25

Hey, I wrote a tiny library to generate bird configurations with python classes. It has no external dependencies and the repository includes some examples. It's in no way perfect or complete and I don't plan to extend it. But maybe it can serve as a base for your own needs. Extending it to support more protocols and options should be fairly easy. My personal favorite feature is that you can mark any Protocol class instance as a bird template by passing the is_template=True parameter. This template can be reused by passing the name of the template (e.g. "my_template") to the from_template="my_template" parameter of another Protocol class instance. https://github.com/hw0lff/bird-config-py Have fun! Cheers -- Hendrik

2 2

IPv4 routes with IPv6 nexthop in OSPFv3
by Lexi Winter 28 Feb '25

28 Feb '25

hello, it's me again, with my OSPF network. i was reading this blog post: https://ipng.ch/s/articles/2024/04/06/vpp-with-loopback-only-ospfv3-part-1/ which seems to suggest that Ondrej had done some work on advertising IPv4 prefixes into OSPFv3 with IPv6 nexthop in BIRD. however, it's not entirely clear to me how this works in practice, particularly since i don't use VPP. what i'd like to achieve is that each router that handles IPv4 packets has a single IPv4 address on lo0, and this somehow (magically) works with OSPFv3, so that i don't need to assign a /31 to every IPv4 OSPF peer. is this possible in BIRD 2.16.1, and if so, how would i go about setting it up? thanks, lexi.

2 1

advertise OSPF default route into a specific area?
by Lexi Winter 28 Feb '25

28 Feb '25

hello, i'm using BIRD 2.16.1 on FreeBSD 15.0. i have an OSPF ABR in area 0 and area 1. this router has a default route via a non-OSPF interface (kernel route, imported into BIRD using the 'kernel' protocol). i'd like to advertise this route into area 1, but *not* into area 0. how would i go about doing that? please feel free to let me know if this is a bad idea or if i'm using OSPF wrong :-) thanks, lexi.

3 3

Question about logging with 3.0.1
by Nigel Kukard 28 Feb '25

28 Feb '25

Hi there, I'm wondering if anyone has seen excessive filter logging with 3.0.0/3.0.1? Comparing log output from tests done on v2 vs v3, I'm seeing 2G+ log files generated in 30s on v3, when in v2 the log files were only a few hundred Kb in size at most after some time. I have router R1 and R2 connected via BGP. I have a couple of filters which log if a prefix has been filtered or accepted, I've included my log configuration and filter below. Here is the log config I'm using... log "/var/log/bird.log" { info, warning, fatal }; debug protocols { states, routes, filters, interfaces, events }; timeformat base iso long; timeformat log iso long; timeformat protocol iso long; timeformat route iso long; Here is the test filter I created to test... define DEFAULT_ROUTE_V4 = 0.0.0.0/0; define DEFAULT_ROUTE_V6 = ::/0; function is_default(string filter_name) -> bool { if ((net.type = NET_IP4 && net = DEFAULT_ROUTE_V4) || (net.type = NET_IP6 && net = DEFAULT_ROUTE_V6)) then return true; return false; } function bgp_accept_bgp(string filter_name) -> bool { if (is_default()) then return false; print filter_name, " [bgp_accept_bgp] Accepting BGP route ", net, " from ", proto; accept; } filter f_bgp_master_export string filter_name; { filter_name = "f_bgp_master_export"; bgp_accept_bgp(filter_name); reject; }; Here is the odd behavior I"m observing in v3... 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.111.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.112.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.113.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.201.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.131.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.132.0.0/24 from bgp4_AS65000_r1 repeating very many times per second... 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.111.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.112.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.113.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.201.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.131.0.0/24 from bgp4_AS65000_r1 2025-02-24 15:21:04 [0002] <INFO> f_bgp_master_export [bgp_accept_bgp] Accepting BGP route 100.132.0.0/24 from bgp4_AS65000_r1 In about 30s my log file grew to 2.1GB before I stopped the process. Perhaps I'm missing something in the migration guide? any help would be greatly appreciated. Kind Regards Nigel

2 4

[PATCH] Fix source-specific routing in Bird 3
by Toke Høiland-Jørgensen 26 Feb '25

26 Feb '25

Commit 69d1ffde4c72 ("Split route data structure to storage (ro) / manipulation (rw) structures.") changed rte->net from a pointer to a 'struct network' to a 'struct net_addr', but kept the address-of (&) operator before casting to 'net_addr_ip6_sadr *' when sending a source-specific route to the kernel. Because 'struct network' had an embedded struct member (struct fib_node), the address-of was needed to get back to a pointer to the data, but with the change in the commit mentioned above, e->net is now a straight pointer to the address. The bug meant that the source prefixes passed to the kernel were essentially garbage, leading to routes in the kernel like: default from b74:9e05:0:1:d8cf:c000::/86 via fe80::1 dev eth0 proto bird metric 32 pref medium Fix this by getting rid of the address-of operator. Fixes: 69d1ffde4c72 ("Split route data structure to storage (ro) / manipulation (rw) structures.") Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- sysdep/linux/netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 1703a67595d5..6cc0142c3e00 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -1494,7 +1494,7 @@ nl_send_route(struct krt_proto *p, const rte *e, int op) /* Add source address for IPv6 SADR routes */ if (e->net->type == NET_IP6_SADR) { - net_addr_ip6_sadr *a = (void *) &e->net; + net_addr_ip6_sadr *a = (void *) e->net; nl_add_attr_ip6(&r->h, rsize, RTA_SRC, a->src_prefix); r->r.rtm_src_len = a->src_pxlen; } -- 2.48.1

2 2

Bird v3 failed assert
by Maiyun Zhang 25 Feb '25

25 Feb '25

Hello folks, I was checking the log today and saw a failed assertion in bird. bird[43579]: Assertion '!bmap_test(&c->export_rejected_map, old->id)' failed at nest/rt-table.c:1571 After this, the daemon dies and gets restarted by systemd. The frequency of this fault ranges from once every few minutes to a few hours depending on BGP traffic. I am running the latest build on branch stable-v3 (d13c9d3), built with gcc 13. This error happens on all three of my routers running the same revision. All of them are aarch64 linux machines. Two of them have eBGP peers and one is iBGP only (and babel). Judging from the log lines, there is not a pattern before which this happens. The set up is a little complex for me, so I’m sorry for not having a ready-to-go MWE. Please let me know if I can help debugging it. Thank you all for the great work in Bird! Best, Maiyun Zhang (he/him)

2 1