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

On 11/21/18 5:54 PM, Alexis Bauvin wrote:

quoted

quoted

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 udp_l3mdev_accept is disabled the default VRF is treated like a  real
VRF as opposed to no VRF (Vyatta's changes), meaning the scope of the
socket is just the VRF (or just the default VRF).

If udp_l3mdev_accept is enabled it allows an unbound UDP socket to work
across all VRFs.

Gives user's options for how to deploy their s/w especially when it
comes to all of the existing software that is has no idea about VRFs.