March 2025 - Bird-users - Mailing Lists

Issues running BMP protocol in v3.0.1
by admin＠nxthdr.dev 26 May '25

26 May '25

Hey, I've migrated from 2.16.1 to 3.0.1 and I'm facing some issues with the BMP protocol. The TCP session goes up but I don't receive all peers up notifications. I receive some (but not all it seems) when I restart bird after have started my BMP collector. If I do the opposite, I get none. Also, I don't receive route monitoring messages. To be precise, I receive only one route monitoring message when I receive a peer up notification. But this one is empty (meaning no announced/withdrawn prefixes in it). Also I receive it just just before the peer up, which is a bit weird. I should receive a tons of them, with announced prefixes in it, right after the peer up. Here is my BMP configuration: protocol bmp { station address ip 2a06:de00:50:cafe:100::c port 4000; monitoring rib in pre_policy; monitoring rib in post_policy;} bird> show protocols all bmp1 Name Proto Table State Since Info bmp1 BMP --- up 18:08:26.528 Established Created: 18:08:16.105 Station address: 2a06:de00:50:cafe:100::c Station port: 4000 Pending TX: 0 B (limit 1024.0 MB) Session TX: 789 B Total TX: 789 B Do you experience the same behavior? Please let me know if you need more information, I'm happy to make some other tests if needed. Best,Matthieu.

1 1

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

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

2.16.1, BFD-related crash in nest/password.c:password_find_by_id()
by Lexi Winter 27 Mar '25

27 Mar '25

hello, i'm running into a crash on 2.16.1 on FreeBSD/amd64 15.0. it happens sometimes (not always) when reconfiguring BIRD with BFD enabled. (gdb) run -f Starting program: /usr/local/bird/sbin/bird -f [New LWP 101873 of process 58914] Thread 2 received signal SIGSEGV, Segmentation fault. Address not mapped to object. [Switching to LWP 101873 of process 58914] 0x00000000002bcd70 in password_find_by_id (l=0x800e913e0, id=1) at nest/password.c:52 warning: 52 nest/password.c: No such file or directory (gdb) bt #0 0x00000000002bcd70 in password_find_by_id (l=0x800e913e0, id=1) at nest/password.c:52 #1 0x00000000002d2b3c in bfd_check_authentication (p=p@entry=0x801215a20, s=s@entry=0x800def920, pkt=0xffffffff00000000, pkt@entry=0x801296780) at proto/bfd/packets.c:246 #2 0x00000000002d2755 in bfd_rx_hook (sk=0x8012288c0, len=<optimized out>) at proto/bfd/packets.c:384 #3 0x0000000000312a3a in sk_read_noflush (s=0x8012288c0, revents=<optimized out>) at sysdep/unix/io.c:2144 #4 sk_read (s=0x8012288c0, revents=revents@entry=0) at sysdep/unix/io.c:2153 #5 0x00000000002d1f49 in sockets_fire (loop=0x80129e020) at proto/bfd/io.c:376 #6 birdloop_main (arg=0x80129e020) at proto/bfd/io.c:526 #7 0x00000008003fad32 in thread_start (curthread=0x800e0b808) at /build/src/freebsd/lf/main/lib/libthr/thread/thr_create.c:289 #8 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 (gdb) line 52 is: WALK_LIST(pi, *l) (gdb) print pi $1 = <optimized out> (gdb) print l $2 = (list *) 0x800e913e0 (gdb) print *l $3 = {{head_node = {next = 0xffffffff00000000, prev = 0x0}, head_padding = 0x0}, {tail_padding = 0xffffffff00000000, tail_node = {next = 0x0, prev = 0x0}}, {head = 0xffffffff00000000, null = 0x0, tail = 0x0}} my BFD configuration is fairly straightforward: protocol bfd { interface "wg.*" { interval 200ms; password "..."; authentication keyed sha1; }; multihop { interval 1s; multiplier 5; password "..."; authentication keyed sha1; }; } and it's enabled (bfd yes;) for OSPFv3 peers and multihop IBGP peers. i have a binary with debuggiing symbols and a core dump if any more debugging is required. regards, lexi.

2 2

Regarding how to check the results of roa_check()
by ushiroz＠ate-mahoroba.jp 25 Mar '25

25 Mar '25

Hi I am using roa_check(). Is there a bird command that checks the result of roa_check() on the command line, not just in the conf processing?

2 4

Re: Ignoring unsorted multipath route 0.0.0.0/0
by Farhad 19 Mar '25

19 Mar '25

Resending.. On Fri, Mar 7, 2025 at 12:54 PM Farhad <ahdfra(a)gmail.com> wrote: > Hi, > In bird (*3.0.0* version) I am seeing a strange behavior which is not the > case with the previous bird version I was using (*2.13.1*) > > In the routing configuration in case of multipath routes if the addresses > are not sorted bird doesn't generate the route in the system and warning `*<WARN> > static1.ipv4: Ignoring unsorted multipath route 0.0.0.0/0 > <http://0.0.0.0/0>*` appears in the log > > an example: > > > > > *protocol static { ipv4 { table ipv4Table_14; }; > route 0.0.0.0/0 <http://0.0.0.0/0> via 10.17.3.123 bfd > via 10.17.3.122 bfd; }* > If the addresses are set in an ascending order then the route is generated. > > Logs: > > > > > > > > *2025-03-07 10:02:00.406 [0001] <INFO> Reconfiguring2025-03-07 > 10:02:00.406 [0001] <INFO> Reconfigured2025-03-07 10:02:00.406 [0001] > <TRACE> No protocol for 0 BFD requests2025-03-07 10:02:00.817 [0001] <WARN> > static1.ipv4: Ignoring unsorted multipath route 0.0.0.0/0 > <http://0.0.0.0/0>2025-03-07 10:05:16.257 [0001] <INFO> > Reconfiguring2025-03-07 10:05:16.257 [0001] <INFO> Reconfigured2025-03-07 > 10:05:16.258 [0001] <TRACE> No protocol for 0 BFD requests2025-03-07 > 10:05:16.258 [0001] <WARN> static1.ipv4: Ignoring unsorted multipath route > 0.0.0.0/0 <http://0.0.0.0/0>* > > BR, > Farhad >

1 0

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

Babel/OSPF with multiple routers claiming the same route
by Maiyun Zhang 18 Mar '25

18 Mar '25

Hi All, I’m trying to implement a topology where multiple nodes have connections to one network. Let’s say there are three devices running babel: A 10.0.0.1/24 B 10.0.0.2 C 10.0.0.3 and both B and C can route traffic to 10.1.0.0/16, and BIRD learns this route through the `kernel` protocol. Now that both B and C announces 10.1.0.0/16 via babel, and it seems that BIRD does some kind of “first come first serve”, and A only sees the route via one of B or C. Let’s say B comes online first and announces the route. Now C comes online. It doesn’t announce 10.1.0.0/16 to babel at all. The same behaviour is observed if I use ospf instead of babel. My hypothesis is that when it synchronizes kernel with master4, it sees that 10.1.0.0/16 is already in master4 (announced by B), and so it doesn’t import this route from kernel to master4 at all(?) What I am trying to do is to have both B and C announce this route, and let babel choose whether traffic from A for 10.1.0.0/16 should go to B or C based on its metric. Is this possible? or is it a really bad idea? Thanks. Best, Maiyun Zhang (he/him)

1 0