Le 20 nov. 2018 à 18:09, David Ahern <d...@cumulusnetworks.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. 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!
