OSPF and kernel does not have the same opinion of the routing table

[mattiaswal]

Current Behavior

Only seen on the yangerd branch, there the test never passes:

09:26:41 infamy0:test # ./case/routing/route_pref_ospf/test.py 
# Starting (2026-05-29 11:23:11)
# PC:      host
#     mgmt2:   d2a
#     data2:   d2b
#     R2_ospf: d2c
#     mgmt1:   d1a
#     data1:   d1b
#     R1_ospf: d1c
# R1:      dut1
#     link:    e8
#     mgmt:    e1
#     data:    e2
#     ospf:    e3
# R2:      dut2
#     mgmt:    e1
#     data:    e2
#     ospf:    e3
#     link:    e5
# 
# Waiting for DUTs to become reachable...
# Probing dut1 on port d1a for IPv6LL mgmt address ...
# Testing using RESTCONF
# YANG models downloaded.
# Waiting for DUTs to become reachable...
# Probing dut2 on port d2a for IPv6LL mgmt address ...
# Testing using RESTCONF
# YANG models downloaded.
ok 1 - Set up topology and attach to target DUTs
ok 2 - Set up TPMR between R1ospf and R2ospf
ok 3 - Configure targets
ok 4 - Set up persistent MacVlan namespaces
# Waiting for OSPF and static routes...
ok 5 - Wait for OSPF and static routes
not ok 6 - Verify connectivity from PC:data1 to PC:data2 via OSPF
# Exiting (2026-05-29 11:23:15)
#   File "/home/lazzer/src/github.com/kernelkit/infix/test/./case/routing/route_pref_ospf/test.py", line 182, in <module>
#     assert "192.168.60.2" in hops, f"Path does not use expected OSPF route: {hops}"
#            ^^^^^^^^^^^^^^^^^^^^^^
# Path does not use expected OSPF route: ['192.168.10.1', '192.168.50.2', '192.168.20.22']
1..6
11:23:16 infamy0:test # 

The route should go throught the OSPF link, but when looking at the routing table we can see, that
zebra thinks the OSPF route is installed in the kernel, but the kernel only have the static route.

admin@R1:/> show ip route
   DESTINATION            PREF NEXT-HOP         PROTO     UPTIME
>  192.168.10.0/24         0/0 e2               direct  01:55:37
>  192.168.10.1/32         0/0 e2               direct  01:55:37
>  192.168.20.0/24       110/0 192.168.60.2     ospfv2  02:06:12
   192.168.20.0/24       120/0 192.168.50.2     static  01:55:37
>  192.168.50.0/24         0/0 e8               direct  01:55:38
>  192.168.50.1/32         0/0 e8               direct  01:55:38
>  192.168.60.0/24         0/0 e3               direct  01:55:37
>  192.168.60.1/32         0/0 e3               direct  01:55:37

admin@R1:/> 
admin@R1:/> 
admin@R1:~$ ip route
192.168.10.0/24 dev e2 proto kernel scope link src 192.168.10.1 
192.168.20.0/24 nhid 508 via 192.168.50.2 dev e8 proto static metric 20 
192.168.50.0/24 dev e8 proto kernel scope link src 192.168.50.1 
192.168.60.0/24 dev e3 proto kernel scope link src 192.168.60.1 
admin@R1:~$ cat /var/

[troglobit]

@ CCB: Quite serious issue, but since we've not seen it on main (yet!) we decided in the team to not classify this as a blocker for the v26.05 release. Clear candidate though for backporting if we find the root cause.