netdev - Re: [RFC v4 3/5] vxlan: add support for underlay in non-default 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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <570aef1e-2d72-9248-05c9-2187bddcabb0@cumulusnetworks.com>
Date:   Thu, 22 Nov 2018 10:19:32 -0700
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Alexis Bauvin <abauvin@...leway.com>, roopa@...ulusnetworks.com
Cc:     netdev@...r.kernel.org, akherbouche@...leway.com
Subject: Re: [RFC v4 3/5] vxlan: add support for underlay in non-default VRF

On 11/21/18 6:07 PM, Alexis Bauvin wrote:
> Creating a VXLAN device with is underlay in the non-default VRF makes
> egress route lookup fail or incorrect since it will resolve in the
> default VRF, and ingress fail because the socket listens in the default
> VRF.
> 
> This patch binds the underlying UDP tunnel socket to the l3mdev of the
> lower device of the VXLAN device. This will listen in the proper VRF and
> output traffic from said l3mdev, matching l3mdev routing rules and
> looking up the correct routing table.
> 
> When the VXLAN device does not have a lower device, or the lower device
> is in the default VRF, the socket will not be bound to any interface,
> keeping the previous behaviour.
> 
> The underlay l3mdev is deduced from the VXLAN lower device
> (IFLA_VXLAN_LINK).
> 
> +----------+                         +---------+
> |          |                         |         |
> | vrf-blue |                         | vrf-red |
> |          |                         |         |
> +----+-----+                         +----+----+
>      |                                    |
>      |                                    |
> +----+-----+                         +----+----+
> |          |                         |         |
> | br-blue  |                         | br-red  |
> |          |                         |         |
> +----+-----+                         +---+-+---+
>      |                                   | |
>      |                             +-----+ +-----+
>      |                             |             |
> +----+-----+                +------+----+   +----+----+
> |          |  lower device  |           |   |         |
> |   eth0   | <- - - - - - - | vxlan-red |   | tap-red | (... more taps)
> |          |                |           |   |         |
> +----------+                +-----------+   +---------+
> 
> Signed-off-by: Alexis Bauvin <abauvin@...leway.com>
> Reviewed-by: Amine Kherbouche <akherbouche@...leway.com>
> Tested-by: Amine Kherbouche <akherbouche@...leway.com>
> ---
>  drivers/net/vxlan.c                           | 32 +++++--
>  .../selftests/net/test_vxlan_under_vrf.sh     | 90 +++++++++++++++++++
>  2 files changed, 114 insertions(+), 8 deletions(-)
>  create mode 100755 tools/testing/selftests/net/test_vxlan_under_vrf.sh
> 

Reviewed-by: David Ahern <dsahern@...il.com>

Thanks for adding the test case; I'll try it out next week (after the
holidays).