netdev - Re: [PATCH] neigh: Support filtering neighbours for L3 slave

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 3 Aug 2021 08:42:27 -0600
From:   David Ahern <dsahern@...il.com>
To:     Lahav Schlesinger <lschlesinger@...venets.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        dsahern@...nel.org
Subject: Re: [PATCH] neigh: Support filtering neighbours for L3 slave

On 8/3/21 12:47 AM, Lahav Schlesinger wrote:
>>>> you can not special case VRFs like this, and such a feature should apply
>>>> to links and addresses as well.
>>>
>>> Understandable, I'll change it.
>>> In this case though, how would you advice to efficiently filter
>>> neighbours for interfaces in the default VRF in userspace (without
>>> quering the master of every interface that is being dumped)?
>>> I reckoned that because there's support in iproute2 for filtering based
>>> on a specific VRF, filtering for the default VRF is a natural extension
>>
>> iproute2 has support for a link database (ll_cache). You would basically
>> have to expand the cache to track any master device a link is associated
>> with and then fill the cache with a link dump first. It's expensive at
>> scale; the "no stats" filter helps a bit.
>>
>> This is the reason for kernel side filtering on primary attributes
>> (coarse grain filtering at reasonable cost).
>>
> 
> Nice, didn't know about the ll_cache.
> Does filtering based on being in the default VRF is something you think
> can be merged into iproute2 (say with "novrf" keyword, following the "nomaster"
> convention below - e.g. "ip link show novrf")?
> If so I'll add it as a patch to iproute2.

yes. There is also an outstanding request to show the vrf of neighbor
entries (e.g., add a new column at the end with vrf) when doing a full dump.