KIF: Received address message for unknown interface
When doing a churn test we see bird speaker logs overwhelmed with below messages and we hit high CPU. 2026-04-20 08:19:06.304 [0001] <WARN> I/O loop cycle took 61075.339 ms for 1 events 2026-04-20 08:19:47.863 [0001] <ERR> KIF: Received address message for unknown interface 513817 Version used: v3.0.2 Source : https://github.com/CZ-NIC/bird We see similar issues in calico bird being fixed Remove interfaces that are flagged as shutdown. by axel7born · Pull Request #111 · projectcalico/bird <https://github.com/projectcalico/bird/pull/111/changes/b32135cb60855b8a73cfcc43343df215f4631bcf> Could someone one check and let me know if we have fix or work around this issue?
Hello! On Mon, Apr 27, 2026 at 02:17:10PM +0530, Kiran Katabathena wrote:
When doing a churn test we see bird speaker logs overwhelmed with below messages and we hit high CPU.
2026-04-20 08:19:06.304 [0001] <WARN> I/O loop cycle took 61075.339 ms for 1 events 2026-04-20 08:19:47.863 [0001] <ERR> KIF: Received address message for unknown interface 513817
This is a known limitation which has no easy solution because of old spaghetti. If you have half a million interfaces, even over time, it's gonna be slow. That's the reality of a linked list.
Version used: v3.0.2
Version 3.0.2 is out of support. Please upgrade because of stability, even though the speed doesn't improve in later versions.
We see similar issues in calico bird being fixed Remove interfaces that are flagged as shutdown. by axel7born · Pull Request #111 · projectcalico/bird <https://github.com/projectcalico/bird/pull/111/changes/b32135cb60855b8a73cfcc43343df215f4631bcf>
Could someone one check and let me know if we have fix or work around this issue?
What is proposed in that PR is not a good fix for the long-term. It's leaking memory and old pointers may keep pointing there. While we have a memory leak inside another function like this anyway, it may lead to various weird problems when interfaces are referenced from config by name, or when referenced from route next hops. It is not easy to fix though. The original architecture expected the interfaces to be pretty stable, thus we never remove any interface structure because it's a non-problem for regular deployments. There is no refcounting of interfaces, they simply get created and they live forever. A thorough rework of the interface subsystem is in our long-term plan but it's, to put it mildly, a can of worms. We expect to tackle this task in the core BIRD team with all the senior knowledge of BIRD insides, probably in 2027 or 2028. Our current priorities are stability, EVPN and API. There is a possibility to pull the interface subsystem rework earlier, maybe Q1/2027, but that would definitely need sending some money our way, preferably in the form of a long-term support contract[0], so that we may even consider growing the core team. Please note that even if somebody wanted to contribute this rework from outside the core BIRD team, we'd have to dedicate a significant amount of people-time anyway to coordinate and review it properly, but technically, that may also speed things up. Yet, there are still several pieces of code which we should have merged long time ago, and we haven't merged them yet simply because we need to dedicate an uninterrupted stretch of time long enough to do the job. Maybe that's too blunt of me but it is what it is. Happy routing! Maria [0] BIRD Support: https://bird.nic.cz/commercial-services/#deployments-dc -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
participants (2)
-
Kiran Katabathena -
Maria Matejka