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: <f738ce8a-6726-80c5-1961-3067b1f41566@cumulusnetworks.com>
Date:   Wed, 21 Nov 2018 12:28:13 -0700
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Alexis Bauvin <abauvin@...leway.com>
Cc:     Roopa Prabhu <roopa@...ulusnetworks.com>,
        netdev <netdev@...r.kernel.org>, akherbouche@...leway.com
Subject: Re: [RFC v3 3/3] vxlan: handle underlay VRF changes

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.

> 
> 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.