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

Le 20 nov. 2018 à 18:09, David Ahern [off-list ref] a écrit :

On 11/20/18 9:58 AM, Alexis Bauvin wrote:

quoted

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.

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.

Thanks!