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

[Donald Sharp]

Can you add `debug zebra rib detail` to the top of your log file and
recreate this issue?  We should have special code that always allows the
kernel route received over netlink.  I would be interested in understanding
what is going wrong.

donald

On Sat, Nov 13, 2021 at 6:04 PM Andrew J. Schorr <
aschorr at telemetry-investments.com> wrote:

> 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
>
> _______________________________________________
> frog mailing list
> frog at lists.frrouting.org
> https://lists.frrouting.org/listinfo/frog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20211114/d6332159/attachment.htm>