I sent the liebot to do some iteration on the problem and it figured out problem was caused by change in route comparison logic in 182a97f5e, comparing by version caused same routes to be re-evaluated over and over again and after adding extra comparison (attached patch, I don't know C nowhere near enough to vouch for it but it at least shows the problem clearly) I also attach the test script used for bisect Cheers, Mariusz On Fri, 10 Jul 2026 18:31:42 +0200 Maria Matejka <maria.matejka@nic.cz> wrote:
This smells of a runaway hostentry resolution cycle or something like that. Do you have some "minimal reproducer" then, which causes this godzilla to emerge? It is probably not easy to fix but we'd like to try.
Thanks!
Maria
On Fri, Jul 10, 2026 at 05:58:43PM +0200, Mariusz Gronczewski wrote:
On Fri, 10 Jul 2026 17:23:54 +0200 Mariusz Gronczewski <xani+bird@devrandom.pl> wrote:
Now 0.0.0.0/0 isnt imported from any peer (dropped on filters), and only generated in static and then distributed to OSPF:
That was incorrect. I had kernel import filter set to all so it imported 0.0.0.0/0 route
and kernel export filter also allowed 0.0.0.0/0 route
however fixing that (no 0.0.0.0/0 exported to kernel any more) didn't fix the problem
removing all but one generated route
protocol static generated { ipv4 { table generated_t;
}; check link; igp table master4; route 193.200.227.0/24 blackhole; route 194.50.132.0/22 blackhole; route 0.0.0.0/0 recursive 8.8.8.8 { preference=500;
};
};
seems to fix it however I don't know why... the previous config just showed 0.0.0.0/0 in bird with multiple hops based on preference.
-- Mariusz Gronczewski (XANi) <xani+bird@devrandom.pl> GnuPG: 0xEA8ACE64 https://devrandom.eu
-- Mariusz Gronczewski (XANi) <xani+bird@devrandom.pl> GnuPG: 0xEA8ACE64 https://devrandom.eu