Re: [RFC v3 3/3] vxlan: handle underlay VRF changes
From: Alexis Bauvin <hidden>
Date: 2018-11-22 11:31:32
Le 21 nov. 2018 à 20:28, David Ahern [off-list ref] a écrit :
On 11/21/18 7:05 AM, Alexis Bauvin wrote:quoted
Le 20 nov. 2018 à 18:09, David Ahern [off-list ref] a écrit :quoted
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.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?
quoted
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).