On 11/21/18 5:54 PM, Alexis Bauvin wrote: >>> 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.
