Re: [PATCH 3/3] vxlan: virtual extensible lan

On Thu, Oct 4, 2012 at 8:12 AM, Stephen Hemminger [off-list ref] wrote:

On Thu, 04 Oct 2012 08:34:50 +0200
Eric Dumazet [off-list ref] wrote:

quoted

On Wed, 2012-10-03 at 21:02 -0700, Stephen Hemminger wrote:

quoted

Since port is always a pair, there is no need to restrict range, unless
there was a broken firewall in the way. One bug there is that random32()
can return 0 which is not a valid port number.  A better fallback
would be a hash of the MAC header.

But using up to 65536 values for the port means that if vxlan traffic
crosses a statefull firewall (eg netfilter with conntrack), this might
need 65536 contexts/sessions.

This is UDP, there is no usable state to be found.
But as a practical matter it only needs to be wide enough to hit the
number of receive channels. Therefore even 64 is probably enough for
most people.

I don't think it actually matters all that much either way because
there will be one vxlan flow for each encapsulated flow.  If you're
running iptables on a hypervisor, for example, you probably end up
seeing the same number of flows as you do today.

There is some benefit to using a slightly wider range than the number
of paths you can take because devices in the path will do their own
hash.  Having a larger range on the vxlan side will reduce the impact
of collisions in the second hash.

quoted

So random32() is not needed.

What might be needed is additional parameters for a vxlan tunnel, to
give an optional range for the source port.

It could be per vxlan without a lot of pain. or just derive it value
from existing ephermeral port range.

In the STT draft we recommended using the ephemeral range.  It seemed
like a good balance.