Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush fib

David Ahern
2023-09-13T14:41:07Z

On 9/13/23 1:58 AM, Nicolas Dichtel wrote:
> Le 11/09/2023 à 11:50, Thomas Haller a écrit :
> [snip]
>> - the fact that it isn't fixed in more than a decade, shows IMO that
>> getting caching right for routes is very hard. Patches that improve the
>> behavior should not be rejected with "look at libnl3 or FRR".
> +1
>
> I just hit another corner case:
>
> ip link set ntfp2 up
> ip address add 10.125.0.1/24 dev ntfp2
> ip nexthop add id 1234 via 10.125.0.2 dev ntfp2
> ip route add 10.200.0.0/24 nhid 1234
>
> Check the config:
> $ ip route
> <snip>
> 10.200.0.0/24 nhid 1234 via 10.125.0.2 dev ntfp2
> $ ip nexthop
> id 1234 via 10.125.0.2 dev ntfp2 scope link
>
>
> Set the carrier off on ntfp2:
> ip monitor label link route nexthop&
> ip link set ntfp2 carrier off
>
> $ ip link set ntfp2 carrier off
> $ [LINK]4: ntfp2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
> DOWN group default
> link/ether de:ed:02:67:61:1f brd ff:ff:ff:ff:ff:ff
>
> => No nexthop event nor route event (net.ipv4.nexthop_compat_mode = 1)

carrier down is a link event and as you show here, link events are sent.

>
> 'ip nexthop' and 'ip route' show that the nexthop and the route have been deleted.

nexthop objects are removed on the link event; any routes referencing
those nexthops are removed.

>
> If the nexthop infra is not used (ip route add 10.200.0.0/24 via 10.125.0.2 dev
> ntfp2), the route entry is not deleted.
>
> I wondering if it is expected to not have a nexthop event when one is removed
> due to a carrier lost.
> At least, a route event should be generated when the compat_mode is enabled.

compat_mode is about expanding nhid into the full, legacy route
attributes. See 4f80116d3df3b