Kernel default route stays in Zebra table even in WAN interface is down pfSense community version

[badgerdog]

Description

When trying to run failover with default-information originate (Redistribute Default Route) from FRR OSPF to neighbors, when the primary path fails, by shutting down its wan interface, the default kernel route remains in the Zebra table causing the route to continue to be advertised to neighbors. This falsely notifies neighbors to use a downed device/interface/route for their default gateway. Note that the kernel route will clear if the OSPF process is restarted, but otherwise will remain in the table indefinitely

Kernel route with WAN interface up:

K>* 0.0.0.0/0 [0/0] via 24.94.72.1, em0, 00:50:34
O>* 10.0.0.0/24 [110/101] via 192.168.0.1, em1, weight 1, 00:50:23
O>* 10.0.15.0/24 [110/101] via 192.168.0.1, em1, weight 1, 00:50:23
C>* 24.94.72.0/21 [0/1] is directly connected, em0, 00:50:34

Kernel route with same WAN interface down:

K>* 0.0.0.0/0 [0/0] via 24.94.72.1, em0, 00:53:42
O>* 10.0.0.0/24 [110/101] via 192.168.0.1, em1, weight 1, 00:53:31
O>* 10.0.15.0/24 [110/101] via 192.168.0.1, em1, weight 1, 00:50:23
**note that connected wan is no longer in the table here

Version

Running pfSense community version:
2.7.2-RELEASE (amd64)
built on Mon Mar 4 9:53:00 HST 2024
FreeBSD 14.0-CURRENT
and FRR package 2.0.2_1 with installed dependencies [frr9-9.0.2](https://freshports.org/net/frr9) and [frr9-pythontools-9.0.2](https://freshports.org/net/frr9-pythontools)

How to reproduce

Choose multiple ospf neighbors to participate in area 0 and choose, on the FRR OSPF configuration tab and section "Default Route Redistribution, to be the default route for all it's neighbors by telling it to "redistribute default route" in its ospf configuration.

Note that the neighbors are receiving the default route in their ospf routing table.

Now do a hard or software shutdown of the default gateway (pfSense) WAN interface and you';; not that it still maintains the default route 0.0.0.0/0 in its kernel table and that ospf continues to advertise this default rout to its neighbors - even though the interface is down

Expected behavior

Expected behavior is that the kernel default route (0.0.0.0/0) for the downed interface, should be immediately removed from the Zebra table and ospf, or any other routing protocol, and should stop advertising it to its neighbors by its protocol specific methods of default-information originate

Actual behavior

Kernel route with WAN interface up:

K>* 0.0.0.0/0 [0/0] via 24.94.72.1, em0, 00:50:34
O>* 10.0.0.0/24 [110/101] via 192.168.0.1, em1, weight 1, 00:50:23
O>* 10.0.15.0/24 [110/101] via 192.168.0.1, em1, weight 1, 00:50:23
C>* 24.94.72.0/21 [0/1] is directly connected, em0, 00:50:34

Kernel route with same WAN interface down:

K>* 0.0.0.0/0 [0/0] via 24.94.72.1, em0, 00:53:42
O>* 10.0.0.0/24 [110/101] via 192.168.0.1, em1, weight 1, 00:53:31
O>* 10.0.15.0/24 [110/101] via 192.168.0.1, em1, weight 1, 00:50:23
**note that connected wan is no longer in the table here

Here a neighbor is still receiving the default route - will continue indefinitely in this state:

sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is 192.168.0.254 to network 0.0.0.0
*** note her that 192.168.0.254 is the pfSense router with the WAN interface shut down

O*E2 0.0.0.0/0 [110/10] via 192.168.0.254, 00:00:06, Vlan1
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.0.0.0/24 is directly connected, Vlan10
L 10.0.0.1/32 is directly connected, Vlan10
C 10.0.15.0/24 is directly connected, Vlan15
L 10.0.15.1/32 is directly connected, Vlan15

Additional context

I'm pretty sure this isn't working right but might be as it should. Please fix if this is not operating correctly as suspected. THANKS!!!!

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[badgerdog]

I just stumbled across this related issue open in May of 2023... over a year ago and still no progress or action taken on this issue report - "Kernel routes are not updated properly in zebra RIB / nhg nexthop check is wrong #13561" This is essentially my particular issue as well as the kernel refuses to remove the default route from the Zebra table even is there is no address on the interface or if the interface is physically or logically down. This is a terrible problem that prevents properly using the default-information originate with any of the routing protocols that support it. Since the kernel refuses to release the default route on a link failure, it falsely announces that it owns the default route....

[donaldsharp]

There have been some fixes in latest have you tried something newer than 9.0.2? I would recommend something in 10.1