- Bird-users - Mailing Lists

[PATCH v2 1/4] Netlink: Enable strict checking on nl_req
by Asbjørn Sloth Tønnesen 18 May '26

18 May '26

Enable strict checking of netlink messages on the nl_req connection, so it is enabled on both connections. Also rename the function to remove "_dump" suffix, as it's a generic option. Strict checking was originally called NETLINK_DUMP_STRICT_CHK, but was renamed to NETLINK_GET_STRICT_CHK, as it should apply to all calls, not only dumps (Linux commmit d3e8869ec826). When set on nl_req, we don't need to check the return code, as it will fail on nl_scan as well, and so one log message should be enough and unlike nl_scan, we don't need to alter the mode of operation. Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 00b21fc97..9c519adb6 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -86,7 +86,7 @@ nl_open_sock(struct nl_sock *nl) } static int -nl_set_strict_dump(struct nl_sock *nl UNUSED, int strict UNUSED) +nl_set_strict_chk(struct nl_sock *nl UNUSED, int strict UNUSED) { #ifdef SOL_NETLINK return setsockopt(nl->fd, SOL_NETLINK, NETLINK_GET_STRICT_CHK, &strict, sizeof(strict)); @@ -125,7 +125,8 @@ nl_open(void) nl_open_sock(&nl_scan); nl_open_sock(&nl_req); - if (nl_set_strict_dump(&nl_scan, 1) < 0) + nl_set_strict_chk(&nl_req, 1); + if (nl_set_strict_chk(&nl_scan, 1) < 0) { log(L_WARN "KRT: Netlink strict checking failed, will scan all tables at once"); krt_use_shared_scan(); -- 2.53.0

1 0

Re: iBGP and redundancy problem.
by Jeroen Massar 18 May '26

18 May '26

> On 18 May 2026, at 09:21, Mike Neo <neomikemac(a)gmail.com> wrote: > > I think there's a problem with knowing how to access clients/internet via iBGP. When the ISP on R1 goes down, I can't even access the internet from R1 via iBGP. Perhaps there's some routing missing in this area. I would suggest providing configuration and routing table excerpts if you want anybody on the list to help you out. Regards, Jeroen > > niedz., 17 maj 2026 o 23:43 Jeroen Massar <jeroen(a)massar.ch> napisał(a): > > > > On 17 May 2026, at 20:44, Mike Neo <neomikemac(a)gmail.com> wrote: > > > > Are you BGP exchanging routes between R1 and R2? > > Yes. > > > > Does R1 pull/removes the routes from the upstream when they are down. > > Yes. > > > > Are R2 routes visible, likely less preferred, on R1? > > Yes, via iBGP. > > Then, what is the post-failover state that apparently fails? > Check routing tables on R1 and R2, both bird and the kernel routing tables. > > Also do a traceroute from a client to see where things go, or if possible log in to each and use similar to 'ip ro get <remote-ip>' to see where the next hop leads. But also be sure to do that all the way from R2. > > Does R2 how to get to R1 to get to the clients? > > > And just in case, if NAT or even normal connection tracking is involved that might cause issues primarily due to the missing state on R2 where those packets are not expected. > > Also this is all assuming that both R1 and R2 are announcing the same prefixes and that upstream keeps on sending packets. > > Regars, > Jeroen >

1 0

Re: iBGP and redundancy problem.
by Jeroen Massar 17 May '26

17 May '26

> On 17 May 2026, at 20:44, Mike Neo <neomikemac(a)gmail.com> wrote: > > Are you BGP exchanging routes between R1 and R2? > Yes. > > Does R1 pull/removes the routes from the upstream when they are down. > Yes. > > Are R2 routes visible, likely less preferred, on R1? > Yes, via iBGP. Then, what is the post-failover state that apparently fails? Check routing tables on R1 and R2, both bird and the kernel routing tables. Also do a traceroute from a client to see where things go, or if possible log in to each and use similar to 'ip ro get <remote-ip>' to see where the next hop leads. But also be sure to do that all the way from R2. Does R2 how to get to R1 to get to the clients? And just in case, if NAT or even normal connection tracking is involved that might cause issues primarily due to the missing state on R2 where those packets are not expected. Also this is all assuming that both R1 and R2 are announcing the same prefixes and that upstream keeps on sending packets. Regars, Jeroen

1 0

iBGP and redundancy problem.
by Mike Neo 17 May '26

17 May '26

Hi, I have two bird v2 based BGP routers, connected directly by iBGP. Each router has a single link with a full BGP table. The gateway for hosts is on R1. If the ISP on R1 goes down, the hosts lose internet access, even though the internet should work via iBGP to R2, where the second ISP link is. Routes from iBGP are on R1, and iBGP has the "next hop self" parameter. Could you please advise what's missing in the configuration? Kind regards, Mike

2 1

BIRD 3.2.1 - abort/core dump on startup on FreeBSD 15.
by Robert Blayzor 12 May '26

12 May '26

Migrating from Bird 2.1.8 to 3.2.1 on FreeBSD 15 Both built from poudriere ... packages and installs fine. Worked through a MP-BGP next hop issue. BIRD appears to read the config, but then just aborts and crashes: # bird -d -c /opt/etc/bird.conf Abort trap (core dumped) bird -d -c /opt/etc/bird.conf []# dmesg pid 22604 (bird), jid 0, uid 0: exited on signal 6 (core dumped) # lldb -c bird.core /usr/local/sbin/bird (lldb) target create "/usr/local/sbin/bird" --core "bird.core" Core file '/var/tmp/bird.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'bird', stop reason = signal SIGABRT * frame #0: 0x0000000827a9c9ea libsys.so.7`__sys_thr_kill + 10 frame #1: 0x00000008225d3894 libc.so.7`__raise + 52 frame #2: 0x00000008226856f9 libc.so.7`abort + 73 frame #3: 0x000000000030f392 bird`___lldb_unnamed_symbol1881 + 146 frame #4: 0x00000000002cedb3 bird`___lldb_unnamed_symbol1281 + 1043 frame #5: 0x000000000029f2da bird`___lldb_unnamed_symbol744 + 186 frame #6: 0x000000000030c6f2 bird`___lldb_unnamed_symbol1833 + 514 frame #7: 0x000000000029f2da bird`___lldb_unnamed_symbol744 + 186 frame #8: 0x000000000030a9d8 bird`___lldb_unnamed_symbol1821 + 1960 frame #9: 0x0000000821bf6d21 libthr.so.3`___lldb_unnamed_symbol575 + 337 (lldb) -- inoc.net!rblayzor PGP: https://pgp.inoc.net/rblayzor/

2 2

Kernel export metric change can delete a route and leave a forwarding blackhole until the next kernel scan
by 水兵 12 May '26

12 May '26

# Title Kernel export metric change can delete a route and leave a forwarding blackhole until the next kernel scan # Description When a kernel-exported route changes `krt_metric`, BIRD may perform the update as delete-old plus add-new instead of an atomic replace. If the add operation fails, BIRD's source route and export view still show the route as exported, but the Linux FIB is missing the route until the next kernel protocol scan repairs it. This creates a transient RIB/FIB divergence and forwarding blackhole. # Version Reproduced with: ```text BIRD 2.18+branch.master.f0f859c26cf9 ``` # How to reproduce 1. Create a single-router Linux namespace or VM with one tested interface. ```text 10.100.0.1/24 +---------------+ | r1 | | | | eth0 | +---------------+ ``` 2. Configure a BIRD static blackhole source route, then rewrite it in the kernel export filter into a direct route with an interface, preferred source, and metric: ```bird protocol static static_src { ipv4; route 198.51.100.0/24 blackhole; } protocol kernel krt_export { ipv4 { export filter { ifname = "eth0"; krt_prefsrc = 10.100.0.1; krt_metric = 110; accept; }; }; scan time 2; } ``` 3. Confirm the route is installed in the Linux FIB: ```bash ip route show 198.51.100.0/24 ``` 4. Remove address `10.100.0.1/24` so that a later route add using `krt_prefsrc = 10.100.0.1` fails: ```bash ip addr del 10.100.0.1/24 dev eth0 ``` 5. Reconfigure the export filter so that the route metric changes from `110` to `210`, without otherwise changing the source route. 6. Observe BIRD's source route and export view, then inspect the Linux FIB before the next kernel scan: ```bash birdc show route for 198.51.100.0/24 all birdc show route export krt_export for 198.51.100.0/24 all ip route show 198.51.100.0/24 ``` 7. Restore the address and wait for the kernel scan to confirm that the route is repaired later: ```bash ip addr add 10.100.0.1/24 dev eth0 sleep 3 ip route show 198.51.100.0/24 ``` # Expected behavior BIRD should not leave the forwarding plane without the route while its control-plane/export view says the route should be exported. If the metric-changing update cannot be installed, BIRD should either preserve the old route, retry immediately when possible, or otherwise keep the control plane and FIB from diverging until the next periodic scan. # Actual behavior After the metric-changing reconfiguration, before the next kernel scan: ```text bird_source_present=True bird_export_present=True bird_export_final_metric=True bird_export_prefsrc=True kernel_present=False addr_present=False ``` The route is absent from the Linux FIB even though BIRD still reports that it should be exported. After the address is restored and the kernel protocol scan runs, BIRD installs the route again: # Additional context The suspected source path is in `sysdep/linux/netlink.c`. ` nl_allow_replace()` disallows an atomic replace when the old and new ` EA_KRT_METRIC` values differ under kernel protocol metric handling. ` krt_replace_rte()` then performs delete-old followed by add-new. If add-new fails, BIRD clears synchronization state but does not immediately recover the missing FIB route; recovery waits for the next kernel scan.

2 1

Kernel export does not repair a stale `krt_prefsrc` after an external route attribute mutation
by 水兵 12 May '26

12 May '26

# Title Kernel export does not repair a stale `krt_prefsrc` after an external route attribute mutation # Description BIRD keeps its control-plane route and kernel export view consistent with the expected route attributes, but the Linux FIB can remain stale after an externally mutated route is scanned back from the kernel. In the reproduced case, BIRD exports `198.51.20.0/24` with `krt_metric = 120 ` and `krt_prefsrc = 10.20.0.1`. An external `ip route replace` changes only the kernel route preferred source to `10.20.0.2`, while keeping the same prefix, next hop, protocol, and metric. After an unrelated interface flap and a kernel scan, BIRD still reports that the exported route should use `Kernel.prefsrc: 10.20.0.1`, but the Linux FIB remains installed with `src 10.20.0.2`. # Version Reproduced with: ```text BIRD 2.18+branch.master.f0f859c26cf9 ``` # How to reproduce 1. Create a single-router Linux namespace or VM with two interfaces. Only ` eth0` carries the tested route; `eth1` is used only to trigger an unrelated interface event. ```text 10.20.0.254 | 10.20.0.1/24 +-------------+ | r1 | | | | eth0 eth1 | +-------------+ | unrelated link ``` 2. Configure BIRD on `r1` with a static source route: ```bird protocol static static_src { ipv4; route 198.51.20.0/24 via 10.20.0.254; } ``` 3. Export the route to the kernel with a fixed metric and preferred source: ```bird protocol kernel krt_export { ipv4 { export filter { krt_metric = 120; krt_prefsrc = 10.20.0.1; accept; }; }; scan time 2; } ``` 4. Confirm BIRD initially installs the expected Linux route: ```bash ip route show 198.51.20.0/24 ``` Expected initial route: ```text 198.51.20.0/24 via 10.20.0.254 dev eth0 proto bird src 10.20.0.1 metric 120 ``` 5. Externally mutate the same kernel route to a different preferred source while keeping the same destination, next hop, protocol, and metric: ```bash ip route replace 198.51.20.0/24 via 10.20.0.254 dev eth0 proto bird src 10.20.0.2 metric 120 ``` 6. Flap the unrelated interface and wait longer than the kernel protocol scan interval: ```bash ip link set eth1 down ip link set eth1 up sleep 3 ``` 7. Compare BIRD's source/exported route view with the Linux FIB. # Expected behavior After the kernel scan, BIRD should notice that the kernel route attributes no longer match the route it exports and should repair the Linux FIB back to: ```text 198.51.20.0/24 via 10.20.0.254 dev eth0 proto bird src 10.20.0.1 metric 120 ``` # Actual behavior BIRD's source route and export view still indicate the expected route with `Kernel.prefsrc: 10.20.0.1`, but the Linux FIB remains stale: ```text 198.51.20.0/24 via 10.20.0.254 dev eth0 proto bird src 10.20.0.2 metric 120 ``` # Additional context The suspected source path is `sysdep/unix/krt.c:krt_got_route()`. The scan-side comparison checks `sync_map` and `krt_same_dest()`, but it does not compare exported route eattrs such as `krt_prefsrc`. As a result, a route with the same destination and kernel key can be treated as synchronized even though its exported attributes differ from BIRD's intended route.

1 0

Reconfiguring `import keep filtered` from off to on does not preserve already rejected routes
by 水兵 12 May '26

12 May '26

# Title Reconfiguring `import keep filtered` from off to on does not preserve already rejected routes # Description Changing a channel from `import keep filtered off` to `import keep filtered on` does not cause existing rejected routes to be reprocessed. Two histories with the same final static route, import filter, and `import keep filtered on` setting end with different filtered-route state. When the route is present before `import keep filtered` is enabled, it has already been dropped and is not re-fed after reconfiguration. When BIRD starts directly with the final configuration, the same route is retained as filtered. # Version Reproduced with: ```text BIRD 2.18+branch.master.f0f859c26cf9 ``` # How to reproduce 1. Use a single BIRD instance. No external peers are required. ```text +-------------+ | r1 | | | | BIRD static | +-------------+ ``` 2. Configure a static protocol route: ```bird protocol static static_reject { ipv4 { import filter { if net = 198.51.80.0/24 then reject; accept; }; import keep filtered off; }; route 198.51.80.0/24 unreachable; } ``` 3. Start BIRD and confirm the rejected route is not retained as filtered: ```bash birdc show protocols all static_reject ``` 4. Reconfigure only the channel option from `import keep filtered off` to `import keep filtered on`, keeping the same static route and same import filter. 5. Check the protocol counters again: ```bash birdc show protocols all static_reject birdc show route filtered protocol static_reject all ``` 6. As a control, restart BIRD directly with the final configuration (`import keep filtered on`) and the same static route/filter, then compare the same outputs. # Expected behavior Because both histories end with the same route, the same import filter, and `import keep filtered on`, BIRD should retain the rejected route as filtered in both cases. The protocol route counters should report one filtered route. # Actual behavior History A reports no retained filtered route: ```text Routes: 0 imported, 0 filtered, 0 exported, 0 preferred ``` History B reports the expected filtered route: ```text Routes: 0 imported, 1 filtered, 0 exported, 0 preferred ``` # Additional context `import keep filtered` changes how rejected routes are represented in channel state. The suspected path is `nest/proto.c:channel_reconfigure()`, which handles several channel changes but does not appear to trigger a reload/refeed for `in_keep_filtered` changes. `nest/rt-table.c:rte_update2() ` decides whether rejected routes are dropped or retained as `REF_FILTERED` based on `c->in_keep_filtered`, so changing that flag without refeeding existing routes leaves history-dependent filtered state.

1 0

Recursive BGP next-hop resolution does not fall back to a lower-preference usable IGP route
by 水兵 12 May '26

12 May '26

# Title Recursive BGP next-hop resolution does not fall back to a lower-preference usable IGP route # Description BIRD resolves a recursive BGP next hop using the current best IGP route for the next-hop address. If that best route is itself recursive, BIRD marks the BGP route as unreachable even when a lower-preference route to the same next-hop address is directly usable. In the reproduced topology, the final IGP route set contains both a higher-preference recursive static route and a lower-preference OSPF route for the BGP next-hop `/32`. The OSPF route is usable and resolves to a direct next hop, but the BGP route is still installed as unreachable. # Version Reproduced with: ```text BIRD 2.18+branch.master.f0f859c26cf9 ``` # How to reproduce 1. Build a three-router topology: ```text iBGP advertises 203.0.113.0/24 NEXT_HOP=10.0.0.2 +---------------------------+ | | +------+ +------+ | r2 | | r1 | +------+ +------+ | | OSPF, 198.51.100.0/24 | +------+ | r3 | +------+ r3 advertises OSPF stub routes: 10.0.0.2/32 172.16.0.1/32 ``` 2. On `r1`, configure the BGP channel to use recursive next-hop resolution through the IGP table: ```bird protocol bgp bgp_from_r2 { ipv4 { import all; export none; gateway recursive; igp table master4; }; local as 65000; neighbor <r2-address> as 65000; } ``` 3. On `r2`, advertise `203.0.113.0/24` to `r1` and set `bgp_next_hop = 10.0.0.2` in the export policy. 4. On `r1` and `r3`, run OSPF so that `r1` learns `10.0.0.2/32` via `r3`, reachable through `198.51.100.2` on `r1`'s OSPF-facing interface. 5. Add a higher-preference recursive static route on `r1`: ```bird route 10.0.0.2/32 recursive 172.16.0.1; ``` 6. Confirm that `r1` has both routes for `10.0.0.2/32`: - Higher-preference `static_recursive`. - Lower-preference but usable `ospf_igp`, via `198.51.100.2` on the OSPF-facing interface. 7. Inspect `r1`'s route for `203.0.113.0/24` and the Linux FIB: ```bash birdc show route for 203.0.113.0/24 all ip route show 203.0.113.0/24 ``` # Expected behavior BIRD should resolve the BGP route through the lower-preference usable OSPF route when the higher-preference route cannot provide a valid recursive next-hop result. The BGP route should remain reachable via: ```text via 198.51.100.2 on r1-eth1 ``` # Actual behavior With only the OSPF route, BIRD resolves and installs the BGP route correctly: ```text 203.0.113.0/24 unicast [bgp_from_r2 ...] * (100/20) [i] via 198.51.100.2 on r1-eth1 ``` After the higher-preference recursive static route is present, BIRD marks the same BGP route unreachable: ```text 203.0.113.0/24 unreachable [bgp_from_r2 ...] * (100) [i] ``` The Linux FIB also contains an unreachable route: ```text unreachable 203.0.113.0/24 proto bird metric 32 ``` # Additional context The suspected source path is the recursive hostentry update logic used by BGP next-hop resolution. The implementation appears to start from the current best IGP route and stop when it encounters a route with hostentry/recursive state at the best preference level, instead of continuing to search lower-preference routes that are directly usable. This makes a valid BGP route unreachable solely because a higher-preference recursive route exists for the same next-hop address.

1 0

Jump to 3.x from 2.18 - Next hop fail?
by Robert Blayzor 11 May '26

11 May '26

I have the following config that works in BIRD 2.18, when I attempted to upgrade and run 3.2.1 it exits out on the below. This appears to happen with both IBGP and EBGP peers. I'm assuming its because IPv4/IPv6 AFI's are on the same transport session... Just trying to figure out the correct "fix" here for BIRD3 ... bird[20990]: rserv1: Missing next hop address template bgp BH_CLIENT { local as MYAS; source address MYIP; ipv4 { import keep filtered on; import filter CLIENT_IN; export filter CLIENT_OUT; }; ipv6 { import keep filtered on; import filter CLIENT_IN; export filter CLIENT_OUT; }; } # protocol bgp rserv1 from BH_CLIENT { neighbor 2000:f000:1::10 as MYAS; source address MYIP6; ipv4 { import none; export none; }; ipv6 { import none; export none; }; }

1 0