netdev - Re: [PATCH v7 0/4] Add VRF support for VXLAN underlay

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: <20181203.141644.507005457248788739.davem@davemloft.net>
Date:   Mon, 03 Dec 2018 14:16:44 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     abauvin@...leway.com
Cc:     dsa@...ulusnetworks.com, roopa@...ulusnetworks.com,
        stephen@...workplumber.org, netdev@...r.kernel.org,
        akherbouche@...leway.com
Subject: Re: [PATCH v7 0/4] Add VRF support for VXLAN underlay

From: Alexis Bauvin <abauvin@...leway.com>
Date: Mon,  3 Dec 2018 10:54:37 +0100

> We are trying to isolate the VXLAN traffic from different VMs with VRF as shown
> in the schemas below:
 ...a
> We faced some issue in the datapath, here are the details:
> 
> * Egress traffic:
> The vxlan packets are sent directly to the default VRF because it's where the
> socket is bound, therefore the traffic has a default route via eth0. the
> workarount is to force this traffic to VRF green with ip rules.
> 
> * Ingress traffic:
> When receiving the traffic on eth0.2030 the vxlan socket is unreachable from
> VRF green. The workaround is to enable *udp_l3mdev_accept* sysctl, but
> this breaks isolation between overlay and underlay: packets sent from
> blue or red by e.g. a guest VM will be accepted by the socket, allowing
> injection of VXLAN packets from the overlay.
> 
> This patch serie fixes the issues describe above by allowing VXLAN socket to be
> bound to a specific VRF device therefore looking up in the correct table.

Series applied to net-next, thanks.