Dumitru Ceara <[email protected]> writes: > On 5/21/21 11:27 AM, Paolo Valerio wrote: >> Aaron Conole <[email protected]> writes: >> >>> Dumitru Ceara <[email protected]> writes: >>> >>>> On 4/26/21 2:19 PM, Eelco Chaudron wrote: >>>>> Currently, conntrack in the kernel has an undocumented feature referred >>>>> to as all-zero IP address NULL SNAT. Basically, when a source port >>>>> collision is detected during the commit, the source port will be >>>>> translated to an ephemeral port. If there is no collision, no SNAT is >>>>> performed. >>>>> >>>>> This patchset documents this behavior and adds a self-test to verify >>>>> it's not changing. >>>>> >>>>> Signed-off-by: Eelco Chaudron <[email protected]> >>>>> --- >>>>> v3: Renamed NULL SNAT to all-zero IP SNAT. >>>>> v2: Fixed NULL SNAT to only work in the -rpl state to be inline with >>>>> OpenShift-SDN's behavior. >>>> >>>> Hi Eelco, >>>> >>>> Would it be possible to add this capability to the list of kernel >>>> Datapath.capabilities ovsdb column? [0] >>>> >>>> Given that the patch to add userspace datapath support for all-zero IP >>>> SNAT is not accepted yet [1], and even if it does it will likely not be >>>> backported to LTS because it's a feature, this would make it easier for >>>> OVN (for example ovn-controller) to determine at runtime if it should >>>> use all-zero IP SNAT or not. >>> >>> I think it would be rather difficult to add this to the userspace patch >>> being proposed. >>> >>> Actually, if we want something where datapath can detect whether such >>> feature is supported, there isn't a good test. For instance, normally >>> we would attempt to insert a flow that has the characteristics we desire >>> and look for a failure to insert. In the case of all-zero SNAT, >>> both datapaths can "accept" it, so it becomes difficult. >>> >> >> I was wondering the same, a successful insertion doesn't ensure the >> correctness and so the support of this feature. >> >>> Also, the netlink datapath under linux has had this support since it was >>> introduced, so we're really just documenting it here. It can still be >>> used in older releases. OTOH, userspace doesn't have such support. >>> Both datapaths will accept flows with SNAT set to 0, as far as I can >>> tell. This means there's not an easy way to distinguish them. >>> >>> Maybe we need a change to this patchset to reject such flows from the >>> netdev datapath, and then we can modify [1] to remove such limitation. > > That would work, I guess. > >>> Then it can be detected by the datapath capabilities that already exist. > > Sounds good to me but which already existing datapath capability would > you use? As far as I see the existing ones are: > > https://github.com/openvswitch/ovs/blob/13c0eaa7b4fc2694a8c6cc8e6487ec6538c607e4/ofproto/ofproto-dpif.c#L5567 > > Shouldn't we add a new one, e.g., "ct_zero_nat"?
Yes, sorry - I think it was meant to use the mechanism that already existed, rather than reuse an existing bit. >>> >>> Maybe I missed something, or misunderstood something. >>> >>> Thoughts? >>> >> >> Considering that linux supports all-zero snat since day one, the >> assumption seems solid enough to me for it. >> >> I have no details about it, but what about Windows dp? >> >>>> [0] >>>> https://github.com/openvswitch/ovs/commit/27501802d09f782b8133031c1eae3394ae5ce147 >>>> >>>> [1] https://patchwork.ozlabs.org/project/openvswitch/list/?series=241223 >>>> >>>> Thanks, >>>> Dumitru >> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
