netdev - Re: [RFC v3 3/3] vxlan: handle underlay VRF changes

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: <363CE0A1-D608-4E24-841A-992428372C19@scaleway.com>
Date:   Thu, 22 Nov 2018 01:54:39 +0100
From:   Alexis Bauvin <abauvin@...leway.com>
To:     David Ahern <dsa@...ulusnetworks.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:     netdev <netdev@...r.kernel.org>, akherbouche@...leway.com
Subject: Re: [RFC v3 3/3] vxlan: handle underlay VRF changes

Le 21 nov. 2018 à 20:28, David Ahern <dsa@...ulusnetworks.com> a écrit :
> On 11/21/18 7:05 AM, Alexis Bauvin wrote:
>> Le 20 nov. 2018 à 18:09, David Ahern <dsa@...ulusnetworks.com> a écrit :
>>> On 11/20/18 9:58 AM, Alexis Bauvin wrote:
>>>> A socket bound to vrf-blue listens on *:4789, thus owning the port. If moving an
>>>> underlay to the default vrf (ip link set dummy-b nomaster), a new socket will be
>>>> created, unbound to any interface and listening on *:4789. However, because it
>>>> will be in the default vrf, it will try to take ownership of port 4789 on ALL
>>>> vrfs, and fail because this port is already owned in vrf-blue for vxlan-a.
>>> 
>>> SO_REUSEPORT will fix that and incoming traffic through a vrf and
>>> default (non-)vrf will work. The recent changes by Vyatta provide even
>>> better isolation of default vrf and overlapping ports.
>> 
>> Did not think about that one, I will give it a shot.
>> 
>> There is one issue I can see with SO_REUSEPORT (if my understanding of it is
>> correct). From what I understood, enabling this option will balance incoming
>> connections (for TCP) / dgrams (for UDP) based on a 4-tuple hash (sip, dip,
>> sport, dport) between sockets listening on the same port.
> 
> AFAIK there is no balancing done. There is an order to which socket is
> selected - and it includes the VRF device if relevant.

Maybe balance was not the correct word, "route" may be more appropriate. Still you
understood me, thanks for the details!

Yet, the "if relevant" part is interesting. Does enabling the
net.ipv4.udp_l3mdev_accept sysctl counts as making vrfs not releavant? In that case,
both sockets are treated equally, right?

>> 
>> If we have two separate vxlan fabrics, with one underlay in the default vrf, and
>> another in some random vrf. Since the socket for the default vrf would own the
>> port on all vrfs, the port would effectively be reused between the two vrfs.
>> Wouldn't vxlan packets be directed to "random" (as in not related to the vxlan
>> fabric itself) sockets, meaning a complete mix of the two fabrics? This would
>> imply a complete drop of the packets not directed to the correct socket.
>> 
>> I guess the Vyatta changes you are talking about are "vrf: allow simultaneous
>> service instances in default and other VRFs"? If so, it looks like it would
>> solve the default vrf problem, not even requiring SO_REUSEPORT.
>> 
> 
> yes.

So it would seem with the above that SO_REUSEPORT is a solution when not using
Vyatta's changes, which are a solution themselves (I will test those anyways).