FRR randomly does not apply a route received from OSPF neighbor (8.5.4)

[Rom1kz]

using quagga many years, but now starting from ubuntu 22.04 there is no native package
so, i've tried to migrate to FRR and faced a few problem

basically native frr package of version 7.2 for ubuntu 20.04 (5.4.0-126-generic) did not worked properly at all (not applied a single route from neighbors)
then i updated to version 8.5.4 and now FRR may not apply (or lose after a while) random route
then i tried ubuntu 22.04 (5.15.0-91-generic) and still no luck

8.5.4 version is installed on each side
is this a bug or i miss some important things ? did not find any similar solved issue ..

[donaldsharp]

Perhaps you could include your topology as well as what your config is? As it is all we have is a it's not working.

[Rom1kz]

ok, here is my simple topology

config ubuntu 22.04

!
frr version 8.5.4
frr defaults traditional
!
hostname xberlin-ospf
password secret
log stdout
log syslog informational
!
!
!
!
!
interface br.100
 ip ospf cost 10
 no ip ospf passive
exit
!
!
interface dum101
 ip ospf cost 100
 no ip ospf passive
exit
!
!
interface tun100
 ip ospf network point-to-multipoint
 ip ospf cost 1000
 ip ospf mtu-ignore
 no ip ospf passive
exit
!
!
interface tun110
 ip ospf network point-to-multipoint
 ip ospf cost 200
 ip ospf hello-interval 5
 ip ospf dead-interval 20
 no ip ospf passive
exit
!
!
interface tun111
 ip ospf network point-to-multipoint
 ip ospf cost 200
 ip ospf hello-interval 1
 ip ospf dead-interval 4
 no ip ospf passive
exit
!
!
router ospf
 passive-interface default
 network 10.12.0.0/16 area 0
 network 10.128.0.0/31 area 0
 network 10.128.0.10/31 area 0
 network 10.128.0.12/31 area 0
 network 192.168.40.0/24 area 0

exit

config from one of 20.04 machine

Current configuration:
!
! loaded from 7.2.1
frr version 8.5.4
frr defaults traditional
!
hostname xnew-ospf
password 111
!
!
!
!
!
interface eno2
 no ip ospf passive
exit
!
!
interface tun110
 ip ospf network point-to-multipoint
 ip ospf cost 200
 ip ospf hello-interval 5
 ip ospf dead-interval 20
 no ip ospf passive
exit
!
!
router ospf
 passive-interface default
 network 10.10.10.0/24 area 0
 network 10.128.0.10/31 area 0
 network 192.168.33.0/24 area 0

exit

so as i said before every host may randomly lose a single route from time to time, for example, few days ago ubuntu 22.04 host lose a 192.168.33.0/24 route (which was present in sh ip ospf route table) and host 20.04 did not apply route to system kernel to network 10.12.0.0/16 (as on picture from first post) and packets goes to default route...
thus FRR do not make alternative route cuz it think the right route is already persist in system (but it is not)

the problem is solved when i do
systemctl restart frr or clear ospf process
but after a while (i think after ospf link down then up) the problem may return

btw, cisco never lose a route )))

[Rom1kz]

today i get this problem again
one of 20.04 server lose the 10.12.0.0/16 route when ospf link down then up

as u can see system kernel does not contain a route to network 10.12/16

looks like frr did not apply this route when get it from ospf link (when it got back online after short downtime)

so, what should i do ?
write my own script to compare ospf table with kernel table and then apply the routes manually ? it sounds like a joke
this is not what dynamic routing was actually made for..

[Rom1kz]

one more note i saw for the last 2 weeks
the problem is occurs only with 10/8 subnets and no matter how wide the single subnet is
frr may lose 10.0.0.0/16 or 10.0.0.0/31 subnet
i set all my primary nets to 192.168/16 subnets and problem did not occur until now
the nets who in 10/8 are still disappeared time to time

[Nuitari]

I have the same problem, some routes randomly does not get applied from FRR/OSPF to the router.

We have 9 Ubuntu 22.04 that link together using gvpe, establishing a full mesh network.

show ip ospf route sees all the routes that the network and mesh have.
But ip route in bash has missing routes. All affected routes so far are subnets of 10.0.0.0/8.

In all cases, we see some of the routes, but not all routes of a particular router.

[Nuitari]

One thing I noticed is that it always tend to be the same routes that are problematic.

[t500s]

I have the same problem and debug logs don't show anything.

[opsec]

I've seen something similar with 8.5.6, changing frr to frr 9.1.2 (on freebsd) and it worked.