netdev - Re: [PATCH net-next] ipv6: Add sysctl for RA default route table number

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]

Message-ID: <bd21f382-c9f4-23cd-3775-3531774d58a8@gmail.com>
Date:   Wed, 30 Jun 2021 08:25:05 -0600
From:   David Ahern <dsahern@...il.com>
To:     antony.antony@...unet.com
Cc:     Eyal Birger <eyal.birger@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
        Christian Perle <christian.perle@...unet.com>
Subject: Re: [PATCH net-next] ipv6: Add sysctl for RA default route table
 number

On 6/29/21 11:34 PM, Antony Antony wrote:
> On Tue, Jun 29, 2021 at 09:34:22 -0600, David Ahern wrote:
>> On 6/29/21 8:05 AM, Eyal Birger wrote:
>>> Hi Antony,
>>>
>>> On 29/06/2021 15:53, Antony Antony wrote:
>>>> Hi David,
>>>>
>>>> On Fri, Jun 25, 2021 at 22:47:41 -0600, David Ahern wrote:
>>>>> On 6/25/21 1:04 AM, Antony Antony wrote:
>>>>>> From: Christian Perle <christian.perle@...unet.com>
>>>>>>
>>>>>> Default routes learned from router advertisements(RA) are always placed
>>>>>> in main routing table. For policy based routing setups one may
>>>>>> want a different table for default routes. This commit adds a sysctl
>>>>>> to make table number for RA default routes configurable.
>>>>>>
>>>>>> examples:
>>>>>> sysctl net.ipv6.route.defrtr_table
>>>>>> sysctl -w net.ipv6.route.defrtr_table=42
>>>>>> ip -6 route show table 42
>>>>>
>>>>> How are the routing tables managed? If the netdevs are connected to a
>>>>> VRF this just works.
> 
> Ah! I figured it out what you were hinting at! Sorry, I didn't know about
> IFLA_VRF_TABLE attribute of link type vrf.
> 
> I also found the Documentation/networking/vrf.rst and red the commits
> including the iproute2 commits. Thanks for the hint.
> 
> It looks like the vrf->tb_id is used for both v4 and v6 routing?
> We are only looking at V6 routing, because the table only have v6 routes.

That's fine. There is no requirement to use both.

> 
>>>>
>>>> The main routing table has no default route. Our scripts add routing
>>>> rules
>>>> based on interfaces. These rules use the specific routing table where
>>
>> That's the VRF use case -- routing rules based on interfaces. Connect
>> those devices to VRFs and the RA does the right thing.
>>
>>>> the RA
>>>> (when using SLAAC) installs the default route. The rest just works.
>>>
>>> Could this be a devconf property instead of a global property? seems
> 
> yes adding to ipv6_devconf.cnf.ra_defrtr_tble is interesting.
> 
> I may propose a general solution that can replaces 
> vrf_fib_table(retrun vrf->tb_id).

no. You missed my point. No change is needed to VRF at all. No change is
needed for this use case at all if you simply:

ip link add VRF type vrf table TABLE
ip link set VRF up
ip link set dev <RA DEV> vrf VRF

You are good. RAs are processed and added to TABLE.

your proposed change is not needed.