[FROG] kernel default route inactive when installed after FRR 7.5 starts

[Andrew J. Schorr]

Hi,

I'm upgrading a bunch of Linux routers from CentOS 7 to Rocky 8, and as part of
the upgrade, quagga seems to have been replaced by frr.  For the most part,
everything works fine, but I've encountered one problem. I've got a router that
picks up a default route via DHCP from a cable modem. With quagga, this default
route was accepted and redistributed via OSPF. But with FRR, it sometimes
says that the route is "inactive", which horks my routing.

I built the Fedora 34 quagga package and ran that and saw these results
using quagga-1.2.4-17.el8.x86_64:

Hello, this is Quagga (version 1.2.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

ti14# show ip route 0.0.0.0/0
Routing entry for 0.0.0.0/0
  Known via "ospf", distance 110, metric 103, tag 0, vrf 0
  Last update 00:00:13 ago
  >  192.168.39.5, via lan0.9

Routing entry for 0.0.0.0/0
  Known via "kernel", distance 0, metric 0, tag 0, vrf 0, best, fib
  >* 207.237.112.1, via lan1

But with the standard frr-7.5-4.el8.x86_64.rpm, it sometimes marks
the kernel route as inactive when it starts, and uses the ospf route instead:

Hello, this is FRRouting (version 7.5).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

ti14# show ip route 0.0.0.0/0
Routing entry for 0.0.0.0/0
  Known via "ospf", distance 110, metric 103, best
  Last update 00:04:42 ago
  * 192.168.39.5, via lan0.9, weight 1

Routing entry for 0.0.0.0/0
  Known via "kernel", distance 0, metric 0
  Last update 00:05:42 ago
  * 207.237.112.1, via lan1 inactive

When it's working properly, typically after a restart, I see:

Hello, this is FRRouting (version 7.5).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

ti14# show ip route 0.0.0.0/0
Routing entry for 0.0.0.0/0
  Known via "ospf", distance 110, metric 103
  Last update 00:00:01 ago
    192.168.39.5, via lan0.9, weight 1

Routing entry for 0.0.0.0/0
  Known via "kernel", distance 0, metric 0, best
  Last update 00:00:08 ago
  * 207.237.112.1, via lan1

My best guess is that there's some kind of timing issue here. When
the system boots up with FRR, the FRR daemons start before DHCP
installs the default route. That seems to lead to its being marked inactive.
If I then restart FRR, it accepts the kernel default route.

Is this perhaps fixed in a newer version of FRR? Or am I doing something
stupid? Is there a patch for this? If not, I'm going to need to revert
to quagga.

Thanks,
Andy