Why do leaked routes from vrfs cause RTM_DELNEIGH events?

[f0o]

I'm on FRR 10.0 and Ubuntu 22.04 - and since upgrade to 10.0 I notice a lot of [YK42S-VD2K1] Rx RTM_DELNEIGH family ipv4 IF IBGP(12) vrf IBGP(12) IP 213.111.87.17 followed by [TDS34-MNEJW] Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring.

I'm experiencing packet-loss about the same time those events are posted.

They dont seem to be related to any BGP route updates and in this example 213.111.87.17 is completely unknown to me and not any directly attached device whatsoever.

I'm a bit confused what NEIGH means in this context as it's not an iproute2 neighbor nor a route.

I'm trying to understand why zebra tries to delete a single IP neighbor from an interface that has no neighbors to begin with and why that causes packet loss. The log was just one example, when this happens there are about 10k of similar logs emitted. All of them single IPs, all of them RTM_DELNEIGH, all of them seemingly random IPs (not a prefix)

[f0o]

I'm starting to believe this was caused by gc_thresh[1,2,3] sysctl settings.

I noticed our gc_thresh2 and 3 are the same as https://github.com/FRRouting/frr/blob/master/doc/user/Useful_Sysctl_Settings.md?plain=1 but since gc_thresh1 wasnt defined it defaulted to 128.

My best guess right now is that thresh2/3 was hit and then everything was removed down to 128 causing packetloss.

I'm still unsure/confused why public addresses that are routed-only end up in any niegh tables and I cannot find any when I query iproute2 directly. All I see are my local aggregates and peers.

[f0o]

So this theory didnt hold up - Although I am no longer getting tons of RTM_DELNEIGH log entries I'm still getting the occasional packetloss just like before.

Back to the drawing board on that particular issue.

I'm still curious to know why routed public IPs end up as neighbors in my kernel tho. Anyone knows?