Hi, I would enable debug in bird to see if it logs the change. Also run "ip mon" to see netlink activity, and strace on the bird process to see if it is bird who actually removes the route. In a test setup it is reasonable to shorten the scan time. Regards, Alexander On Sun, Aug 31, 2025 at 1:02 AM Alexander Javoronkov <nmi@nmi.ru> wrote:
Greetings, I have stumbled on a problem with the new (v3) BIRD. I've been using v2 (still using 2.15.1 on old systems) over the years without problems.
The kernel4 protocol is defined with the following options: * persist off; (I need the routes to exist only when the BIRD is running) * scan time 86400; (BIRD v2 had a very hard time scanning Full View routing tables, so I have incremented this number) * learn off; (I only need to export routes to the kernel)
// Disregard the full view comment, I am having a problem even with a simplest setup with 1 or 2 routes.
"birdcl show route export kernel4" shows that routes are supposed to be exported to the kernel: 10.0.4.0/24 unicast [users 16:43:23.752 from fe80::be24:11ff:fe00:303] * (100) [AS65004i] via 10.0.3.3 on eth1
However, when I check the routes (ip -4 r), they are not there. If I run the "birdcl configure", the routes do not appear. If I restart the protocol with "birdcl restart kernel4", I start to see the routes in the routing table. Some time passes (something about an hour) and they disappear (without a single message in the logs).
Please advise how can I further debug/fix this problem.
LXC, CentOS 9 Stream, bird-3.1.2-1.el9.x86_64