netdev - Re: [PATCH] net: allow interface to be set into vrf if a vif in same vrf

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>] [day] [month] [year] [list]

Date:   Mon, 26 Feb 2018 13:43:37 -0700
From:   David Ahern <dsahern@...il.com>
To:     mmanning@...tta.att-mail.com, Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: allow interface to be set into vrf if a vif in same
 vrf

On 2/26/18 11:05 AM, Mike Manning wrote:
> On 2/26/18 9:48 AM, Mike Manning wrote:
> 
>> Setting an interface into a vrf fails with 'RTNETLINK answers: File
>> exists' if one of its vifs is already in the same vrf. As the vrf is an
>> upper device of the vif, it is also showing up as an upper device of
>> the interface itself. The solution is to restrict this check to devices
>> other than master. As only one master device can be linked to a device,
>> in this case the check is for the upper device (vrf) to be linked to as
>> being the master device rather than any other upper device.
> 
> I'm not understanding what you mean by vif in this context. Can you
> elaborate and show an example set of commands?
> 
> 
> Here is an example of a vrf (green), a physical if (ens12) and a virtual if (vif) on vlan 10 (ens12.10):

ok, so by vif you mean a vlan subinterface.


> 
> # ip link show dev vrfgreen
> 14: vrfgreen: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP mode DEFAULT group default qlen 1000
>     link/ether b2:9a:92:88:a8:fe brd ff:ff:ff:ff:ff:ff
> # ip link show dev ens12
> 3: ens12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
>     link/ether 52:54:00:4c:a0:45 brd ff:ff:ff:ff:ff:ff
> # ip link add link ens12 ens12.10 type vlan id 10
> # ip link add link ens12 ens12.20 type vlan id 20
> 
> This works fine:
> 
> # ip link set dev ens12 master vrfgreen
> # ip link show dev ens12
> 3: ens12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vrfgreen state UP mode DEFAULT group default qlen 1000
>     link/ether 52:54:00:4c:a0:45 brd ff:ff:ff:ff:ff:ff
> # ip link set dev ens12 nomaster
> 
> But if one of the vifs is first set into the same vrf, then subsequently setting the parent into the vrf fails:
> 
> # ip link set dev ens12.10 master vrfgreen
> # ip link show dev ens12.10
> 39: ens12.10@...12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vrfgreen state UP mode DEFAULT group default qlen 1000
>     link/ether 52:54:00:4c:a0:45 brd ff:ff:ff:ff:ff:ff
> # ip link set dev ens12 master vrfgreen
> RTNETLINK answers: File exists
> # 
> 
> The workaround is to move the vif back into the default VRF beforehand, but for this one first has to shut the vif so as to avoid the risk of traffic leaking from the VRF.
> 
> This fix is proposed to avoid that messy workaround.

Ok, I get the problem now. I would like to see the above comments and
series of commands added to the commit message.

I need to think about the change with respect to other stacking options.
Somewhere I have commands that cover a lot of permutations.