netdev - Re: [PATCH net-next] ipv4/fib: send RTM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6b53e392-ca84-c50b-9d77-4f89e801d4f3@6wind.com>
Date: Fri, 28 Jul 2023 15:01:18 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Stephen Hemminger <stephen@...workplumber.org>,
 Hangbin Liu <liuhangbin@...il.com>
Cc: Ido Schimmel <idosch@...sch.org>, David Ahern <dsahern@...nel.org>,
 netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Thomas Haller <thaller@...hat.com>
Subject: Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush
 fib

Le 25/07/2023 à 18:36, Stephen Hemminger a écrit :
> On Tue, 25 Jul 2023 16:20:59 +0800
> Hangbin Liu <liuhangbin@...il.com> wrote:
> 
>> On Mon, Jul 24, 2023 at 08:48:20AM -0700, Stephen Hemminger wrote:
>>> On Mon, 24 Jul 2023 16:56:37 +0800
>>> Hangbin Liu <liuhangbin@...il.com> wrote:
>>>   
>>>> The NetworkManager keeps a cache of the routes. Missing/Wrong events mean that
>>>> the cache becomes inconsistent. The IPv4 will not send src route delete info
>>>> if it's bond to other device. While IPv6 only modify the src route instead of
>>>> delete it, and also no notify. So NetworkManager developers complained and
>>>> hope to have a consistent and clear notification about route modify/delete.  
>>>
>>> Read FRR they get it right. The routing daemons have to track kernel,
>>> and the semantics have been worked out for years.  
>>
>> Yes, normally the routing daemon need to track kernel. On the other hand,
>> the kernel also need to make a clear feedback. The userspace developers may
>> not know the kernel code very well. The unclear/inconsistent notification
>> would make them confused.
> 
> Right, that should be addressed by clearer documentation of the semantics
> and the rational.
> 
Frankly, it's quite complex, there are corner cases.

When an interface is set down, the routes associated to this interface should be
removed. This is the simple part.
But for ecmp routes, there are several cases:
 - if all nh use this interface: the routes are deleted by the kernel;
 - if only some nh uses this interface :
   + if all other nh already point to a down interface: the route are deleted by
the kernel;
   + if at least one nh points to an up interface: the nh are temporarily disabled.

Managing a cache with this is not so obvious ;-)

My two cents,
Nicolas