- Bird-users - Mailing Lists

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

[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

BGP, "Invalid NEXT_HOP attribute"
by Lexi Winter 15 Mar '25

15 Mar '25

hello, recently i noticed some entries in syslog like this: Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1 Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1 Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1 Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1 Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn i am not sure how to understand this log message. i still have the route (including via nl-myb-1): root@uk-myb-2:~ # birdc show route 172.20.212.0/26 BIRD 2.16.1 ready. Table master4: 172.20.212.0/26 unicast [uk-jmp-2 11:03:22.032 from fd5b:a83:b06b:400::1] * (100/61) [AS4242422622i] via fe80::e0e3:b1bf:8d1d:abcd on wg.nl-myb-1 unicast [nl-myb-1 11:03:20.704 from fd5b:a83:b06b:500::1] (100/61) [AS4242422622i] via fe80::e0e3:b1bf:8d1d:abcd on wg.nl-myb-1 unicast [ny-czy-1 11:03:20.589 from fd5b:a83:b06b:200::1] (100/694) [AS4242422622i] via fe80::bc1b:dbed:690a:6840 on wg.uk-jmp-2 unicast [mia-czy-1 11:03:20.680 from fd5b:a83:b06b:900::1] (100/694) [AS4242422622i] via fe80::bc1b:dbed:690a:6840 on wg.uk-jmp-2 and it's in the FIB as well: root@uk-myb-2:~ # route -n get -inet 172.20.212.0/26 route to: 172.20.212.0 destination: 172.20.212.0 mask: 255.255.255.192 gateway: fe80::e0e3:b1bf:8d1d:abcd%wg.nl-myb-1 fib: 0 interface: wg.nl-myb-1 flags: <UP,GATEWAY,DONE> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1420 1 0 so everything seems fine. what is BIRD trying to indicate with this log message?

2 5

IGP metric attribute semantic dichotomy
by Maria Matejka 15 Mar '25

15 Mar '25

Dear BIRD users, we'd like to do a public survey about naming things. In short, there are two different route attributes in BIRD 2: - The whole route's total metric from here to the destination, if set explicitly by `igp_metric = N` in filters. I.e., a generic alternative to protocol-specific IGP metrics like `ospf_metric1` or `babel_metric`. - Metric of the route's part between here and `bgp_next_hop`, determined by recursive next hop resolution. I.e., from that route which resolved the recursive next hop, the value in the first meaning of `igp_metric` is taken and stored here. **Both of these two attributes are internally named `igp_metric` in BIRD 2.** However, only the first one is accessible by filters. When rewriting the attribute handling code for BIRD 3, I merged them together. This is technically not a bug per se and for now, yet it behaves weirdly in corner cases and confuses people. We plan to split these attributes back in BIRD 3, but we don't want (and technically also can't) use the same name any more. **How to name these two attributes better?** Looking forward to your suggestions and opinions. Happy routing! Maria and the BIRD Team -------------------------- Follows longer explanation on IGP metric, feel free to skip that. What's the IGP metric? Let's consider an iBGP route, received from a BGP peer in the same AS, via a multihop session. This route's next hop is often not locally known and has to be resolved by finding a matching route (let's call that route an IGP route) and using that route's nexthop, as expected by RFC 4271, section 5.1.3. We call such a situation "recursive nexthop". Such a route pair then may look like follows (shortened): 2001:db8:2::/48 unicast [ibgp3 <removed> from 10.1.4.1] * (100/40) [AS65532i] via fe80::386c:8fff:feb8:206c on ve1 hostentry: via 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 table master6 bgp_next_hop: 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 igp_metric: 40 source: BGP 2001:db8:1:13::/64 unicast [ospf6 <removed>] * I (150/40) [10.0.1.4] via fe80::386c:8fff:feb8:206c on ve1 ospf_metric1: 40 source: OSPF The `bgp_next_hop` attribute is non-local, and there is another route able to resolve that attribute to the local next hop. That route's metric is transferred to the BGP route as `igp_metric`. In BIRD 2, that's just an internal value, displayed on the first line as (100/40), which is preference (100) and the IGP metric (40). But you may also have a static route instead of the OSPF one: protocol static { ipv6; route 2001:db8:1:13::/64 via fe80::386c:8fff:feb8:206c dev ve1 { igp_metric = 40; }; } Here the `igp_metric` semantics is the whole route's metric. This metric can then be used in next hop resolution and applied to the BGP route. And in the BGP route, there will be this `igp_metric` attribute copied, representing only the metric from here to `bgp_next_hop`. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

3 2