On 11/21/18 7:05 AM, Alexis Bauvin wrote: > 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.
AFAIK there is no balancing done. There is an order to which socket is selected - and it includes the VRF device if relevant. > > 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.
